Lead
Online Application not yet submitted
eLead Offer not yet confirmed
← All work
IGNITE / LEAD MANAGEMENT / CASE STUDY 02
Bringing Offline Insurance Enquiries into Ignite
Ignite is a digital sales platform for insurance agents. Its existing purchase flow mainly covered products that could be quoted directly online, but not every insurance need could be priced through a standardised form.
With eLead, we brought enquiries previously handled offline into Ignite. Agents could submit a need, receive Offers from insurers, and continue through payment and policy issuance.
Design challenge
How could we bring an enquiry process that depended on offline coordination across multiple roles, involved complex statuses, and had many exceptions into Ignite without passing all that complexity on to Agents?
01 / SERVICE CONTEXT
Insurance needs that instant quotes could not cover
Employee Benefit, Marine, and high-sum-insured Property needs often required insurers to quote against a client's specific risks. Even where the platform offered a product in the same category, an Agent might not find a suitable option for the client.
Previously, Agents submitted details offline. Placement contacted one or more insurers, discussed underwriting terms and premiums, and returned the Offers to the Agent. One need could go through several rounds of additional information and negotiation, or receive several Offers at once. Placement and Admin also relied on Excel trackers to record and follow up on progress.
One Lead represents an insurance need to be resolved; one Offer represents an insurer's proposed terms for that need. Specialist discussions can still happen offline, but their outcomes need to return to the system so the next action has a clear basis.
SERVICE CHAIN
- Submit a need
- Manual enquiry
- Receive multiple Offers
- Choose an Offer
- Continue the transaction
The Agent submits the need and confirms an Offer; Placement seeks quotes and organises the Offers; the relevant Admin roles take over subsequent review, payment, and policy issuance. The homepage provides Personal Line and Commercial Line entry points for online quotes and manual enquiries respectively: products that can be quoted directly online follow the existing Online flow, while needs requiring manual enquiry are submitted through eLead. The paths arrive at a price in different ways, but Agents still need to find each transaction in Ignite, understand its progress, and complete the next action. In designing eLead, I needed to decide which existing rules could carry across and which differences in manual enquiries had to remain.
02 / BUSINESS ALIGNMENT
Using Online milestones to define where eLead differs
Before designing screens, I looked for business milestones I could compare across the two paths. Ignite's Online status diagram covered quotes, applications, payment, and policy issuance, but mixed business objects, user actions, and transition conditions. Matching eLead to it by status name could make actions with similar labels appear equivalent when they meant different things.
I used business object, triggering action, responsible role, entry condition, and next action as comparison dimensions, and used AI to turn the Online diagram into a structured reference that could be checked against its source. I then compared it with the manual enquiry flow to judge when a need began to be followed up, when an Offer was confirmed, and when the transaction could move forward.
| Shared business meaning | Online | eLead |
|---|---|---|
| Start a need that can continue to be followed up | Submit a Quote | Submit a Lead |
| Confirm an Offer and proceed with the transaction | Submit an Application | Agent confirms an Offer |
| A payment succeeds | Payment Success | A one-off payment succeeds; with installments, one installment is Paid while the overall transaction may still have payments due |
When an Online Application is submitted, the price has already been calculated. When an eLead Lead is submitted, there is no price yet; staff still need to obtain an Offer. The Offer and premium are only established after an Offer is returned and confirmed by the Agent. I therefore mapped confirming an Offer to submitting an Application, rather than matching the actions by the word “submit”.
These relationships compare business stages. They do not mean the paths share status names or review and payment rules. Page groupings by progress still depend on each path's own triggering conditions. AI organised the existing flow into material I could compare; I judged the business meaning, kept the necessary differences, and brought questions without a clear basis back to the PM.
03 / MODEL THE COMPLEXITY
Keeping overall progress consistent with child states
The shared milestones between Online and eLead established a basic path, but could not describe the full transaction. One Lead can have several Offers progressing independently; with installments, each payment under a Policy also changes independently. I needed to decide what the overall record should show, when a child object's change should affect it, and what the Agent could do next.
MODEL 01 / LEAD & OFFER
One Lead, multiple Offers progressing independently
One Lead expresses the progress of an insurance need, while each Offer retains the independent status of an insurer's proposal. Placement may advance several Offers at once, so the Lead cannot simply adopt the status of one of them. It needs to convey whether the need is being handled and whether the Agent has an Offer to review or another action to take.
Changes to Offers do not all have the same effect on the Lead. When an Offer is available to review, the Lead should help the Agent discover it. Once the Agent confirms one Offer, that irreversible choice determines the subsequent transaction and the other Offers become invalid. The design decision is which changes to a child object affect the progress of the whole need or its next action, rather than displaying every Offer status on the Lead.
MODEL 02 / PAYMENT
Separate overall payment progress from each installment
The Policy expresses the payment progress of the whole transaction. Without installments, the result of one payment can be reflected directly on the Policy. With installments, each payment changes independently, while the Policy must summarise whether the transaction still has payments due.
One successful installment therefore cannot make the whole transaction appear fully paid. The list shows the Policy's overall progress so the Agent can see whether the transaction still needs attention; the detail page then shows each installment's amount, due date, payment result, and related commission, helping the Agent find the next payment to address. The same principle applies to Lead and Offer: the parent conveys the transaction's overall progress, while children retain their own states; a child changes the parent's presentation when it affects the overall judgement or next action.
VALIDATION / AI CHECK
Using AI to check the cross-role flow
Lead, Offer, and Payment in eLead move forward asynchronously through different roles. Individual status diagrams can explain their own transitions, but cannot guarantee that the overall progress, owner, and available actions the Agent sees still match the transaction when events overlap. Before finalising the pages, I used AI to explore sequences based on status conditions, role responsibilities, and page actions. I then reviewed boundary scenarios with the PM and engineers and turned the valid issues into design constraints.
| Scenario checked | My design constraint |
|---|---|
| Parallel Offers: One Offer is ready for review while others are still being processed | The Lead surfaces the actionable Offer; after the Agent confirms one, the others become invalid and the selection action closes |
| Payment delay: A payment has been submitted, but the result has not returned and the page still offers another payment action | Show a “Processing” status, control the repeat-payment action, and make clear how the result will be updated |
| Additional-information handoff: The insurer requests more information, while the Agent and Placement see different progress and no one clearly owns the next action | Show the reason for the pause, the current owner, and the conditions for resuming consistently, so the task returns to the right role |
04 / SALES EXPERIENCE
The underlying model should not become a learning burden for Agents
An accurate underlying model is necessary, but Agents should not have to learn the internal relationships between Lead, Offer, Payment, and Policy before finding a transaction and its next action. The original Sales page grouped records by Quote and Policy, each of which already contained many statuses. Adding Lead, Offer, and installments as further object-based categories would make finding a transaction increasingly dependent on understanding the system's internal structure.
I found a way to judge progress that both paths could share: submitting an Online Application or confirming an eLead Offer means an Offer has been selected and the transaction has moved on. After that, I also needed to know whether the Agent still had an action to complete. The first successful installment payment changes one installment's status; it does not mean the whole transaction is finished.
I therefore proposed regrouping the original Quote / Policy categories into Lead / In Progress / Sales based on progress Agents can recognise, and aligned the proposal with the PM:
In Progress
Online Application submitted; Agent still has an action to complete
eLead Offer confirmed; Agent still has an action to complete
Partly Paid installments with later payments still due remain here
Sales
Online / eLead The Agent's required actions are complete; nothing currently needs their attention
Subsequent Admin work and policy issuance statuses remain visible
Lead / In Progress / Sales are page stages, a different layer from the underlying Lead object or a Lead In Progress status. The page stage helps Agents find a transaction; the record status explains what is happening; the next action shows how to continue.
One successful payment does not determine the page stage on its own. As long as the Agent still has later payments to complete, the transaction stays In Progress. In Sales, the Agent has no outstanding action, but Admin may still be processing or issuing the Policy. The structure preserves necessary differences in the underlying flow while letting Agents find records by progress, understand their current situation, and continue. I did not remove the business complexity; I placed it at the appropriate level.
05 / RESULT
Manual enquiries become part of Ignite's daily operations
eLead has launched. The Placement and Admin teams' manual-enquiry records and follow-up work, previously managed in Excel trackers, moved into Ignite's business flow. Specialist enquiries and negotiations can still happen offline where needed, but the need, returned Offers, and processing progress come back to the same Lead so different roles can continue working from one business record.
Offline work disconnected from platform records
Enquiries, Offers, and handoffs happened outside the online flow.
Offline handling, with context kept online
Details, Offers, and outcomes return to the same Lead after each handoff, so the Agent can continue.
REFLECTION
Making complex business understandable to both teams and users
This project made it clearer to me that design work in a complex business does not happen only on screens. My core contribution was to organise business knowledge scattered across roles and offline processes into a structure the team could align around, the system could implement, and users could understand.
The challenge is more than documenting every status. When Offers progress in parallel, payment is pending, or work passes between roles, everyone needs to understand what has happened, who is responsible, and how the process can continue.