DoorDash: a Claude-powered voice AI fields hundreds of thousands of Dasher calls a day

• Building a Generative AI Contact Center Solution for DoorDash Using Amazon Bedrock, Amazon Connect, and Anthropic's Claude — AWS (case study)
• DoorDash successfully leverages Claude in Amazon Bedrock (one-sheeter) — Anthropic
• Deploy generative AI agents in your contact center for voice and chat using Amazon Connect, Amazon Lex, and Amazon Bedrock Knowledge Bases — AWS Machine Learning Blog

Background

DoorDash is the largest local commerce and delivery platform in the US, founded in 2013. By the end of 2023 the service had more than 37 million monthly active consumers and over 2 million monthly active Dashers — the couriers who perform deliveries. Dashers are the contact center's main clients: they need help mid-delivery, when a question arises about an order, an address, sign-up, or pay.

This audience has a hard constraint that shaped the whole project: Dashers are behind the wheel. They prefer calling over chatting — and they cannot wait. Every second of response delay is a courier standing at a restaurant door or parked at a curb. Response latency in the voice channel here is not a 'quality metric' but physical time subtracted from a person's earnings.

DoorDash's contact center runs on Amazon Connect — AWS's cloud platform — and handles a collective volume of hundreds of thousands of calls per day. An important nuance of this case that retellings often lose: by the time generative AI launched, DoorDash already had advanced voice automation on Amazon Connect and Amazon Lex, and it was delivering measurable results. The task was not to 'replace a touch-tone menu' but to break through the ceiling of what a classic NLU bot can do — without degrading the speed Dashers were used to.

Problem

DoorDash's baseline was strong — which makes this case more honest than most. The existing self-service IVR on Amazon Connect and Amazon Lex had already reduced agent transfers by 49%, driven a 12% increase in first-contact resolution, and was saving $3 million in year-over-year operational costs. Those are results of classic, pre-generative automation — attributing them correctly matters.

The problem was the ceiling: despite those results, most calls were still redirected to live agents. A classic NLU bot confidently walks users through pre-designed flows but cannot answer varied questions 'in its own words' from a knowledge base: anything outside the flow goes to a human. At hundreds of thousands of calls a day, every percentage point of escalations means dozens of agents on the line.

Generative AI promised to close exactly that gap, but imposed three hard requirements. First, latency: a voice dialogue falls apart if the model thinks for five seconds — doubly unacceptable for drivers on the road. Second, reliability: a model answering couriers about pay must not hallucinate, must resist prompt injection, and must catch abusive content. Third, testing at scale: before the project the team had to pull live agents off help queues to run a handful of manual test cases per hour — no way to validate a voice AI that faces hundreds of thousands of calls.

Solution

DoorDash built the solution with the AWS Generative AI Innovation Center (GenAIIC) — a program pairing AWS experts with the customer's team. In 8 weeks the teams designed, built, and brought the solution to production A/B-testing readiness; per the case study, Bedrock as a managed platform cut generative AI application development time in half.

The foundation is Anthropic's Claude models in Amazon Bedrock. The case explains the choice of Claude by three properties critical for voice support: the capability to mitigate hallucinations, resistance to prompt injection, and detection of abusive language. And with the release of Claude 3 Haiku — the family's lightest and fastest model — DoorDash got the mix of accuracy and speed it needed: a response latency of 2.5 seconds or less. The choice itself is telling: for the voice channel the company took not the most powerful model but the fastest sufficiently accurate one.

The system's knowledge follows a RAG scheme: DoorDash's publicly available Dasher help center serves as the source, while Knowledge Bases for Amazon Bedrock — a managed service that spared the team custom integrations — handles indexing and the whole 'retrieval → prompt augmentation' pipeline. A key security constraint: no personally identifiable information is passed to the generative loop; data is encrypted and isolated within the DoorDash application. 'Employing AI-generated responses for phone support presented unique challenges that demanded innovative strategies to enhance response times and answer quality. Amazon Bedrock proved to be a perfect fit for our requirements, allowing us to concentrate on refining the solution's finer details,' says Vraj Shah, Lead Project Engineer at DoorDash.

The project's invisible but decisive part is the testing loop. On Amazon SageMaker the team built an automated test-and-evaluation framework: thousands of automated tests per hour — a 50x increase in testing capacity versus manual runs — with semantic evaluation of responses against ground-truth data. That loop made it possible to run A/B tests on live traffic and prove quality before full rollout. Without it, taking a voice AI from design to production in 8 weeks would have been impossible.

Architecturally the solution is embedded in the existing Amazon Connect stack: the generative layer augments the working IVR rather than replacing the channel — complex and non-routine cases still go to live agents.

Result

After successful testing in early 2024, DoorDash rolled the new self-service options out to all Dashers. The voice AI fields hundreds of thousands of Dasher calls daily at a response latency of 2.5 seconds or less. In the case study's wording, the solution has driven 'large and material reductions' in call volumes for Dasher-related support inquiries, cut escalations to live agents by thousands per day, and reduced the number of tasks agents perform to resolve inquiries. AI closes the routine questions, freeing agents for complex cases that need a human.

It is important to hold the attribution frame — and to correct a widespread retelling of this case (including our own earlier version): the figures '−49% transfers, +12% first-contact resolution, $3M annual savings' belong to DoorDash's previous automation generation on Amazon Connect and Amazon Lex — the baseline the generative layer was built on top of. For the Claude solution itself, AWS and DoorDash publish speed and scale metrics (2.5s; hundreds of thousands of calls a day; 50x testing capacity; −50% development time) and qualitative impact statements ('thousands of escalations a day'), but no percentages or dollars. That is typical, honest practice for a fresh deployment — precise financial effects take a year of observation.

The team has already announced the next step: expanding the knowledge bases and integrating DoorDash's event-driven logistics workflow service so the assistant not only answers questions but takes actions on the user's behalf. 'Using AWS and Anthropic's Claude, we've built a solution that gives Dashers reliable and simple-to-understand access to the information they need, when they need it. This has cascading positive impacts on our users and the platform as a whole,' says Chaitanya Hari, Contact Center Product Lead at DoorDash.

In our view there are three transferable lessons. First: for voice AI, speed is product requirement number one, and choosing a light model (Haiku) over the flagship is sound engineering economics applicable to any realtime scenario. Second: test infrastructure matters more than model 'smarts' — the 50x testing capacity increase is the reason the project reached production in 8 weeks. Third: build the generative layer on top of working automation, not instead of it — DoorDash augmented a strong IVR baseline, which is exactly why it could honestly measure the added value through A/B testing.

Lessons learned

1. For voice scenarios speed is a product requirement: DoorDash picked a light model (Claude 3 Haiku) for ≤2.5s latency rather than the most powerful one in the lineup.
2. Attribute metrics honestly: the famous '−49% transfers and $3M savings' are the result of the pre-generative Connect/Lex IVR; the Claude layer's value is measured separately, on top of that baseline.
3. An automated testing loop is the invisible but critical piece: 50x testing capacity (thousands of runs per hour with semantic evaluation) is what made production in 8 weeks possible.
4. The generative layer augments working automation instead of replacing the channel: complex cases still go to humans, and the added value can be honestly measured via A/B testing.
5. Security is designed into the architecture: no PII enters the generative loop, and the model was chosen partly for prompt-injection resistance and abusive-language detection.
6. The first audience is couriers, not customers: an internal audience gives a fast feedback cycle at lower reputational risk.
7. A managed platform (Bedrock + Knowledge Bases) halved development time — at the start, iteration speed matters more than fine-tuning your own infrastructure.

Frequently asked questions