Case Study Details
Client: Global insurance company (name withheld under NDA)
Industry: Insurance
Service: System Automation & Modernization
Engagement length: 6 weeks diagnostic, 12 weeks redesign and rollout
The Problem
By the time they came to us, this company had just wrapped an 18-month modernization program on their core underwriting systems — and by every technical measure, it had gone well. Core services had been broken apart and containerized. Legacy point-to-point integrations had been replaced with proper APIs. Databases had been refactored and moved to the cloud. On paper, and in every steering committee update along the way, the project was a success.
Inside the business, almost nothing had changed. Cycle times hadn't meaningfully improved. Manual approvals were still sitting in the same places they'd always sat. Exception queues — cases pulled aside for manual review — hadn't shrunk. If anything, they'd grown, because the same volume of work was now arriving faster at the same manual bottlenecks. Their VP of Operations, who we'll call the VP of Operations throughout this case study, put it bluntly when we first spoke:
"We spent eighteen months and a serious budget making the system faster at executing, and it turns out we never touched why it was slow at deciding. We modernized the plumbing and left the actual problem exactly where we found it."
The program's underlying assumption — reasonable, and one most modernization efforts share — was that better infrastructure would produce better performance. More scalable systems, more flexible integrations, faster data access. That assumption held for raw system throughput. It didn't hold for the business outcome anyone actually cared about, because the real constraint had never been where the system ran. It was how it decided things.
What We Did First: Reframe the Question
We didn't start by looking at services, containers, or API response times — all of that had already been handled well by the prior modernization effort. Instead, we mapped the underwriting workflow end-to-end around a different unit of analysis entirely: decision points. Not "which service handles this," but "why does this case get escalated," "what condition actually triggers manual review," and "does that condition still make sense."
That reframing mattered, because it surfaced something the infrastructure project had never questioned: a large share of the workflow wasn't actually complex. It was unexamined. Static risk thresholds that had been set years earlier and never revisited. Escalation paths built around organizational hierarchy rather than the actual risk profile of a case. Human sign-off required on categories of cases that, in practice, followed extremely predictable, low-variance patterns — same inputs, same outcome, every time — but were still routed through a person as a matter of inherited process rather than genuine need.
The modernization program had faithfully preserved every one of those decision rules. It had just made them run on newer infrastructure.
What We Tried First (And Why It Wasn't Enough)
Our first instinct — the same instinct that had driven the original 18-month program — was to look for performance gains within the existing structure: reducing queue latency through better orchestration, improving responsiveness across the newly-built APIs, parallelizing pieces of the approval workflow that were currently running in sequence.
These changes produced small, measurable improvements at the margins. They did not change outcomes. Manual reviews still existed exactly where they'd existed before, because the decision logic sitting on top of the infrastructure hadn't moved. It became clear that no amount of orchestration or parallelization was going to fix a problem that lived one layer above the infrastructure entirely.
What We Built
The actual redesign came from separating two things that had been treated as one: predictable, low-variance logic, and genuine judgment calls that legitimately needed a person.
Working with their underwriting team, we quantified how much of the approval volume actually fell into the predictable category — and it was substantial: a large portion of cases were following the same input-to-outcome pattern reliably enough that routing them through manual validation added time without adding safety. From there, we rebuilt the decision layer directly:
- Automated risk scoring for predictable cases, replacing manual sign-off with a scoring model for the categories of cases that had demonstrated consistent, low-variance outcomes.
- Replaced static thresholds with adaptive, context-aware rules, so the system's decision boundaries reflected actual current risk patterns instead of numbers set years earlier and never revisited.
- Removed redundant escalation paths that had been inherited from the legacy process and carried forward into the new architecture without anyone questioning whether they were still necessary.
- Restricted human review to genuine edge cases — the ones that actually varied, actually carried ambiguity, and actually needed a person's judgment rather than a rubber stamp.
This wasn't automation layered on for its own sake. It was a restructuring of which decisions needed a human in the loop at all, built on top of the solid infrastructure the earlier program had already put in place.
The Impact
- Processing times dropped substantially — not because the underlying computing got faster, but because a large share of unnecessary manual decisions simply stopped happening
- Exception queues shrank significantly, since the predictable cases that had been quietly filling them no longer required manual validation to move forward
- Underwriters shifted from repetitive sign-off work to genuine risk evaluation on the cases that actually warranted their judgment — a better use of specialized staff, not just a faster process
- The infrastructure investment from the original 18-month program finally started paying off, because the decision layer sitting on top of it had been rebuilt to actually take advantage of it
The VP of Operations summarized the lesson that stuck with their leadership team afterward:
"The infrastructure project wasn't wasted — we needed it. But it taught us the hard way that migrating a broken decision process onto faster infrastructure doesn't fix the decision process. It just makes the same inefficiency run at cloud scale. Nobody had asked which decisions actually needed a human until you did." — VP of Operations
This case study reflects a real client engagement. The client's name and identifying details have been withheld in accordance with a confidentiality agreement; the VP of Operations' title is used in place of a name for the same reason.