This is a paperwork automation case study about an insurance broker in Tangerang that was quietly choking on its own success. More clients meant more policies, more policies meant more documents, and more documents meant more things falling through the cracks. The team was busy, the owner was stressed, and nobody could tell you where any given policy actually was at a given moment.
I want to walk through this one carefully because the interesting part is not the technology. The interesting part is the diagnosis. When I started, everyone assumed the answer was "buy software." The real answer turned out to be roughly 30 percent software and 70 percent redesigning how work flowed through the office. If you skip the diagnosis and jump straight to a tool, you automate a broken process and make it faster at being broken.
The starting point: email and Excel as a system
The broker handled personal and commercial policies for a few hundred active clients. The "system" was email plus a shared Excel file. A client request arrived by email or WhatsApp. Someone printed or forwarded it. Details got typed into Excel. Supporting documents lived in inboxes, in a shared drive, and sometimes on someone's phone.
The symptoms were textbook:
- Policies stalled for days because nobody knew whose turn it was to act
- The same client detail was typed three or four times into different places
- The owner could not answer "how many policies are pending renewal this week" without an hour of manual counting
- When a staff member was on leave, their in-flight work simply froze, because it lived in their inbox
The team was not lazy. They were working hard inside a process that guaranteed friction.
The diagnosis: map where documents stall, not where they move
Before touching any tool, I spent two days doing something unglamorous: following documents. Not the happy path, the stalls. For a representative sample of recent policies, I traced exactly where each one sat, for how long, and why it stopped moving.
The pattern was clear. The bottleneck was not typing speed or headcount. It was handoffs with no owner. A document would arrive complete but sit for two days because it was unclear who was supposed to pick it up next. Renewals were the worst, because nobody owned the calendar; renewals were remembered, not tracked.
This is the step most people skip, and skipping it is why so many automation projects disappoint. If you map only where work moves, everything looks fine. You have to map where work stops. In this paperwork automation case study, roughly 70 percent of the elapsed time on a typical policy was waiting, not working.
The redesign: one intake, one pipeline, clear owners
With the stalls mapped, the fix mostly designed itself. Software supported the design; it did not lead it.
One structured intake. Instead of policies arriving as free-form emails, we put a simple web form at the front. Clients and staff entered requests into fields that matched what the process actually needed. No more hunting through email threads to reconstruct what someone wanted.
OCR for documents. Identity documents, existing policy PDFs, and vehicle papers were run through OCR so the key fields were extracted automatically instead of retyped. This was the one genuinely AI-flavored piece, and it mattered because retyping was both slow and a source of errors. Human review stayed in place, because OCR is confidently wrong often enough that you never fully trust it unattended.
A shared pipeline board. Every policy became a card that moved through clear stages: intake, verification, quoting, client confirmation, issuance, filed. Each stage had one named owner. Anyone could open the board and see, in five seconds, where everything stood.
A renewal view. Because dates now lived in structured data instead of memory, renewals surfaced automatically weeks ahead. This alone recovered revenue that had been leaking through lapsed policies nobody chased in time.
What changed, in numbers
I am wary of case studies that quote suspiciously round improvements, so here are plausible, honest figures from the first three months after rollout.
| Measure | Before | After |
|---|---|---|
| Average policy turnaround | 6 to 8 days | 2 to 3 days |
| Times a client detail was typed | 3 to 4 | 1 |
| Owner time to get a pipeline status | ~1 hour | seconds |
| Renewals missed per month | several | close to zero |
The turnaround improvement did not come from anyone working faster. It came from removing the waiting. Once handoffs had owners and everything was visible on one board, work stopped sitting idle.
Why the 70 percent matters more than the 30
If this broker had simply bought a shiny insurance CRM without the diagnosis, I am confident it would have failed. The team would have kept their email habits, entered data twice, and blamed the tool. The tool would have automated the intake but left the ownerless handoffs untouched, which were the actual problem.
The workflow redesign is what made the software stick. We decided who owned each stage, killed the duplicate data entry, and made status visible before we automated anything. The software then made the good process easy to follow. This is the same lesson behind Change Management: Why Staff Reject Your New Software: tools succeed when the process underneath them is sound and the team helped shape it.
It is also a reminder that a company's real constraint is rarely a missing feature. It is usually accumulated process debt, the operational cousin of the code problem I described in Technical Debt Explained for Non-Technical Owners.
The practical takeaway
If your back office is drowning in paperwork, resist the urge to buy software on day one. Spend two or three days first following your documents through their stalls. Ask, for real cases, where work stops and why. You will almost always find that the bottleneck is ownerless handoffs, duplicate data entry, and things tracked by memory instead of by system.
Fix the process, then let software make the fixed process effortless. In this paperwork automation case study, that sequence turned a stressed, opaque operation into one the owner could see and trust, and it cut turnaround by more than half without hiring a single extra person. If you want help running that diagnosis on your own operation before spending on tools, that is the kind of work I do as a technical partner.