Review company insurance cover

When to use

The yearly pass over all insurance the company holds. Not for motor third-party liability renewal alone — that is vehicles.octa-renewal and runs on its own expiry clock; this review only checks it is not forgotten. Not for supplier and lease contract renewals — that is ops.contract-renewal-watch. Not for handling an actual loss — report the event first (vehicles.accident for vehicles), then let it feed the claims history in S5.

Before you start

• The previous year's inventory is in documents, or the agent builds one from mail and the insurer portal in S1.
• The owner can name what changed this year (S2), or the agent drafts the change list from the goals and tasks records.
• Payment authority is known: who approves premiums and from which account.

What a run requires3

The trail8 steps

1. S1

   Build the inventoryagent

   Collect every policy: insurer, policy number, what it covers, sums insured, deductible, premium, expiry, auto-renew on/off. Include company vehicles, leased premises (check the lease for a required tenant cover), and any cover an employee bought "for the company" personally — flag those.

   Done when the inventory in documents has a row for every policy and every row has an expiry date.

2. S2

   List what changedagent

   Compare today's company with last year's review: new or closed premises, equipment bought or sold, headcount, revenue, new products or markets, work abroad, subcontractors.

   Done when a dated change list exists, each line pointing at the policies it could affect.

3. S3

   Check each policy against realityagent

   For each policy read the terms: is the sum insured still enough, are current activities and addresses actually named or covered, what is excluded, does the deductible still make sense.

   Done when each row carries a verdict: fits · too small · wrong scope · expired exclusion ⚠ verify against the policy text, not memory.

4. S4

   Check the claims historyagent

   List claims since the last review: what, paid, rejected and why, effect on premium.

   Done when the claims note is in the inventory, including "none".

5. S5

   Name the gapsagent

   From S2–S4 write the gap list: underinsured assets, uncovered activities, missing cover types (liability, cyber, employer obligations — ⚠ verify which are legally required vs optional for this company in LV), personal-policy flags.

   Done when every gap has a one-line consequence ("fire in the office: paid X of Y").

6. S6

   Decide per policyownerneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Present the inventory and gap list with options and a recommendation per policy: renew as is · change cover · switch insurer · drop · add.

   Done when every policy has a named decision and a decision record exists (management.decision-record format).

7. S7

   Execute the decisionsagentneeds approval · ownerirreversible

   Approval · S7 · owner — the run stops until a named person records the decision

   Irreversible · S7 — an agent never closes it alone

   For renewals: confirm terms in writing before the expiry; the owner approves the premium, the agent schedules payment from the money module — the agent never pays itself. For switches: new policy bound before the old one ends. For drops: record why.

   Done when each decision shows either a bound policy with new expiry, or a recorded "dropped on <date> because …".

8. S8

   Record and hand backagent

   Update the inventory with new terms and expiries, put every expiry in the renewal watch with a lead time, add open tasks (bc tasks add) for anything not closed, send the owner a summary: policies, total premium, changes, next earliest expiry.

   Done when the inventory carries the new terms and expiries, every expiry is in the renewal watch with a lead time, open items have tasks, and the owner has the summary.

Checks — how we know it worked

• Every policy row has an expiry date later than today, read from the policy document, not from memory.
• For each renewed policy: the written confirmation matches the agreed sums, deductible and premium before payment.
• No switch left a day without cover: old policy end date ≤ new policy start date, in that order.
• Vehicle OCTA appears in the inventory with its own expiry, whether or not it was renewed here.
• Any policy held in a personal name is flagged with a decision, not silently carried over.

If it goes wrong

What each step leaves behind

1. S1the inventory in documents has a row for every policy and every row has an expiry date.
2. S2a dated change list exists, each line pointing at the policies it could affect.
3. S3each row carries a verdict: fits · too small · wrong scope · expired exclusion ⚠ verify against the policy text, not memory.
4. S4the claims note is in the inventory, including "none".
5. S5every gap has a one-line consequence ("fire in the office: paid X of Y").
6. S6every policy has a named decision and a decision record exists (management.decision-record format).
7. S7each decision shows either a bound policy with new expiry, or a recorded "dropped on <date> because …".
8. S8the inventory carries the new terms and expiries, every expiry is in the renewal watch with a lead time, open items have tasks, and the owner has the summary.

Evidence to keep

The inventory with per-policy verdicts · the change list with dates · the decision record from S6 · written renewal confirmations and payment references · the claims note · the summary sent to the owner.

How this playbook improves

After every run ask: how many days from start to last decision, and which step waited? Did S2 miss a change that S3 later surfaced anyway? Was any policy renewed at worse terms because the decision came after auto-renew? Did any expiry fall outside the watch? A new version changes the step that caused the wait or the miss, and says so in its change note.