How to Manage Multiple Insurance Policies in One Dashboard

The complaint behind this question is rarely about dashboards. It is that answering one simple question requires four places: a spreadsheet for the policy numbers, a folder for the documents, a WhatsApp history for what the customer last asked, and an insurer portal for anything current.

So the goal is not a screen with tiles on it. The goal is that one screen can answer the three questions an agent asks a hundred times a week — what does this customer hold, where is that document, and what expires soon — without opening anything else. A dashboard is what that looks like at the end; it is not how you get there.

One dashboard requires that a motor policy, a health floater and a shop fire policy can appear in one list and be sorted by the same column. That is a data problem, and it has four parts.

1. 1

   Every policy has a real expiry date

   Read from its own schedule, not calculated. The moment one policy's date was assumed rather than read, the sorted list is no longer trustworthy — and it will be the travel policy or the long-term motor policy that is wrong.

2. 2

   Every policy belongs to a customer

   Matched to a person, not sitting loose. In practice the mobile number on the document is the key: match it against the numbers you hold, and anything that does not match waits to be assigned rather than being attached to a near-enough name.

3. 3

   Every policy has its document attached

   Not in a folder named after the month. On the record, so that "where is that document" is answered by opening the policy rather than by a search of a drive.

4. 4

   Every line of business keeps its own fields

   This is the part people get backwards. One dashboard does not require flattening every policy into the same four fields — it requires a shared spine (customer, insurer, number, period, premium) with each line keeping its own detail underneath. Flattening is what makes a dashboard possible and useless at the same time.

Get those four right and the dashboard is almost incidental. Get any of them wrong and no interface can compensate: a list sorted by a column half of whose values were guessed is worse than no list, because it looks complete.

Dashboards fail by containing too much. Five numbers, each of which should change what you do today.

Worth naming, because they are what most dashboards in this category are full of.

• Total policies, all time. A monotonically increasing number with no action attached. It is a vanity metric and it takes the space a renewal count needed.
• Premium under management. Tempting, and usually misleading: it mixes lines of business with different premium scales, it double-counts a renewal against the policy it replaced, and it is not your income.
• A monthly growth chart. Three points of data is not a trend, and for a small agency monthly policy counts are dominated by the timing of a few renewals.
• A per-person league table. It measures who uploaded, which is a measure of who did the filing — not of who sold. In an agency where one person uploads for the others it is actively wrong.

None of these is forbidden information. They are just not operational, and a dashboard is an operational screen. Put them in an export if somebody wants them at year end.

Most agencies arrive at this question halfway through: some policies in a spreadsheet, some in new software, and a period where neither view is complete. That period is the dangerous one, and it is worth being deliberate about.

1. 1

   Pick one system as authoritative, on a date

   From the first of the month, every new policy goes in the new system and nowhere else. Two systems both kept half-current is the state to avoid, because then neither can answer the renewal question and both look like they can.

2. 2

   Move the current year first

   Not the archive. The current year is what the renewal list has to be right about, and it is the half that pays for itself in the first month. Twelve months of policies is a finite, visible piece of work.

3. 3

   Keep the old register read-only

   Rename it, do not delete it. It stays as the record of the years not yet moved, and marking it read-only is what stops somebody helpfully adding a new policy to it in March.

4. 4

   Backfill the archive in batches

   By customer rather than by year, so that each batch finishes something: one customer's five years is a complete history, where one year across all customers is five incomplete ones.

5. 5

   Then check the two agree, once

   Export the policy list from the new system and compare the count and the renewal dates against the old register for the current year. Do this once, deliberately, rather than trusting it — this is the step that catches the fifteen policies nobody moved.

One more consequence of having everything in one shape: other people can be given their own view of it, which removes work rather than displaying it.

A policyholder with a read-only login can see their own policies, how long each has left and the documents — which is the "send me a copy of my policy" call, removed. A sub-agent can be given a view of the agency's book with upload but not confirm, or read without seeing unmasked phone numbers. In both cases the point is not transparency for its own sake; it is that a question somebody else can answer themselves stops arriving as an interruption.

• The customer's view should be read-only. A customer who can edit a record creates a different problem from the one you were solving.
• A sub-agent's view should be granted capability by capability rather than as a role, so a reviewing role can exist without access to customers' phone numbers.
• Nobody's view should be enforced by hiding a button. If it is not checked on the server, it is not access control.