Order Status Voice Agent

Business Problem

Order status is the single most repeated question in e-commerce support: high volume, low complexity, and fully answerable from data the business already has, making it a strong fit for a voice agent and a poor use of a human agent's time.

Customer / User Context

Built for two distinct users: the end customer calling to check an order in one of five languages without navigating a phone menu, and the recruiter or engineer evaluating the project with well under two minutes to judge whether it demonstrates real integration and architecture skill rather than a scripted demo.

Approach

The agent greets the caller, confirms which of three demo stores they ordered from, accepts a preferred language, then asks for an order number or checkout email. It calls a look_up_order webhook tool registered directly on the agent, which queries a live Postgres table on Supabase scoped to that store, and reads the result back in natural spoken language: processing, shipped with carrier and tracking number, or delivered.

Architecture

A single shared orders table and a single shared webhook tool serve three separate demo stores, with store passed as a required parameter on every lookup rather than standing up three separate deployments. The ElevenLabs agent calls the look_up_order tool, which hits a stateless FastAPI endpoint on Vercel that queries Supabase Postgres with row-level security enabled and an explicit grant to the service role.

Technology Stack

Business Outcome

The full path, voice to tool to live database to spoken response, works end to end and is verified against real Supabase rows rather than mocked data. The agent handles three demo stores and five languages through one shared schema and one shared tool, and the project is documented well enough, via a case study and a self-service integration guide, to be legible to someone outside the build in under a minute.

Lessons Learned

Every major failure hit while building this got found and fixed rather than worked around, and each one was a different category of mistake: a tool that was silently never attached to the agent because it lived in the workspace tool library but not in the agent's own tool_ids; a valid API key rejected by an outdated client library; Postgres RLS policies that were configured correctly but useless because the base table grant to service_role was missing, since RLS alone doesn't grant table access; and turn-taking settings that needed retuning so the agent stopped interrupting callers or looping on unclear answers.

Deployment

FastAPI backend and widget both deployed on Vercel, with the agent itself hosted on ElevenLabs and reachable via a standalone web widget or an ElevenLabs dashboard test call. There's no real phone number: Twilio integration was a deliberate cost decision, not a limitation hit by accident, and the agent's spoken promise to hand off to a human on a failed lookup is not yet backed by a real handoff.