What an Advisor CRM Must Do That a Spreadsheet Cannot

Start with the honest version, because most writing on this subject opens by insulting the reader. If you run your book in a spreadsheet, you are in the majority, and you did not arrive there through laziness. You arrived there because the spreadsheet is the only tool in this business that never said no.

It cost nothing. It opened in four seconds. It never asked which insurer you were tied to, never refused a product because somebody had not configured it, never locked a row while a support ticket sat open. When a principal started asking for a field nobody had asked for before, you added a column at nine in the evening. No tool sold to Indian advisors matches that, and general purpose is a real advantage when your book is genuinely idiosyncratic.

So the argument here is not that the spreadsheet is stupid. It is that a spreadsheet fails in six specific ways, that three of those failures are survivable at any book size, and that three of them compound: they worsen as the book grows, and by the time they are visible the loss is already booked. Telling the two groups apart is the whole decision.

One thing this post is not about. How your records should be structured, one row per policy per period, joined to a household, is a separate and upstream question. A badly structured book fails in any container. Assume yours is sound, and ask what the container still cannot do.

The first failure is the one everybody names and nobody fixes: a spreadsheet is passive.

A renewal date sitting in a cell is inert. It is a fact about the world, stored in a place that does not act on facts. Conditional formatting turns the cell amber as the date approaches, which is a genuine improvement, and it improves nothing whatsoever on the morning you do not open the file. The alert fires into an empty room.

This is not a small distinction. Every renewal you have ever lost was lost during a stretch when you were not looking at the row. That is true by definition. The row was correct the entire time. The row is always correct. Correctness is not the job.

What a system of record has to do instead is invert the direction of attention. The book contacts you, rather than waiting to be interrogated. A morning digest saying three motor policies fall due inside 30 days and one health case entered its grace period yesterday is not a nicer spreadsheet, it is a different relationship: the book raises its hand, and you respond.

Test it honestly. Ask how many days it has been since you last read every row, not scrolled past them, read them. Past roughly 150 policies the true answer is usually between three weeks and never. The rows you read are the rows about clients you were already thinking about. The rows that lapse are the ones you were not, which is precisely the set a passive tool cannot surface, because surfacing requires being looked at first.

A spreadsheet is excellent at arithmetic and entirely uninterested in whether the arithmetic is true.

Type =D2*0.15 and a number appears. That number is the commission you believe you are owed. It carries exactly as much authority as your belief did, which is none, because the rate is a fact about the contract of engagement between you and the entity that engages you, not a fact about your recollection of a conversation in March.

A POSP is remunerated by the entity that engages them, insurer or intermediary, under that contract of engagement. That entity issues a payout statement. The statement is the other side of the ledger, and it usually arrives as a PDF, sorted by the entity's own numbering, netted, covering a period that does not align with yours, occasionally carrying a reversal against a policy you placed nine months ago.

Reconciliation is the act of matching two lists built by two parties with different filing habits, and finding the rows on one and not the other. That is not multiplication. It is a join, then a difference, repeated every cycle. A spreadsheet holds both lists happily. It will not perform the match, and it will not remember that you performed it last month, so next month you start from the beginning, or, far more commonly, you do not start at all and accept the number the statement gives you.

The failure is not that the spreadsheet computes wrongly. It computes precisely what you told it to. The failure is that a formula produces an estimate wearing the clothes of a fact, and estimates that look like facts do not get checked. A number that cannot lose an argument with the payout statement is a hope with two decimal places.

A spreadsheet is a rectangle. Your book is not.

The Kulkarni household has a two-wheeler, a private car, a family floater and a term plan. Four policies, four expiry dates, three insurers, one decision. A rectangle offers two ways to hold that, and both are wrong in different directions.

One row per policy gives you a correct dates table and destroys the household. You call the same house four times a year as four unrelated strangers, and you never notice that three of the four fall due within six weeks of each other, which is the most useful thing available to know about that house.

One row per client gives you the household and destroys the dates. The policies move into columns (Policy 1, Policy 2, Policy 3) or into a notes cell, and the moment the household buys a fifth, you are editing the shape of the sheet rather than adding a record.

You can do this properly in a spreadsheet. Two tabs, a client ID, a lookup. Advisors do it, it works, and here is what happens to it. The join is a formula, formulas are maintained by whoever wrote them, and nothing in the file objects when someone types the household's name into the ID column because it was faster that morning. Six months on, half the lookups return a value and half an error, and the errors cluster on rows edited in a hurry, which are the rows about clients who were calling you, which are your best clients.

