Case one: embedded income protection for gig workers
A two-wheeler mobility platform in South East Asia. Live.
Riders using the platform's daily-pay battery-swap service had no realistic route to income protection. Conventional products were too large, too slow to buy and sold somewhere the rider never went.
The structure. Four parties in production: the platform as distributor, a global broker, a global carrier providing underwriting and capacity, and Gangkhar as the embedded platform running orchestration and hypercare.
What we built. Cover is bought inside a panel in the platform's own app, and the premium is collected through the wallet the rider already uses for battery swaps. No separate checkout, no redirect, no second login. The product is daily-pay and fixed-benefit, with payout the day after a valid claim. Reconciliation runs on a standard model across policies issued, gross premium, partner share, insurer deductions and payment timing, built for daily-pay micro-premium economics.
The timeline.
| Technical kickoff to functional design approved | Under four weeks |
| User acceptance testing | Five days |
| Technical kickoff to live | About six weeks |
Ahead of that sat roughly nine months of work that had nothing to do with technology: originating the use case, aligning four parties and structuring the regulatory and contractual position. Worth saying plainly, because the six weeks is the build, not the whole journey.
What happened after launch.
The first policies were issued during the launch period.
18,295 policies issued in the first five weeks.
Around 523 new lives covered per day across that period.
Platform performance. Quotation returns in under 500 milliseconds at the 95th percentile, issuance completes in under two seconds, and support availability runs at 99.9%. A rider buys cover in the time it takes to tap twice.
Why it matters beyond this case. Micro-premium protection only works if the cost of selling and servicing it is close to zero. This is the proof that the economics close.
Case two: back-office operations for a tier-one carrier
A global carrier's accident and health and motor business in Latin America, delivered with a global claims and TPA partner as prime contractor. Live and scaling in phases.
Where it started. The operation had not kept pace with the book it was serving.
| Baseline before we started | |
|---|---|
| Quotes reaching the underwriting desk | Fewer than 100 a month, each assembled by hand |
| Certificates cancelled or reissued for missing or bad data | Around 30% |
| Policy issuance | Three to five business days |
| First-offer conversion | About one in ten |
What is contracted. Ten operational modules across the policy lifecycle and more than 200 active products, on the carrier's existing systems of record. Sherpa+ holds the product suite, rate tables and coverage catalogue as configuration. The design assigns eight governed agents across enrolment, validation, coverage mapping, premium rating, reconciliation and broker notification. Sherpa+Lens is planned for a later phase covering renewals and collections optimisation.
What it is contracted to deliver.
| Baseline | Contracted | |
|---|---|---|
| Issuance time | 3 to 5 business days | Real-time |
| Certificate error and reissue rate | ~30% | Material reduction through validation at intake |
| Automatic reconciliation | Manual | Above 98% |
| Standard servicing | Manual | Above 90% touchless |
Governance runs on three tiers: a fortnightly operating committee, a monthly service committee against the service levels, and a quarterly executive committee for scope and roadmap. Every automated process keeps a documented manual fallback through the transition.
Why it matters beyond this case. Errors at intake are the most expensive thing in an insurance operation, because a cancelled certificate is not only lost premium. It is rework, and rework consumes the same underwriting hours that would otherwise have quoted new business.
What the two cases have in common
Neither required a core replacement. Neither required a capital approval cycle. Both started on one process and extended from there. And in both, the agents are checking their work against live product rules rather than a written procedure, which is what keeps accuracy from decaying as the product changes.
Frequently asked questions
What made the six-week launch possible?
The product layer was built before the agents. Coverages, parameters, rules and pricing are configured rather than coded, so functional design was approved inside four weeks and the build had a single reference to work against.
What is the fastest you have gone live?
About six weeks from technical kickoff, on case one. Enterprise back-office programmes run in phases across quarters.
Would this work for a smaller book?
The pattern holds wherever rules exist, exceptions are frequent and the product changes. Very small or genuinely static processes are usually better served by simpler automation, and we will say so.
What would it cost us?
Pricing is set case by case, against the scope of work and what it costs you to run today. We put a number to it during scoping.