Ship Compliant Ecommerce Voice Agent Scripts With 3 Ready Templates

A playbook for engineers to ship ecommerce voice agent scripts: three ready templates, SSML fixes, testing metrics, and U.S. compliance checks.

Specialist testing an ecommerce voice script

A voice agent script is a structured set of prompt components, role, scope, tone, and behavior rules, written so it sounds natural when spoken aloud rather than read on a screen. The single most important design rule is to keep every turn short and ask one clear question at a time. That discipline improves comprehension, lowers call abandonment, and reduces the legal exposure that comes with confusing or misleading automated calls.

TL;DR:

  • Ensuring each turn is short and asks one clear question is crucial to prevent miscommunication and minimize call abandonment.
  • Predefine all voice script components, including role, tone, scope, and escalation rules, to avoid failures caused by vague or missing instructions.
  • Use plain prose without formatting artifacts and read scripts aloud to detect pronunciation issues before deployment.
  • Implement a three-strike fallback system that escalates to human intervention after two failed attempts to reconnect with the caller.
  • Comply with US legal requirements by obtaining explicit consent and clearly disclosing AI involvement at the start of automated outbound calls.
Orphora AI
orphoraai.com
Make Support Available Around The Clock
Orphora AI provides WooCommerce voice agents that answer order and returns questions using real-time customer and order data.

See Orphora AI

Table of Contents

The core components every voice agent script needs

A voice agent prompt is built from distinct blocks, not one long paragraph of instructions. Deepgram’s voice agent prompting guide breaks a strong prompt into role, personality, environment, scope, conversational approach, speaking style, function calling, and boundaries, a structure worth using as a working checklist.

Each block does a specific job:

  • Role and identity: state the agent’s job plainly, such as “You are a support agent for an online store handling order status and returns.”
  • Personality and tone: two or three descriptors (warm, efficient, plain-spoken) with a line of example phrasing, not a personality essay.
  • Environment and channel: remind the model it is speaking, not displaying text, so it avoids lists, links, or visual formatting.
  • Caller expectations: describe who typically calls and why, so the agent sets context instead of guessing.
  • Scope: define exactly what the agent can and cannot do, and tie every factual claim to a tool call rather than a guess.
  • Conversational approach: one question per turn, with short, targeted follow-ups instead of multi-part asks.
  • Speaking style rules: sentence length limits, approved vocabulary, and a ban on jargon the caller won’t recognize.
  • Function-calling instructions: how and when to call backend systems, and how to confirm results before repeating them to the caller.
  • Boundaries and escalation: the conditions that trigger a handoff to a human agent.
  • Error and fallback wording: what the agent says when it doesn’t understand, and how that wording narrows with each attempt.

Writing all ten blocks before testing a single call saves rewrites later. Most script failures trace back to a missing scope definition or a vague escalation rule, not bad phrasing.

Why voice scripts are not text prompts

Text prompts tolerate density. Voice prompts don’t. A caller can’t reread a sentence, so a script written like a chatbot prompt will produce turns that are too long, too formal, or too visually formatted to say aloud.

Four constraints separate voice from text:

  • Ear-readability and turn length: spoken turns need to be short enough to hold in working memory, generally one idea per sentence and one question per turn.
  • TTS literalness: text-to-speech engines read markdown, bullet symbols, and stray punctuation out loud or mangle them, so scripts must be written in plain prose with no formatting artifacts.
  • Interruptions and streaming latency: callers talk over the agent, and streaming TTS means a script has to handle a cut-off mid-sentence gracefully rather than losing state.
  • Orchestration and model choice: the underlying model and the orchestration layer around it (how turns are managed, when tools fire, how state is tracked) change what the script can assume is already known.

Microsoft’s guidance on voice agent prompts recommends treating the whole prompt as a state machine: each turn reads or updates a small, explicit piece of state, and the script guards transitions between states. That approach prevents the agent from looping on the same question and makes fallback logic predictable instead of improvised.

Pro Tip: Read every script line aloud before shipping it. If you stumble reading it, the TTS engine and the caller will stumble too.

Ready-to-adapt script templates for common voice tasks

