Insurance CRM software organised around the customer, not the deal.
Insoora holds one record per policyholder: every policy they hold and have held, every document, every expiry date, and a login of their own if you want them to have one. What it does not hold is a sales pipeline — and it is better to say so on this page than to let you find out on the third screen.
- One record per policyholder
- Every policy they hold, by year
- Policies matched by mobile number
- Optional portal login per customer
On this page
Read this first
Two different things are called an insurance CRM
They solve different problems, and buying the wrong one is the most common mistake in this category.
A sales CRM manages people who have not bought yet. It has leads, stages, follow-up tasks, quotations, call logs and campaign sending, and it is judged on how many prospects it converts.
A client CRM manages people who have already bought. It has one record per policyholder, every policy under it, the documents, the dates, and the question "what does this customer actually hold?" answered in one screen. It is judged on whether you can service a book of business without opening a shared drive.
Insoora is the second kind. For an agent whose real problem is that four hundred policyholders are spread across a spreadsheet, a WhatsApp history and a folder of PDFs, the client record is the thing that was missing — and a pipeline would not have helped.
- Search the customer list by name or mobile number
- Open a customer and see every policy they hold and have held
- See at a glance which policyholders have a portal login and which have never signed in
What it does not do
There are no leads, no deal stages, no quotations, no task assignment, no email or SMS campaigns and no call logging. If you are shopping for a pipeline to convert prospects, this is not that product.
The client record
What is on a policyholder in Insoora
Only fields the platform actually stores. There is no custom-field builder and no notes timeline.
Identity and contact
Name and mobile number, which is also the key a policy uses to find its customer and the number a policyholder registers their portal login with.
Every policy held
All policies assigned to this customer across lines of business, each with its insurer, number, premium and dates.
Previous years
Policies stack by year, so last year's cover and the document that proved it are one click away rather than one search of an inbox.
The documents themselves
Every uploaded PDF stays attached to the policy it was read from, in private storage, downloadable by whoever is authorised.
What expires when
Each policy's expiry as read off its schedule, which is what puts this customer on a renewal list without anybody setting a reminder.
Portal account state
Whether this policyholder has a login, has been given one and never used it, or has none — the column that tells you who still rings you for a copy of their own policy.
Who this changes something for
Three situations, and what is different
A customer rings to ask what cover they have. The answer is in a spreadsheet for the policy number and a Downloads folder for the document, and the spreadsheet was last tidied in March.
Search the name, open the customer, read every policy they hold and send the PDF — without leaving the screen or trusting a sheet.
Three people sell, each keeps their own list, and nobody can say how many policies the agency holds or which of them expire next month.
One book of business. Everyone uploads into it, the agency sees all of it, and each person's access is granted rather than assumed.
Policies are inherited as a folder of PDFs with no index, and the only way to know what is in there is to open four hundred files.
Upload the folder. Each document is read, filed under a matched customer, and the ones that cannot be matched are queued for you to assign instead of being lost.
How a policy finds its person
The mobile number is the key
This is the mechanism worth understanding before you upload anything, because it is where a customer record comes from.
When a policy is extracted, Insoora reads the mobile number off the document and matches it against the numbers you hold on record. A match files the policy under that customer. No match, and the policy waits in a queue for an agent to assign it — it is never attached to a nearby-looking name.
The same number is how a policyholder registers for their own portal. They sign up with the number their agent already holds, which is what ties the login to the right book of policies without anyone issuing credentials by email.
The practical consequence: the quality of your customer records depends on the mobile numbers being right. An agency whose numbers are current gets most policies filed automatically; one whose numbers are five years old gets a longer assignment queue.
- A matched policy is filed under the customer automatically
- An unmatched policy waits to be assigned rather than guessing
- A policyholder registers with the number already on their record
What it does not do
There is no deduplication wizard and no fuzzy name matching. Two records for the same person with two different mobile numbers stay two records until somebody merges them by hand.
What is not here
The parts of a CRM Insoora does not have
A list long enough to disqualify the product for some buyers, which is the point of publishing it.
No lead or pipeline management
No leads, stages, opportunities, quotations, proposals or conversion reporting. Insoora starts at the policy that has already been issued.
No outbound messaging
It does not send renewal emails, SMS, WhatsApp messages or campaigns, and does not log calls. The renewal list tells you who to contact; contacting them is still you.
No custom fields or notes
The customer record holds what the platform stores. You cannot add a field, a tag, a segment or a notes timeline of your own.
No commission or brokerage tracking
Premium figures are recorded as the document states them. Insoora does not calculate commission, split it between sub-agents, or reconcile what an insurer paid you.
Choosing between the two
Which kind of CRM you actually need
The question that settles it is not about features. It is about where your time goes in a normal week.
If most of it goes on finding new customers — chasing enquiries, following up on quotes, keeping track of who you called — then the thing you are missing is a pipeline, and a client record will not give you one.
If most of it goes on servicing customers you already have — finding last year's policy, telling someone what they hold, working out what expires next month, re-typing a schedule into a sheet — then the thing you are missing is a client record, and a pipeline will not give you one either.
Can you use both?
Yes, and plenty of agencies do: a pipeline tool for prospects and a policy system for the book. There is no integration between Insoora and any CRM, so the handover is manual — you upload the policy PDF once the sale has closed.
That is a real cost and worth naming. It is also a smaller cost than it sounds, because the handover happens once per policy rather than once per conversation.
What to test before you decide
Upload five policies from the insurers you actually sell, from the oldest-looking documents you have. Extraction quality on your layouts is the only thing about this product that cannot be judged from a page like this one, and it is the thing the whole value depends on.
Frequently asked questions
Questions this page should answer
Keep reading
Where to go next
The pages that cover the next part of this, with what each one adds.
Your customer records are already inside your policy PDFs.
Upload the documents and the client list builds itself, one matched policy at a time.