Three products, three different problems
| What it is | Solves | Fails at |
|---|---|---|
| Generic CRM (HubSpot, Zoho, Pipedrive) | Pipelines, reminders, email sequences, reporting. Cheap or free at small scale. | Knows nothing about policies. No field for a conversion deadline, a rider, a cash value or an in-force date, so you either bolt them on as custom fields or keep them in your head. |
| Agency management system (AgencyBloc, Radius, and similar) | Built for insurance. Policies, commissions, carriers, compliance. The right shape of database. | Still waits to be told. It automates what you configure and stores what you enter; the reading, the filing and the typing remain yours. |
| Spreadsheet | Free, instant, and genuinely fine below roughly a hundred policies. | No reminders, no documents, one person, and no way to answer "what expires in the next ninety days" without maintaining it by hand. |
| AI assistant that holds the book (Briar) | Reads the mail and the documents and populates itself, then tracks and flags. No separate CRM to pay for. | New, and deliberately narrow — built for independent life agents rather than for every line of business. |
The honest version of the buying decision: if your book is small and your memory is good, a spreadsheet and a calendar will hold you for longer than anyone selling software will admit. If you are missing follow-ups, a cheap generic CRM fixes that this week. If your system is out of date because updating it is unpaid work you do at night, no CRM fixes that, because being out of date is not a feature gap.
The five fields a life-specific system needs that a generic one does not
- Conversion deadline — the date a convertible term policy stops being convertible. It is the single most valuable date in a life book and no generic CRM has a field for it.
- Riders, individually — accelerated death benefit riders for terminal, chronic and critical illness, waiver of premium, child riders. A text note is not a rider field; you cannot query a text note.
- In-force values that move — cash value and premium are not static properties of a client, they are a time series, and last year's number is worse than no number.
- The requirement pipeline — what each carrier is still waiting for on each application in flight. This is where cases die, and it lives in email by default.
- Carrier-agnostic policy records — an independent agent writes with several companies and needs one book, not one silo per carrier portal.
What "free" costs
Free CRM tiers are genuinely good now, and for an agent under about a hundred clients a free tier plus a disciplined calendar is a defensible answer. The cost shows up in three places, and all three arrive at once when the book grows: contacts limits that bite exactly when you are busiest, no document storage that is safe for client information, and the fact that everything in it is still typed by you.
How Briar is different from the systems above
Briar is the system of record itself, so it replaces the CRM rather than sitting beside it — but the reason to use it is not the storage. It reads the mailbox every minute, reads carrier documents on your own machine, and files them against the right client only when two independent identifiers agree. The book fills itself from work that was arriving anyway.
It also imports an existing book from a carrier's own CSV export, so moving does not mean retyping. And because it holds the documents as well as the records, it can answer questions about the book rather than only storing it.