Design Voice Commerce

Problem Statement: Voice Commerce Platform

Voice commerce lets shoppers buy through a conversation — "Alexa, order more paper towels" — across smart speakers (Alexa, Google Assistant) and in-app voice. The hard part is that this is not "search with a microphone": a voice purchase chains a fragile pipeline of ASR → NLU → catalog grounding → cart mutation → spoken confirmation → payment capture, and every stage can fail in a way that, unlike a screen, the shopper cannot see and correct. The core entities are the Shopper, the VoiceSession (one conversation), the Intent (what the utterance means), and the CartSnapshot (the priced cart the shopper hears and pays for).

The scale anchors: 50M linked households, 4M voice sessions/day, and 350k voice checkouts/day at steady state, with a 12× utterance multiplier at peak events (Prime Day, Black Friday) — though checkout attempts lag the utterance spike by ~30% because confirmation adds friction. The defining design constraint is that there is no screen: the shopper cannot glance at a cart, so the system must read back the price verbally, get an explicit confirmation, and never charge without it.

The three failures that define the problem: ASR mishears the SKU (orders the wrong product), a duplicate order on replay (the assistant retries a webhook and charges twice), and a stale price at confirmation (the price changes between the read-back and the charge). Each maps to a load-bearing mechanism — disambiguation, idempotency, and price-snapshot binding — that the rest of the design builds. The principle: voice commerce is a stateful pipeline where confirmation-before-charge and idempotency are not features but the core, because the shopper cannot see what went wrong.