Case Study — InsurGuide

From ad-hoc decks to a schema-driven intake platform — for a top-5 big-tech last-mile delivery business

InsurGuide is the internal platform country Program Managers, Risk Managers, and Risk Ops Admins use to stand up insurance coverage for two delivery programs — DSP (partner fleets) and FLEX (gig drivers). The design problem wasn't one form; it was a schema system that lets one platform serve 150+ country × program combinations without a release each time the business shifts.

Client
Top-5 Big Tech · Last-Mile Delivery
Industry
Logistics — Risk & Insurance Ops
My Role
Product Designer (E2E)
Timeline
2022–2023
Team
2 Designers · Eng · PM · Risk Ops
Engagement
Internal Product Team
01 — The Challenge

Insurance ops running on inbox + deck, at global scale

The Problem

  • Every country launch kicked off with a bespoke deck — no two requests captured the same fields
  • Risk Managers worked out of email — no SLA clock, no queue, no portfolio view
  • DSP and FLEX shared no common intake, so reuse was impossible
  • Any new requirement meant another round of email to re-collect missing info
  • No system of record for approved coverage — quotes lived in broker inboxes
  • Admin had no way to evolve the intake without a release

The Shift

  • Admin authors intake schemas — one schema per program type, versioned and published
  • PM submits structured requests from templates — guided, validated, saveable
  • RM works a typed queue — insurance · metrics · project — with milestone status per row
  • Program portal becomes the system of record: coverage, files, approval team, messages
  • DSP and FLEX share IA but inherit program-specific question blocks
  • Quote → Recommend → Enrolled, traceable end to end
2
Program Types (DSP · FLEX)
150+
Country × Program Combos
3
Personas · 1 Shared Platform
12+
Composable Intake Templates
02 — Personas

Three roles, one shared schema

Admin authors. PM submits. RM reviews. Same data model underneath — each persona gets a dashboard sized to their job.

Admin
Risk Ops Admin
Authors the intake schemas themselves — a new program type, a new country variant, a new question — all published without eng tickets.
Primary surfaceForm Builder
Admin landing page
Pain: Had no way to evolve the intake without a release. Every new requirement became a workaround in email.
Program Manager (PM)
Alicia · DSP / FLEX Country PM
Owns a country program. Submits structured insurance, metrics, and new-project requests to the Risk Manager team — one intake per program type.
Primary surfaceGuided Intake
Program Manager (PM) landing page
Pain: Used to assemble ad-hoc decks with whatever fields someone might ask for. Each round-trip added weeks.
Risk Manager (RM)
Steven · Regional Risk Manager
Queues, reviews, recommends quotes, and manages launched programs across countries. Watches milestones and renewals.
Primary surfaceTask Queue + Program Portal
Risk Manager (RM) landing page
Pain: Worked out of an inbox. No structured queue, no SLA, no way to see portfolio health across countries.
03 — Walkthrough

Three personas, two live demos, one platform

The first two tabs are live — you can type in them. The third tab walks the RM path through real screens. Together they trace a request from schema author → submitter → reviewer.

Admin edits a question inline — toggles style, adds options, marks the default — the PM's preview updates live.

Form Builder · Live

In v1 a new question meant an email to eng, a ticket, a release. In InsurGuide the Admin is the schema owner — types the question, toggles between Single Selection (compact radio list) and Ratio Card(explanatory cards the PM sees on first launch), adds as many answer blocks as the business needs, and marks a default. The PM-facing preview re-renders as you edit.

Question Section
Answer TypeSingle Select
Choose One Style
PreviewWhat the PM will see
*Where are you in your program launch plan?
Early Exploration
We are still defining the program and not sure if we even need coverage
Still Working Out Details
We have a good idea of what we need but it might adjust
Preparing to Launch Soon
We have firm figures and know exactly what we need
04 — One Platform, Two Business Models

How the template system handles DSP and FLEX

DSP is a B2B partner-fleet program. FLEX is a gig-driver program. Different risk shapes, same IA — the question blocks compose differently at the template level.

Dimension
DSP — partner fleets
FLEX — gig drivers
Business model
B2B — Amazon contracts with partner fleets
B2C / gig — individual drivers
Vehicle source
Partner-owned or leased branded vans
Driver's personal vehicle
Labor model
DSP's W2 employees or 1099 contractors
1099 independent contractors only
Insurance shape
Fleet commercial auto + general liability
Individual endorsements + umbrella
Template-level diff
Vehicles + Labor steps full; partner permissions block
Abbreviated Vehicles + simplified Labor; driver-enrollment block
05 — Impact

What shifted

Intake as a product, not a form
An Admin-authored schema layer means the intake evolves as the business evolves — new programs, new countries, new questions, without an eng release each time.
One platform, two business models
DSP (B2B fleet partners) and FLEX (gig drivers) share the same IA, permissions, and quote workflows — but inherit program-specific question blocks at the template level.
Structured queue replaces inbox
Risk Managers work from a typed task queue — insurance · metrics · project requests — with milestone status, SLA clock, and POC on every row.
Quote → Enrollment traceable
Every program has a program portal where insurance coverage, uploaded files, approval team, and permissions live in one place — from recommended quote to enrolled status.
06 — Reflection

Design as schema ownership

The PM lens on this one: most internal intake tools get built as forms, then regretted as forms. The durable move is to treat the intake as a schema layer the business owns — so the day the business changes (a new country, a new program type, a new question), the platform can change with it, same day, no release.

Platform IA as the core PDM move:The design problem was less "a form" and more "a schema system" — who can author what, who can submit what, who can approve what
Templates before pages:Rather than designing 12 country-program variants by hand, the Admin form builder made the template the design surface — same primitives, different compositions
Connecting strategy to delivery:The program portal — not the intake — is where strategy lives. Insurance coverage, uploaded files, approval team, milestones, renewals. The intake is the front door; the portal is the product.
Next case

Multi-Agent Care Operations Platform

View Project →