The distinction worth holding is not capability. It is enforcement. A grid permits every shape, including the wrong one, and permits it silently. A system of record refuses.

Ask an advisor to produce the policy schedule for a specific motor policy issued fourteen months ago. Watch what happens.

Almost nobody opens the spreadsheet. They open WhatsApp and scroll, because that is where the PDF is. The spreadsheet holds the policy number, the insurer, the IDV and the expiry date, and has no way at all to hold the document those facts were copied out of. A cell can hold a filename. It cannot hold the file.

That matters more than it sounds like it should, for three reasons.

• The schedule is the authority and the row is a copy. Every field in your book was transcribed by hand from a document. When row and document disagree, the document wins. If you cannot reach the document quickly you settle the disagreement from memory instead, which is how a wrong expiry date survives for a year.
• The client wants the document, not your row. A client calling about a claim wants the schedule. Sending it in ninety seconds is servicing. Saying you will look for it and send it tonight is the first move in the sequence that ends with an advisor being replaced.
• A chat thread is transport, not storage. Media expires off devices, threads get archived, phones get replaced, and a search for policy returns four hundred results sorted by nothing useful.

The link a spreadsheet cannot make is the one that turns a row into a record: this number, this date, this premium, and the document all three were read out of, in one place, retrievable by policy number rather than by remembering which month the client sent it.

This is the failure advisors discover last and regret most.

A spreadsheet stores the current state of the world. Cell F14 says Renewed. It does not say who changed it from Pending, or when, or on the strength of what. Edit history exists in some tools, and is switched off, or unread, or lost the first time the file travels as an attachment and gets edited by the copy.

A book of clients is not a state. It is a sequence of events. You sent this quote on this date. The client asked that question on that date. You forwarded the insurer's approved brochure on the fourteenth, and you did not author your own version of it.

That last one is regulatory, and it deserves precision. A POSP may not issue or publish any advertisement or sales material without the prior approval of both the engaging entity and the insurer. Sending an approved document to an existing client who asked a question is servicing. Composing your own one-pager and pushing it to two hundred contacts is much closer to the thing that needs approval. The difference between those two acts is invisible in a cell that says Sent. It is visible only in a record of what was sent, to whom, when, and whether the artefact was the approved one or something you wrote at midnight.

Two failures that look practical and are structural.

The first is form factor. You work standing outside a workshop, in a client's front room, on a two-wheeler seat between calls. The tool you have in that moment is a phone. A spreadsheet on a phone is a grid rendered at a size where six cells are visible, on a file that either opens a stale download or fights the cloud copy somebody else has open. So the entry does not happen there. It happens tonight, from a photograph of a proposal form and whatever you still remember, and tonight is when transcription errors are made. The book is not wrong because you are careless. It is wrong because the moment of capture and the moment of recording were separated by nine hours and a commute.

The second is durability. The file is a file. It lives on one laptop or in one cloud account, under one login, in a format only you can read, with a column scheme only you understand. If the laptop goes, the book goes. If you go, the book goes, and this is the part nobody plans for. No successor, no family member and no principal picks up a file named book final v3 (2).xlsx and services two hundred households out of it.

Six failures, and they are not equal. Treating them as equal is why advisors either change nothing or try to change everything.

Three are survivable. The phone problem, because you can discipline yourself to record the same evening, and most advisors do. The document problem, because chat search is bad but not useless, and a client who waits a day for a schedule is irritated rather than lost. The rectangle problem, because a disciplined two-tab file with real IDs genuinely works, at the price of you personally being the enforcement mechanism forever.

Three compound.

1. Passivity compounds because the book grows and your attention does not. At 80 policies you can read every row monthly. At 300 you cannot, and the unread fraction is where lapses come from, so the loss rate rises with the size of the book. This is the only failure that gets worse precisely because you are succeeding.
2. Unreconciled arithmetic compounds because an undetected payout difference is not an event, it is a rate. A gap you never caught in month one is still running in month thirty, applied to every policy in between, and by then the arrears are past the point where anybody will discuss them.
3. Missing event history compounds because the record you need is the one you did not know you would need. You cannot retroactively start recording what you sent whom. On the day the question is asked, the answer is either already stored or gone permanently.

The survivable failures cost you time, now, visibly. The compounding ones cost you money, evidence and continuity, later, invisibly, and they charge interest meanwhile.

A spreadsheet is a perfectly reasonable tool for a book you can hold in your head. The difficulty is that no advisor ever decides to outgrow it. There is no morning on which the file stops working. The book grows, the tool stays, and the three failures that compound do so quietly for two years before anyone notices, which is roughly two years past the point where fixing them was cheap.