A referral email with a quote number in it
A customer fills in the quote journey. Something in their answers, perhaps a claims history, a property type or a business activity, is outside what your rules let the system accept automatically. The rating engine marks the quote as referred and sends an email to the underwriting inbox.
The underwriter opens the email. It has a quote number. They log in to the policy administration system, find the quote, read the answers, look for the rule that fired, maybe check an external data source, and decide. They then update the quote, or ask a colleague to, and email the customer or broker. If it is a busy day, the referral waits until tomorrow. The customer has already quoted elsewhere.
Why referrals are slow
The referral step is often the least developed part of an insurtech's platform, because the goal was straight-through quoting.
- The notification carries a reference, not the information the underwriter needs.
- The rule that caused the referral is not always recorded in a readable form.
- Underwriters work from a shared inbox, so ownership is unclear.
- Past decisions on similar risks are not easy to find.
- Decisions are written back to the quote by hand, sometimes by someone else.
Which risks you refer and how they are decided is your underwriting team's judgement within the authority your capacity provider gives you. We do not make those decisions.
What slow referrals cost
Referred risks are often the more interesting, more valuable ones, and the ones most likely to be shopped around. Waiting loses them. Underwriters spend time on lookups instead of judgement. Decisions on similar risks drift apart because nobody can see the last one. And if your capacity provider asks how referrals are handled within your authority, the evidence is spread across emails.
A referral queue for underwriters
What we build turns referrals into cases underwriters can work quickly and consistently.
- When the rating engine refers a quote, a referral case is created with the full risk details, the customer's answers and the rules that fired, in plain words.
- External data you already use, such as property or vehicle lookups, is shown on the case.
- Similar past referrals and their outcomes are listed, so the underwriter can see how comparable risks were decided.
- Referrals are routed by product, value and the authority level they need, and each has a named owner.
- The underwriter accepts, accepts with adjusted terms such as an excess or endorsement, or declines, choosing from your own options and adding a reason.
- The decision is written back to the quote in your policy administration system through its API, and the customer or broker is notified with the result and a link to continue.
- Age, volume and outcomes by rule are reported, so the underwriting team can review rules with real data.
| Referral reason | Case shows | Typical decisions available |
|---|---|---|
| Claims history outside rules | Declared claims and dates | Accept, add excess, decline |
| Property or vehicle type | Lookup data and customer answer | Accept, add endorsement, decline |
| Sum insured above auto limit | Sum insured and your authority level | Accept within authority or escalate |
| Business activity not listed | Activity description | Accept, amend activity, decline |
A referral day that keeps pace
Underwriters start with their own queue, sorted by age. Each case has what they need to decide. Decisions reach the customer quickly, with a link straight back into the journey. Senior underwriters see escalations with the full case attached. The data on outcomes by rule shows which rules refer risks that are almost always accepted, which the team can review.
Does your referral process look like this?
- Referrals arrive as emails with a quote number.
- Underwriters log in to the policy system to read each risk.
- The rule that caused the referral is not obvious.
- Customers wait a day or more for a referral decision.
- Nobody can see how similar referrals were decided.