Three templates cover most production use cases: support triage, order-status lookup, and appointment booking. Each follows the same shape: open, clarify, confirm, resolve.

  1. Support triage: open with “Thanks for calling, how can I help today?” then route based on a single core question such as “Is this about an existing order or something new?” Narrow follow-ups should offer two or three options at most, never an open-ended menu.
  2. Order-status lookup: capture an order number or phone number, verify it against the account, call the order-lookup function, and confirm back a short summary (“Your order shipped yesterday and should arrive by Thursday”) rather than reading raw data.
  3. Appointment booking: offer two or three specific time slots instead of asking “When works for you?”, confirm the caller’s choice once implicitly, then use an explicit final confirmation only for the booking itself, since that’s the irreversible step. Google’s guidance on confirmations recommends reserving explicit confirmation for high-cost or irreversible actions and using implicit confirmation for routine parameters, which keeps the call moving.

When adapting any template, check product names, order identifiers, and abbreviations against your pronunciation lexicon before launch. A script that reads perfectly on paper can still mangle a SKU or a brand name if the TTS engine guesses at pronunciation. Google’s conversation design guidance on commands also warns against listing example phrases as a closed set, since that narrows what callers think they’re allowed to say. Present examples as suggestions, not a menu.

Getting pronunciation right with SSML and custom lexicons

Standard TTS engines frequently mispronounce product names, part numbers, and acronyms, which breaks trust fast on a support call. SSML and custom lexicons fix this at the script level instead of leaving it to chance.

  • Use inline phoneme or say-as tags for one-off terms that appear rarely, such as a single unusual product name in one script.
  • Use a custom lexicon file (PLS or XML) for terms that repeat across many scripts, such as a brand name, model number format, or industry abbreviation.
  • Microsoft’s Azure Speech Service documentation details phoneme, say-as, and sub elements alongside custom lexicon support for exactly this purpose, and Microsoft’s Copilot Studio lexicon guidance covers the same pattern for voice agents built on that platform.
  • Version your lexicon file the same way you version code, since a silent pronunciation regression is hard to catch without a diff.

Build a testing workflow with three layers: single-phrase tests for new terms, batch tests across the full lexicon before each release, and a running pronunciation registry that tracks every term you’ve had to fix. That registry becomes the first place to check when a new product name or abbreviation enters the script.

Pro Tip: Keep your pronunciation registry in the same repository as your scripts so a new product launch triggers a lexicon review automatically.

Building a three-strike fallback for errors and confusion

Callers misunderstand prompts, mumble, or get cut off by background noise, and a script needs a clear, escalating response rather than repeating the same line.

  1. First reprompt: rephrase the original question more simply. If you asked “What’s the reason for your call?” and got silence or confusion, follow with “Are you calling about an order, a return, or something else?”
  2. Second reprompt: narrow further into a yes-or-no or two-option choice, such as “Is this about an order you already placed?” This is the point where the script should stop trying to be open-ended.
  3. Final exit: after two failed attempts, stop reprompting and offer a clear path out, typically a human handoff or a callback option, rather than asking the same question a third time.

Google’s conversation design guidance on errors prescribes exactly this escalating pattern, ending in a final exit instead of a repeated loop. Wire the attempt count into session state so it resets once the caller successfully answers a question, not just at the start of the call. Without that reset, one early stumble can push a caller toward escalation even after they’ve recovered.

What U.S. rules mean for AI-generated voice calls

Automated and AI-generated voice calls carry specific legal obligations that script writers need to account for, not just engineers.

The FCC’s Second Report and Order on TCPA clarified that “artificial or prerecorded voice” under the Telephone Consumer Protection Act covers current AI-generated voices, and it requires prior express consent for non-emergency automated calls. The order also recommends clear disclosure when a caller is interacting with an AI system.

In practice, that means:

  • Capture and log consent explicitly before placing outbound automated calls, not just inbound ones.
  • Include a brief, natural disclosure near the start of the call, such as “You’re speaking with an automated assistant,” rather than burying it in fine print the caller never hears.
  • Treat disclosure wording as a scripted, auditable line, the same way you’d script a legally mandated disclaimer in a regulated industry, since FTC telemarketing guidance treats these disclosures as part of the legal record of the call.
  • Route any outbound AI calling campaign, as opposed to inbound support, through legal review before launch, since outbound consent requirements are stricter than inbound ones.

These aren’t boilerplate suggestions. A missing disclosure or a consent gap is a compliance failure that shows up in call logs, which is exactly why QA should check for it on every release.

Testing and measuring script performance

