Insights
Insurtech product design means showing the consequence before the commitment: what a quote excludes, where a claim stands, whether a payout is final. Insurance software is arithmetic and obligation shared between a carrier, its producers, the policyholder and the operations staff in between, and many of the numbers it
Insurance software is arithmetic and obligation shared between a carrier, its producers, the policyholder and the operations staff in between, and many of the numbers it shows are provisional. Good insurtech product design shows the consequence before the commitment: what a quote does and does not include, where a claim stands and what happens next, whether a payout is final, and how far one configuration change will reach. In our view, the hardest of those problems sit in the carrier and distribution tools behind the policyholder's quote and claim screens, where one edit can reach many workflows and real money.
This guide is about designing insurance software. Designing the insurance product itself (cover, rating and terms) belongs to actuaries and underwriters, and nothing here is legal or regulatory advice.
| Moment | Who commits | What they need to see first |
|---|---|---|
| Quote | The buyer, or a producer acting for them | Whether the price is an estimate or one they can buy at; what is excluded; what would change it |
| Claim | The claimant | The stage, what evidence is still needed and why, what happens next and how to challenge a decision |
| Payout | Carrier operations, and the producer who is paid | Whether the figure is final, waiting on something or due to be recalculated; who changed it by hand and why |
| Configuration change | A carrier administrator | Every workflow and message the change will reach, and anything it would break |
| AI output | An underwriter or claims handler | That it is a recommendation, the evidence about this case, and how to override it |
What makes insurance software different from other fintech
At Tcules, our first-hand record in insurance is in producer compensation and communications, from our work with Chestnut. The quoting and claims sections below rest on regulators' own texts and published research, and on our reasoning from them; we say which is which. What all financial products share (money states, the way back from a mistake, compliance built into the flow) is covered in our fintech UX guide. Four things are particular to insurance.
The promise is tested later. A payment shows whether it went through soon after it is made. An insurance policy is a promise about an event that may happen months or years after purchase, so the moment the buyer learns what the quote really covered can be the claim. That is our inference, and it is why exclusions belong at the quote rather than in the policy wording alone.
More parties see different slices of one record. A carrier, an agent or broker (US law calls them producers), the policyholder, a claimant who may not be the policyholder, and operations staff all act on the same policy, each with different authority.
Numbers stay provisional for a long time. A premium can change after underwriting checks, a claim can be accepted in part, and a commission depends on a policy that can still change.
Licensing gates the money. The NAIC Producer Licensing Model Act (NAIC text dated 2005), a model that US states adopt in their own versions, bars an insurer or producer from paying commission to a person who must be licensed and is not (Section 13A). It also allows renewal or other deferred commission to a person who was licensed at the time of the sale, solicitation or negotiation (Section 13C). Our inference for the interface: a payout screen has to know a producer's licence status on the date of the sale, not only today.
Quoting: an estimate must not read as a price you can buy at
A quoting flow can show a price before the answers behind it have been checked. The design problem is to keep that indication from reading as the price the insurer will actually put the cover on at. At Tcules, our recommendations here are reasoning from the sources below, not from our own quoting work.
Name the state in words. "Estimate, may change after we check your answers" and "Price you can buy at, valid until a stated date" are different promises. Show what would move the estimate, and which answers are still unchecked.
Put the exclusions beside the price. How cover is described can change what people choose. In a series of studies, Johnson, Hershey, Meszaros and Kunreuther found that framing manipulations led consumers to make hypothetical insurance choices that violate basic laws of probability and value, and that subjects showed framing effects when evaluating premiums and benefits (Journal of Risk and Uncertainty, 1993). The choices studied were hypothetical (the authors add illustrations from real insurance markets), so they show a tendency, not a measured effect in your funnel. The design consequence we draw is that a headline price should not be separated from the exclusions, excess and limits that change its meaning.
Comparison is still hard for buyers. In the UK, the FCA's response to the Which? super-complaint on home and travel insurance, published on 18 December 2025, said 31% of consumers say there isn't enough information to judge the quality of different policies, and the FCA set itself work to improve consumer understanding of what their insurance covers. A quote screen that compares on price alone leaves that gap open.
Treat a required disclosure as a step with a record. India's insurance regulator, IRDAI, in its Master Circular on Health Insurance Business of 29 May 2024, requires insurers to design proposal forms in simple language and to forward a Customer Information Sheet in the specified format and obtain the policyholder's acknowledgement. In a digital journey, that acknowledgement is a moment to design and record, not a checkbox buried under the payment button.
Claims: status a claimant can act on
On claims, regulators are specific about what the claimant must be told, and their wording reads like interface requirements. At Tcules, we base this section on public sources and our reasoning, not on our own claims work.
- United Kingdom. The FCA's rule ICOBS 8.1.1R requires an insurer to handle claims promptly and fairly, give reasonable guidance to help a policyholder make a claim and appropriate information on its progress, not unreasonably reject a claim, and settle promptly once settlement terms are agreed.
- California. Under the state's Fair Claims Settlement Practices Regulations, 10 CCR 2695.7, an insurer must accept or deny a claim, in whole or in part, no more than 40 calendar days after receiving proof of claim (a few lines, such as disability insurance, are excepted from that clock). If it needs more time, it must say so in writing, specify the additional information it requires and the reasons it cannot yet decide, and repeat that notice every 30 days. A written denial of a first-party claim must list every basis for it and, where it rests on a policy provision, condition or exclusion, refer to it and explain how it applies; and the written notice must tell a claimant who believes the claim was wrongly denied that they may have it reviewed by the California Department of Insurance, with the address and telephone number of the unit that reviews claims practices.
- India. For health insurance, the same IRDAI master circular requires a decision on a cashless authorisation request within one hour and final discharge authorisation within three hours, with any extra hospital charge from a longer delay borne by the insurer. When a claim is rejected or partly disallowed, the claimant must be given the details with reference to the specific policy terms, and insurers and third-party administrators collect the documents from the hospital rather than asking the policyholder for them.
Read together, these give a claims interface its shape. This is our synthesis, not any one regulator's list:
| The claimant's question | What the screen shows |
|---|---|
| Where is my claim? | A named stage, who holds it now, and the date the next decision or update is due |
| What do you still need from me? | Each missing item, why it is needed, and whether someone else (a hospital, a repairer) is supplying it instead |
| What has been decided? | Accepted and declined amounts line by line, each tied to the policy term it rests on |
| What if this is wrong? | The route to challenge it, including an outside reviewer where one exists |
The same clocks belong in the handler's tools. A queue that shows how long each claim has before a required notice is due lets the insurer see a deadline coming, rather than learn about a missed one in an audit. Most claimants are satisfied, at least in the UK: in the same December 2025 statement, the FCA reported that 79% of consumers who make an insurance claim are satisfied with how it was handled. In our view, the design effort pays most in the exceptions: partial acceptance, missing evidence and disputes.
Behind the policyholder screens: producer pay and required communications
At Tcules, we worked as an embedded design partner with Chestnut for about thirteen months, alongside its own product, design and engineering teams, and built the front end ourselves on some modules. Chestnut is a producer performance platform for insurance carriers: commission schedules, bonus programmes, hierarchies, holds on earnings and the compliant email that goes out around all of it. The engagement concluded in August 2026. The case shows product decisions and how they were built, not usage or business results, so we claim no outcomes here.
Three questions ran through the work: what will this change reach, can this number be trusted yet, and what will actually happen to the money?
Say whether a payout is final. Recalculating a payout on demand is costly, so we did not present every figure as settled. Each payout says where it stands: Needs Recalculation when an input has changed, Blocked when an earlier payout is still awaiting approval. Overrides, where an operator sets an amount by hand, require a reason and leave an audit trail.
Let a bonus lead with what matters in its current state. A bonus is configured once and then pays out against live policy data for months. In draft, setup is the page and Publish leads. Once live, payouts come first and setup sits behind a single button.
Keep different holds as different flows. A producer hold stops the final payout, so its release can show exact amounts. A policy hold stops earnings much earlier, and the exact figure after debt repayment is costly to calculate across a producer hierarchy, so the policy hold release shows an estimate that says plainly it excludes debt payoff. Both releases ask what should happen to the held funds before anything is confirmed.
Design the messages carriers must get right. Carriers send producers email they are required to get right, such as licence-expiry notices, welcome messages and debit-balance notices; a wrong or empty message lands with a real producer. The details in each email come from the workflow that sends it, so we made the trigger, the event that explains why a message is sent, the intent behind every message, and the right details follow from it.
Disclosure runs through distribution too. The NAIC model act's compensation disclosure section (Section 18) applies to a producer who is paid by the customer for a placement, or represents the customer in it: before the purchase, the producer must obtain the customer's documented acknowledgement and disclose the amount of compensation it will receive from the insurer or another third party for that placement and, when the amount is not yet known, the specific method for calculating it and, if possible, a reasonable estimate. An estimate that says how it was made is a pattern insurance already asks of its own people.
One change, many workflows: show the reach before publishing
In carrier tools, one edit can reach many workflows. At Tcules, we kept Chestnut's deliberate choice of one live version and one draft per template, with no version history, because it keeps the product easy to run. The design paid for that simplicity at two moments. The template list shows how many workflows each template feeds, and a Usage view lists every dependent workflow; it began as an analytics table, and the run and success-rate columns were removed because its real job is a safety check. Publishing names every affected workflow, and is blocked, with the mismatched details listed, when a template's variables no longer match what a workflow provides. Archived workflows are flagged instead of quietly hidden.
The general rule for carrier and distribution tools: before a configuration change goes live, show who and what it will reach, and block what it would break.
When AI enters underwriting or claims
Regulators have started to say what AI in insurance decisions owes the people affected, and each statement implies something on screen.
- The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted on 4 December 2023 for states to issue, expects an insurer's AI programme to give notice to affected consumers that AI systems are in use, with access to information appropriate to the stage of the insurance life cycle. It asks insurers to scale their controls to, among other things, how far humans are involved in the final decision and how transparent and explainable outcomes are to the consumer.
- The EU AI Act classes AI systems for risk assessment and pricing of natural persons in life and health insurance as high-risk (Annex III, point 5(c)). Its human-oversight article (Article 14(4)) requires such a system to be provided so that the people assigned to oversee it are able, as appropriate and proportionate, to stay aware of automation bias, interpret its output correctly, and disregard, override or reverse it. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026 moved the date those high-risk obligations apply for Annex III systems to 2 December 2027.
- In the US, a memo of 6 February 2024 from CMS, the US federal Medicare agency, told Medicare Advantage plans that an algorithm may assist coverage decisions but that a length-of-stay prediction alone cannot be the basis for ending post-acute care; the individual patient's condition must be reassessed first. That applies to one programme, but it states the principle plainly: a prediction about people like this claimant is not a decision about this claimant.
For an underwriting or claims interface, that means four things: label the output as a recommendation until a person with authority accepts it; put the evidence about this case beside it, not only a score; make override a first-class action that asks for a reason; and keep a record that shows later who decided and on what. At Tcules, we cover the patterns in our guide to human-in-the-loop UX, so we won't repeat them here.
Who designs insurance software, and what to ask them
Insurance software is designed by insurers' own product teams, by the teams at the platform vendors that sell core and distribution systems, and by outside design partners working inside those teams. Whoever does it, these questions separate experience with insurance screens from experience with insurance products:
- Have they worked on the carrier and distribution side, or only on policyholder quote and claim screens?
- Do they start from the running product, the codebase and the specs, or from a fresh design file?
- How do they show a number that is not final yet, and a change whose reach is wider than it looks?
- Who keeps legal interpretation, underwriting and regulated policy? It should be you.
- Can they show where their evidence ends? A case that claims usage or revenue results should be able to back them up.
We are Tcules, a digital product design studio creating ambitious new software products and making established ones better. We were founded in 2017 and are based in Ahmedabad, India. On insurance work, our clients keep legal interpretation, regulated policy, underwriting, data ownership and final production approval, and we design the roles, states and recovery paths around them; our FinTech and InsurTech expertise covers how we work on financial and insurance products. Audits and pilots have a fixed price agreed before we start; defined projects are priced on their agreed scope. For record-heavy carrier tools, our enterprise UX principles cover the workflow side in more depth.