The failures of embedded insurance are as patterned as the successes. Six recurring launch archetypes — and the question that would have stopped each one before it shipped.
Survivorship bias runs the embedded insurance conversation. Conference stages and vendor decks feature the programmes that worked; the ones that quietly shipped, underperformed and were removed in a later release get no panel. That is a loss, because the failures are at least as patterned as the successes — and cheaper to learn from secondhand.
A note on method before the list: the six launches below are archetypes, not named companies. Each is a pattern we have seen recur across the industry — in public post-mortems, in funnels that visibly disappeared from live products, and in conversations with teams who lived them. We have deliberately not attached names or invented figures; the point is the pattern, and every pattern here ends with the question that would have killed the launch in the planning document, where killing is cheap.
Launch one: the product nobody was thinking about
The most common failure is the least dramatic: cover embedded into a transaction that does not make the customer think about risk. A grocery checkout offering personal accident cover. A fashion order offering income protection. The insurable need may be real in the actuarial sense, but the moment does not surface it in the customer's mind, and no amount of placement optimisation or copy testing rescues an offer the context does not justify. These programmes do not blow up; they flatline, consume roadmap attention for two quarters, and get removed in a cleanup sprint.
The question that would have stopped it: if we described this transaction to a stranger, would they name the risk unprompted?
Launch two: the attach rate that was really a default
The opposite failure is louder. A team under revenue pressure discovers that pre-selecting the cover, burying the decline option, or bundling the premium into a total price moves the attach rate dramatically — because of course it does. The programme reports spectacular numbers for several quarters. Then the delayed costs arrive together: cancellation spikes, chargebacks, complaint volumes, press attention, and in regulated markets, supervisory questions about whether customers knowingly bought anything at all. Forced attach is the single failure mode most likely to end not just the programme but the platform's permission to run one.
The question that would have stopped it: would this attach rate survive the customer fully understanding what happened?
Launch three: the integration without an operation
A platform ships the technical integration — clean API work, tested flow, correct documents — and staffs the operational side with nobody. The first policy month works. Then the edge cases arrive: a customer who needs to correct a misspelled name, a cancelled underlying transaction whose policy must be unwound, a claims question landing in a support team with no script, no escalation path and no idea which party is responsible. Insurance generates a small but relentless stream of exceptions, and a programme designed only for the happy path converts each exception into an angry customer holding a legally binding document.
The question that would have stopped it: who, by name, handles the tenth weirdest ticket this programme will generate in month two?
Launch four: the price that had no insurer behind it
Some launches are built on commercial arrangements that cannot survive contact with claims experience. A headline premium set aggressively to win the partnership; an insurer accepting it for the volume story; a first renewal cycle where the loss ratio arrives and the price corrects sharply upward — or the capacity is withdrawn entirely. The platform, having marketed a price point to its customers, now owns the backlash for a repricing it did not decide. Programmes die at the first renewal more often than at launch.
The question that would have stopped it: does the insurer's pricing survive a realistic claims year, and what does our customer communication look like if it does not?
Launch five: the claim that had no home
A customer buys embedded cover in a checkout, has a loss six months later, and returns to the only brand they remember — the platform. The platform routes them to the orchestrator, who routes them to the insurer, whose claims team has never heard of the distribution partnership's promises. Every party behaves correctly by its own contract; the customer experiences a circle. One viral thread about an unclaimable policy can undo years of attach-rate work, because the entire embedded proposition rests on borrowed trust, and claims are where the loan is repaid.
The question that would have stopped it: has anyone on our team filed a test claim, end to end, pretending to know only what a customer knows?
Launch six: the rebuild before the proof
The quietest failure is sequencing. A well-resourced platform decides insurance is strategic, skips the validation phase, and commits two quarters of engineering to a fully native, deeply integrated experience — before any evidence of demand exists in its funnel. The build is excellent. The attach rate, measured for the first time at launch, does not support the investment, and the sunk cost then distorts every subsequent decision: the programme is kept alive to justify the build rather than the build serving the programme.
The question that would have stopped it: what is the cheapest version of this offer that would tell us whether anyone wants it?
The common thread
Read the six again and notice what none of them are: technology failures. APIs, webhooks and document generation are solved problems. Every archetype above is a failure of honesty at the planning stage — about whether the moment implies the risk, whether the attach is chosen, whether the operation exists, whether the price is real, whether the claim has a home, and whether the demand is proven. Embedded insurance fails in documents, not in code. The good news is that documents are cheap to fix.