Insurance broker
The insurer went down. The business does not have to.
- ≈10,000
- policies issued every month
- up to a week
- sales can stall while a partner is unreachable
- 10,000+
- clients in the broker’s database
The pain
A broker sits between a person and a single insurer: takes the request, gets a price, issues the policy. When the partner goes down, nothing is quoted, nothing is issued, and sales across the whole network stall for up to a week.
On top of that, each of the ten thousand monthly policies is handled by hand: the same data entered again, a separate payment link sent for every product. Two items means two policies and four links. Clients get lost, reports are stitched together in spreadsheets, and renewals live in someone’s head.
Audit
We started with the process rather than the ageing technology, and walked the client’s path from the first question to issuing and renewing a policy. It turned out two separate pains needed two separate answers.
Automation removes the manual chaos: data entered once, a single order and payment, automatic reports and reminders. An aggregator removes the dependence on one partner: the platform queries several insurers in parallel, and if one is unavailable it turns to the others.
Not a chatbot. A platform
We designed one system for the whole of policy work: insurer quotes, clients, orders, payments, renewals and reporting. At its centre is the aggregator that collects quotes from different insurers. Around it sit a CRM, unified payment, analytics and an assistant for routine questions.
A manager enters the owner and vehicle details once, prices arrive in a single view, and the client gets one link or QR code instead of several.
The budget changed. The project did not
The platform was planned as six weekly sprints. After the second, the client’s finances changed and the remaining four could no longer be funded in full. Stopping would have left them with analysis, architecture and a skeleton, but no working product.
We went back through the feature list, separated what was essential from what could be added later, and rebuilt four sprints into two. Testing and documentation were not cut — only the scope of the first version was.
6 → 4 sprints−33 %1.5M ₽
Development shrank by a third: the modelled budget after the rebuild went from 2.25M ₽ to 1.5M ₽.
The remaining 20 % of the feature set moved to the next stage — nothing was thrown away, all of it is written down and ready to come back into the work.
BROKER.PRO is a stand-in for the brand name. Modelled at a nominal sprint cost of 375,000 ₽. The 80 % of retained functionality is the team’s own estimate. The actual project budget is not disclosed.
750,000 ₽
saved while keeping 80 % of the feature set
Got a problem? Let us take it apart.
You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
EmailTelegram channelMAX channel