The spreadsheet next to the system
You chose a policy administration system to launch quickly. It handles standard quotes, binding, documents and renewals well. Then your product did something slightly unusual: monthly cover that pauses, usage-based pricing, a policy covering a changing list of items, or a partner who needs a different commission split.
The system could not do it, so someone built a spreadsheet. The monthly usage is calculated outside and entered as a manual adjustment. The list of covered items lives in a Google Sheet. Commission splits are worked out at month end. Each workaround made sense. Together they mean a lot of the product actually runs outside the system of record.
How the workarounds pile up
Most policy administration systems are configurable within their model. Insurtech products are often designed to be different from that model.
- The product needs a data structure the system does not have, such as a schedule that changes weekly.
- Pricing depends on data the system cannot store or call.
- Customer journeys need events the system does not send.
- Partners need calculations or reports the system cannot produce.
- Configuration changes need the vendor's professional services, which take time.
When the workarounds start to hurt
Manual adjustments cause errors in premium, documents and bordereaux. Staff time goes on keeping spreadsheets and the system in step. Reporting to capacity providers depends on reconciling the two. Launching the next product feels risky because nobody is sure what the system can take. And replacing the whole system, the obvious fix, is a large and uncertain project in its own right.
Building around the gaps
What we build keeps your policy administration system as the record of policies and adds the missing pieces beside it.
- We list every workaround: what it does, who maintains it, what data flows in and out, and what breaks if it is wrong.
- With you, we sort them into gaps worth building around, gaps better fixed by vendor configuration, and processes worth changing instead.
- For each gap worth building, we write a small service that holds the extra data or logic, such as a covered items register or a usage calculator.
- The service talks to the system through its API, for example posting adjustments with a clear reference, rather than people typing them.
- Checks run daily to confirm the system and the service agree, and flag differences.
- Where the vendor can close a gap properly, we write up the requirement clearly so they can quote for it.
| Workaround | Common risk | Typical approach |
|---|---|---|
| Usage calculated in a spreadsheet | Wrong premium adjustments | Usage service posting adjustments by API |
| Covered items list in a sheet | Documents and claims use an old list | Items register linked to the policy |
| Commission splits at month end | Partner statements wrong | Commission service reading policy events |
| Custom documents edited by hand | Wording or data errors | Document service using system data |
| Manual pause or restart of cover | Cover dates wrong | Scheduled changes through the API |
Living with a system that fits better
Each gap now has an owner, a service and a daily check, not a spreadsheet and a person. The policy administration system stays the record your capacity providers and auditors rely on. Launching a new product starts with a clear view of what the system does, what the services do and what needs building.
If you do replace the system one day, the services and the documented gaps make the replacement much better defined.
Is your system being worked around?
- Parts of your product are run from spreadsheets.
- Manual adjustments are a regular part of the week.
- Staff say the system cannot do what the product needs.
- Bordereaux need reconciling with side spreadsheets.
- Replacing the system keeps coming up as the answer.