A script that reads well in a design review can still fail in production, so measurement has to happen continuously, not just at launch.

  • Completion rate: the share of calls that reach the intended outcome without escalation or hangup.
  • Fallback rate: how often the agent triggers a reprompt, broken down by which turn caused it.
  • Correction rate: how often callers have to repeat or correct information the agent misheard or misunderstood.
  • Caller satisfaction signals: post-call survey responses or sentiment markers in the transcript, where available.

Run structured experiments rather than guessing at fixes: test two versions of an opening line, two confirmation styles (implicit versus explicit), or two reprompt wordings, and compare fallback and completion rates between them. Instrument telemetry so every fallback and escalation event links back to the specific script line that triggered it, and label failures by cause (misheard input, ambiguous phrasing, missing scope) so edits target the actual problem instead of a guess.

Deploying scripts safely: storage, function calls, and rollback

Shipping a script to production needs the same discipline as shipping code, since a bad script change can break every call simultaneously.

  • Store scripts in version control with clear changelogs, so you can trace any regression back to a specific edit.
  • Keep a fast rollback path ready, since a script bug in production affects live calls immediately, not just a staging environment.
  • Enforce tool-only truth: the agent should never state an order status, price, or availability figure it hasn’t retrieved from a function call in that session.
  • Confirm function call results before repeating them to the caller, catching malformed or stale data before it reaches a human.
  • Collect telemetry before and after every rollout, including fallback rate and completion rate, and set a rollback threshold (for example, a defined jump in fallback rate) that triggers an automatic revert rather than a manual decision made hours later.

Applying these patterns to e-commerce voice agents

Order-status and returns calls are a good test case for everything above, because the agent’s scope has to be airtight: it should never guess at a shipping date or a refund amount. Some AI voice agents pull order and customer data in real time before answering, so the response is grounded in the account the caller actually has rather than a plausible-sounding guess.

Adapting the order-status template for a store means mapping the identifier-capture step to real account fields and wiring the confirmation step to live inventory and shipping data rather than a cached summary. Orphora AI’s WooCommerce integration is built around that exact pattern: capture, verify, call, confirm, with no step skipped. The result is a script that sounds simple on a call but is backed by a function call at every factual claim, which is the same discipline the component checklist above describes for any voice agent, not just ours.

— Orphora AI

Give your store’s phone line the same upgrade

Writing a good script is half the job. Running it reliably on real phone lines, with real order data, at a price that makes sense for a small or mid-sized store, is the other half. Orphora AI applies the patterns in this article directly: real-time order lookup, no speech-to-text lag slowing down the conversation, and guardrail workflows that keep the agent inside its scope on every call.

The AI Voice Agent plan runs $9.99 per month per agent, with call usage billed at $0.10 per minute, so you pay for a working phone line, not a flat subscription regardless of volume. Stores with higher call volume or multiple locations can ask about the Enterprise plan, priced on request based on scale.

If you’re running a WooCommerce store and fielding the same order-status and return questions on repeat, check availability for your store at Orphoraai and see what a live script sounds like on your own phone number.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Give your store's phone line the same upgrade — overview diagram

FAQ

What is the most important rule for writing voice agent scripts?

Keep each turn short and ask one clear question at a time, since callers can’t reread a sentence the way a reader can. This single rule drives most of the other best practices, from reprompt design to confirmation style.

How is a voice script different from a chatbot prompt?

A voice script has to be ear-readable: no markdown, no bullet lists read aloud, and shorter turns than a text interface would use. Deepgram’s prompting guide breaks this down into explicit components like speaking style and conversational approach that text prompts don’t need to address.

The FCC’s TCPA ruling confirms that AI-generated voices fall under rules requiring prior express consent for non-emergency automated calls, and it recommends clear disclosure that the caller is speaking with an AI system. Outbound campaigns typically need stricter consent handling than inbound support calls.

How do I fix mispronounced product names in a voice agent?

Use SSML phoneme or say-as tags for one-off terms and a custom pronunciation lexicon file for terms that repeat across scripts. Microsoft’s lexicon guidance and Azure Speech Service’s SSML reference both document this pattern for production TTS systems.

What should happen after a caller fails to answer twice?

Stop reprompting and offer a clear exit, usually a human handoff or callback, instead of repeating the same question a third time. Google’s conversation design guidance describes this escalating, three-step fallback pattern as standard practice.

Sources