Insurance Management System
Keep every policy connected from enquiry to renewal.
A system built around the record insurance actually runs on: the customer, the policies held against them, what each one is waiting for, who owns it, when it renews, and what commission it should produce. Built for how your agency works rather than configured to fit somebody else’s product.
Branditify builds these to order. There is no product to log into here — the page describes the system and what a build has to get right.
ArjunSomebody asks. It may or may not become a policy, and it belongs to a person from this moment.
OperationsProposal, documents and payment. The state that answers "what is this waiting on".
OperationsThe policy exists. Its number, its term and its document attach to the record.
ArjunNothing needs doing, which is exactly when a policy falls out of view.
ArjunThe term is ending. A task exists, it has an owner, and it starts from everything above rather than from a blank row.
ArjunA new term, linked to the one before it. The customer, the agent and the history carry across.
- Customer
- Maya Sharma · two other policies held
- Agent
- Arjun · owns the relationship and the renewal
- Documents
- Current policy document · previous term’s copy retained
- Payment
- Received against the current term
- Commission
- Expected · not yet reconciled against a statement
- Next action
- Call before the term ends · owned by Arjun
Illustrative policy record · sample data
Renewal due: The term is ending. A task exists, it has an owner, and it starts from everything above rather than from a blank row.The state that costs the most is Active, because nothing is asking for attention. A record that cannot surface itself when its term is ending is a record that only works while somebody is watching it.
The problem underneath
One customer, six places, and no single record that knows all of it.
Nobody chose this. It accumulates — a spreadsheet that worked at forty policies, a calendar for renewals, a folder of PDFs, and a commission sheet somebody reconciles at month end.
- 01SpreadsheetThe policy list. Usually correct, usually one person’s.
- 02Calendar or reminderWhen the renewal is due, disconnected from why.
- 03Documents folderThe policy PDFs, named however whoever saved them named them.
- 04Payment recordsWhat came in, in a different system from what it was for.
- 05Commission sheetWhat is owed, reconciled from statements by hand.
- 06Chat and call notesWhat the customer actually said, which is often the only place it exists.
None of these is wrong on its own. What is missing is anything that holds them together, so every renewal starts by reassembling the picture — and the ones nobody reassembles are the ones that lapse.
This is not an argument against spreadsheets. A spreadsheet is a genuinely good tool up to a point, and the point is usually reached when renewals start being missed rather than when the row count gets uncomfortable.
- What is insurance agency management software?
- Software that keeps a broker or agency’s insurance-specific records connected — the customer, the policies held against them, the state each policy is in, its documents, its renewal, the agent who owns it and the commission it should produce. The distinction from general business software is that it understands a policy as a thing with a term, a renewal and a commission attached, rather than as a row.
- What is insurance broker management software?
- The same category, named from the broker’s side. A broker places business across several insurers rather than one, so the system additionally has to hold which insurer each policy sits with, what commission each arrangement produces, and how remittances from different insurers reconcile against the policies they cover.
The distinction everything else depends on
A customer is not a policy, and treating them as one is where the data goes wrong.
The commonest structural mistake in a spreadsheet-run agency, and the hardest to unpick later.
One row per policy
Maya Sharma appears three times. Her phone number is different in two of them because somebody updated one row. Nobody can answer "what does this customer hold with us".
One customer, three policies
Maya Sharma is one record. Motor, health and home are three policies against it, each with its own term, renewal, documents and commission.
- A renewal conversation can mention the other two policies
- A change of address or phone number happens once
- The agency can see what a customer is worth across everything they hold
- A lapse on one policy is visible against the rest of the relationship
- Can one customer have multiple policies?
- Yes, and getting that structure right is the foundation the rest of the system rests on. One customer record holds many policies, each with its own insurer, term, renewal date, documents and commission. The alternative — one row per policy — duplicates the customer, so contact details drift apart and nobody can answer what a household or a business actually holds with the agency.
Between the enquiry and the policy
The stage where things sit, and nobody is sure whose turn it is.
Most operational frustration in an agency lives here, and almost all of it is one unanswered question: what is this waiting on.
- ProposalSubmitted to the insurerDone
- DocumentsOne outstanding — waiting on the customerWaiting
- PaymentNot yet receivedWaiting
- IssuanceBlocked until the two above clearNext
Three states, one question each: what is needed, who from, and who is chasing it. A case that can answer those does not need a status meeting.
Documents belong to the policy, not to a folder
- The proposal or application, as submitted
- The policy document for the current term
- The previous term’s document, retained rather than replaced
- Receipts and customer documents where the workflow needs them
The one that matters most is the second-to-last. When a policy renews, the previous term’s document should not be overwritten — a claim or a query about last year has to be answerable next year.
Where agencies lose money quietly
A renewal is not a new row. It is the next term of something you already have.
This is the single most valuable distinction in the whole system, and the one an off-the-shelf spreadsheet cannot hold.
Renewal as a new entry
- The customer is re-entered, or matched by hand
- Last year’s document is somewhere else
- Who handled it last time is a memory
- What the customer objected to last year is lost
- The old row is deleted, or left to confuse somebody
Renewal as the next term
- The customer record is the same record
- The previous term stays, linked, and readable
- The agent who owns the relationship owns the renewal
- The history of the last conversation is attached
- Both terms exist, and the policy has a past
- 01Term end approachesThe record knows its own end date. Nothing has to be watched.
- 02A task appears, ownedNot a list of expiries — a task on a person, opening onto the policy.
- 03The conversation starts with contextWhat they hold, what changed, what they said last time.
- 04The outcome is recorded either wayRenewed, lapsed or moved. A lapse with a reason is worth more than a blank.
- 05The new term links to the oldThe relationship continues; the policy has a history.
The renewals that lapse are almost never refused. They are the ones nobody got to, on records nobody could see, in a month that was busy. That is a systems problem, not a sales one.
- What is the difference between a renewal and new business?
- New business creates a relationship; a renewal continues one. The system should treat them differently — a renewal inherits the customer, the agent, the previous term and its documents, and produces a new term linked to the old one rather than a fresh unconnected record. Handled as new business, a renewal loses the history that makes the conversation easy and leaves the agency unable to see how long it has actually held a client.
- How does policy renewal management work?
- The renewal is generated from the policy rather than tracked beside it. As the term end approaches the record produces a task with an owner, and that task opens onto the existing customer, the previous term, the documents and the history. Whoever handles it starts from context rather than from a name and a date, which is the difference between a renewal conversation and a cold call to your own customer.
Who owns what
Two different questions the same system has to answer.
Who brought the business, and who is responsible for it now. In an agency with sub-agents these are frequently not the same person, and commission usually follows the first while follow-up follows the second.
- AgencyNorthstar Insurance ServicesHolds the book and the insurer arrangements.
- AgentArjunOwns the customer relationship and the renewal.
- Sub-agentNehaSourced this policy. Commission arrangement follows the source.
- Who sourced this policy?Decides the commission arrangement.
- Who owns the follow-up?Decides whose task list the renewal lands in.
- Who may see this customer?A permissions question, and a commercial one in an agency with several sub-agents.
Roles a build usually needs
- Owner / admin
- Everything, including the commission arrangements.
- Agent
- Their own customers, policies and renewals.
- Operations
- Processing and documents across the book, usually without commission visibility.
- Finance
- Payments and reconciliation, usually without editing policy records.
Which of these a specific agency needs is a scoping conversation rather than a default. The one that varies most is whether an agent can see anything beyond their own book, and that is a commercial decision before it is a technical one.
How deep the hierarchy goes and how commission splits down it varies enormously between agencies. A build models the arrangement the agency actually operates rather than assuming a standard multi-level structure.
The number that is always slightly wrong
What you expected, what arrived, and the gap nobody has time to chase.
Reconciliation is where most agencies quietly lose money, and it is lost in small amounts across many policies rather than in one obvious place.
- ExpectedWhat the arrangement for this insurer and product should produce on this premium.Pending
- ReceivedWhat actually arrived, usually as one payment covering many policies.Pending
- MatchedEach policy in that payment identified and reconciled against its expectation.Reconciled
- DiscrepancyExpected and received disagree. Somebody has to look, and now it is visible enough to be looked at.Discrepancy
Why this is genuinely hard, and not a reporting problem
An insurer remits in bulk. The statement, remittance advice or challan that arrives covers many policies at once and rarely lines up cleanly with your own records. Matching it is the work — and until each policy in a payment can be identified, no report about commission is trustworthy.
What that document is called and what it contains differs by insurer and by arrangement. A build maps the format the agency actually receives rather than assuming one, which is usually the first thing looked at when scoping.
- How are insurance commissions tracked and reconciled?
- By holding an expected amount against each policy from the arrangement that applies to it, then matching incoming remittances against those expectations policy by policy. Because insurers pay in bulk, the reconciliation is the real work: a payment covering many policies has to be broken down and matched before anything can be called received. What the system adds over a spreadsheet is that the difference between expected and received stays visible on the policy rather than being discovered at year end.
The question every buyer asks
A CRM knows the customer. This also knows the policy.
Both are real answers, and which one you need depends on where the work actually goes wrong.
A CRM
Right when the problem is winning business
- Leads and where they came from
- Contacts and companies
- A pipeline with stages
- Activities and follow-up
- What to do next on a deal
An insurance management system
Right when the problem is everything that happens after the sale
- Policies with terms, insurers and documents
- Renewals generated from the policy itself
- Processing state — what a case is waiting on
- Agent and sub-agent ownership
- Commission expected, received and reconciled
An insurance system contains CRM-shaped things — a lead is still a lead. What it adds is everything that only exists because the product is insurance, and that is roughly two-thirds of an agency’s working day.
- Does an insurance broker need a CRM or an insurance management system?
- A CRM is enough if the difficulty is winning business and the book is small enough that renewals and commissions stay manageable by hand. An insurance management system becomes worth it when the work after the sale is where things are lost — renewals nobody got to, cases stuck waiting on a document, commission that never quite reconciles. Most agencies feel the second problem before the first.
Where the line is
Four things this is not, and one of them is a regulated product.
Each is a real category with real vendors. Being clear about the boundary is more useful than implying it is all included.
- An insurer’s policy administration platformInsurers run core systems that issue and administer policies at scale. This sits on the intermediary’s side of that relationship — it manages the agency’s book, not the insurer’s.
- An underwriting or quote engineRisk assessment and premium calculation belong to the insurer. A build records what a policy costs; it does not decide what it should cost.
- Claims adjudicationA build can record that a claim exists, its reference and where it has got to, so the agency can answer a customer. Assessing, approving or settling a claim is the insurer’s process and its own regulated software.
- A consumer marketplaceComparing and buying cover online is a different product with a different buyer. This is the system the intermediary runs behind the scenes.
On compliance, plainly
Insurance intermediation is regulated, and what a specific intermediary must record, retain and control depends on their licence, their products, their insurers and their jurisdiction. Branditify makes no regulatory approval or certification claim on this page. What we do is establish which records, permissions, retention and activity history the intended workflow requires, as part of scoping, and build to that — which is a different thing from asserting compliance, and the only honest one.
- Does the system manage claims?
- Only to the extent of recording them. A build can hold that a claim was raised against a policy, its reference number and its current status, so anyone in the agency can answer a customer without phoning the insurer. Assessment, approval and settlement sit with the insurer and involve regulated processes and parties outside the agency, and nothing here should be read as doing that work.
Connecting to what already exists
What each system can actually give you, checked before anything is designed around it.
This is the question most likely to be answered optimistically by everybody except the system that has to provide the data.
- Insurer portalsWhat each one exposes varies from a documented interface to a downloadable statement to nothing at all.
- Broker platformsWhere an agency places business through one, what it can export is the constraint.
- Payment and accountingWhat arrived and when, which reconciliation depends on.
- Existing recordsWhatever the agency runs today, which is usually spreadsheets and is usually the largest source.
Where an insurer, broker platform or existing system exposes the required data or an interface, we confirm that interface before defining the connection. Where it does not, the workflow is designed around what genuinely arrives — often a file — rather than around an integration that was assumed.
- Can the system connect to insurer platforms?
- Sometimes, and it depends entirely on the insurer and on what your arrangement with them exposes. Some provide an interface, some provide files, some provide a portal a person logs into. Branditify claims no insurer integrations on this page — what each system can give you is confirmed during scoping, and the honest outcome is often that some insurers connect and others are handled as a file the system reads.
Getting what you already have into it
Everything you have is in a spreadsheet, and that is the normal starting point.
It is also the part of the project most likely to be underestimated, by us as much as by anybody.
- 01See what exportsWhat the current tools can actually produce, in what shape. Often less structured than remembered.
- 02Sample and read itA few hundred rows tells you more than a schema. This is where the surprises are.
- 03Map the fieldsWhich column is the customer, which is the policy, and what the ones nobody can explain contain.
- 04Clean and de-duplicateThe same customer under three spellings is the standard finding, and merging them is a decision the agency makes rather than the software.
- 05Load and verifyAgainst the source, by somebody who knows the book well enough to notice what is wrong.
Not every historical record moves cleanly and it would be dishonest to promise otherwise. Policies whose documents were never saved, terms that predate the current spreadsheet, and customers who exist only in a phone contact list are the usual three. What can be recovered is knowable in the first pass, and it is better to decide deliberately what to leave behind than to discover it later.
- Can existing policy data be moved from Excel?
- Usually most of it, and the first pass over a real export tells you which parts. The predictable difficulties are duplicate customers under slightly different spellings, policies whose documents were never filed anywhere, and history that predates whatever spreadsheet is currently in use. Deciding what to bring across is a business decision made early, not a technical one discovered late.
What the records should be able to answer
Not a dashboard. Six questions.
A report is only worth building if somebody acts on it. These are the ones an agency asks, and each is answerable only because the record underneath is connected.
- 01Which policies renew this month?The one everything else depends on.
- 02Which renewals have no owner?The ones that lapse.
- 03Which cases are waiting on a document?And who is chasing them.
- 04Which commissions are unreconciled?And how far back they go.
- 05What does this customer hold with us?Answerable only if the customer is one record.
- 06Which of an agent’s policies need attention?For the agent, not for a manager’s report.
Every one of these is a question about the record rather than a chart. Where an agency wants the analytical layer on top of it, that is its own piece of work.
Dashboards When the reporting itself is the project
What changes the size
What makes one insurance system larger than another.
Not the number of policies, which barely moves the build.
- Commission arrangementsOne rate across the book is simple. Rates varying by insurer, product and sub-agent, with splits, is the single biggest driver.Effect on scope: 3 of 3
- Agent hierarchyA flat team is straightforward. Sub-agents with their own visibility and commission are not.Effect on scope: 3 of 3
- ReconciliationWhether incoming remittances have to be matched policy by policy, and in what format they arrive.Effect on scope: 3 of 3
- Product linesEach line of business has its own fields, terms and renewal behaviour.Effect on scope: 2 of 3
- MigrationDecided by the state of the current records rather than their volume.Effect on scope: 2 of 3
- Customer portalWhether policyholders see their own documents and renewals, which is a second interface.Effect on scope: 2 of 3
- Insurer connectionsEach one is its own piece of work, and some are a file rather than an interface.Effect on scope: 2 of 3
- PermissionsHow much an agent may see beyond their own book — a commercial decision with a technical cost.Effect on scope: 1 of 3
What we need to scope one
How policies are tracked today, how renewals are chased, how commission is worked out and reconciled, and who is allowed to see whose customers. A real export of the current spreadsheet is worth more than any description of it.
Whose data it is
Your customer and policy records are yours, and so is the system built for you — the configuration, the commission rules, any code written for you and the accounts it runs on, handed over as agreed in scope. There is no per-policy fee and no licence to renew.
- What determines the scope of an insurance management system?
- Mostly the commission arrangements and the agent structure. A single commission rate across a flat team is a modest build; rates that vary by insurer, product and sub-agent, with splits and bulk reconciliation, is a substantially larger one. After that it is how many lines of business are in scope, the state of the records being migrated, and whether policyholders get their own view.
Background
Selected insurance & product work.
ELEVONE is this exact system, designed and built by Branditify. The other two are shown for what they document — an insurance-sector digital experience, and a shipped product with real operational state — and neither is broker operations software.
- Insurance brokers The industry view of who this is built for
- All work Every project, with what was delivered on each
Questions
Asked before commissioning one.
- Should we just buy off-the-shelf insurance software?
- Very possibly, and we would say so. Several established products serve Indian brokers well, and if your commission arrangements and workflow fit one of them, buying is faster and cheaper than building. A build earns its place when fitting your business to somebody else’s product costs more than building around how you actually operate — usually because of commission structure or sub-agent arrangements.
- Can policies be assigned to agents and sub-agents?
- Yes, and the system usually needs to hold two separate things: who sourced the business, which drives commission, and who owns the relationship now, which drives whose task list a renewal appears in. In many agencies those are different people.
- Can renewal reminders be assigned to a person?
- A renewal should generate a task on a named owner rather than appear on a shared list, because a shared list of expiries is a list nobody is accountable for. The task opens onto the policy so the conversation starts with context.
- Can it handle multiple lines of business?
- Yes, and each line brings its own fields, terms and renewal behaviour, which is why the number of lines in scope affects the build more than the number of policies does.
- Can customers see their own policies?
- Where a policyholder view is in scope. It is a second interface with its own permissions, so it is a scoping decision rather than something included by default — and Branditify already builds portals as a system in their own right.
- Can payment progress be tracked on a case?
- Yes, and it is usually one of the more valuable states, because "waiting on payment" and "waiting on a document" are the two answers that resolve most internal questions about why a case has not moved.
- Is this IRDAI compliant?
- That is not a claim any software vendor can make on your behalf, and treat it carefully when one does. Compliance obligations attach to you as an intermediary and depend on your licence, products and insurers. What a build can do is hold the records, permissions, retention and activity history your obligations require — established during scoping rather than assumed.
- What about security?
- Insurance records hold identity, contact and financial information, so permissions, activity history, retention and where data is stored are design decisions taken early. No certification is claimed on this page; what is offered is that those requirements are established with you before the architecture is settled rather than after.
- Who owns the data and the system?
- You do, and the practical test of that is whether somebody else could take it over. Ask for the handover to be defined in scope — accounts, records, configuration and readable code — because ownership that cannot be picked up by another developer is ownership on paper. It is a fair thing to ask any vendor, including us.
- How long does one take to build?
- It follows from the commission and hierarchy complexity and the state of the data being migrated, so it is scoped after seeing a real export rather than quoted before. Reading a current spreadsheet honestly tells you more about the timeline than any requirements document.
- What happens after it goes live?
- The first renewal cycle is the real test, because that is when the parts that were designed from description rather than observation show themselves. Planning for adjustments after the first cycle is more realistic than treating launch as the end of the project.
Start here
Bring us the policy workflow your team is holding together by hand.
The most useful first conversation is about renewals and commission — how they are tracked today, and where they go wrong. Those two answers shape most of the build.
- How policies are tracked today, and by whom
- How renewals are found and chased
- How agents and sub-agents are assigned
- How commission is worked out and reconciled
- What your insurers actually give you, and in what format
- What customers need to see for themselves