Amazon Connect ACXD Conversational AI Guidelines

When you build a conversational AI experience in Amazon Connect ACXD, the behaviour is spread across many flows, nodes, and prompts — and often across several people. Without a shared rulebook, each part drifts: one flow is chatty, another is terse; one apologises too much, another blames the customer; the same action gets confirmed three different ways. The fix is a conversational AI guidelines document: the generic rules every conversation must follow, so the experience feels like one coherent assistant no matter who built which part.

This article is a template for that document. It draws on established conversation-design practice^[1][2][3] and is framed for ACXD, where these guidelines do double duty — they govern your designers and they feed the instructions and prompts that steer the generative AI itself.

1. Persona, Voice & Tone

These three are often conflated but are distinct, and your guidelines should define all three:

• Persona — who the assistant is. A short character brief: its name (if any), role, and personality. Decide whether it's explicitly an assistant/bot (usually best — don't pretend to be human).
• Voice — the consistent personality that never changes: the assistant always sounds like the same "someone." This is where brand lives.
• Tone — how the voice adapts to the situation. Tone matters most when things go wrong.^[4]

Spell out how tone shifts by context:

2. The Core Conversation Principles

Behind good conversation design sits the Cooperative Principle (Grice, popularised for conversation design by James Giangola at Google): people cooperate to move a conversation forward, which breaks into four maxims your assistant should follow.^[2][3] Put these in your guidelines as the non-negotiable rules:

• Quality (be truthful). Never state anything the assistant doesn't know to be true. No invented facts, no false certainty. (This is also where guardrails against hallucination belong.)^[5]
• Quantity (right amount of information). Give enough to move forward, no more. Don't read a paragraph when a sentence will do — especially on voice.
• Relevance (be relevant). Respond to what the customer actually asked; assume their input is cooperative and valid, and work out their intent.^[6]
• Manner (be clear). Plain, unambiguous, in the customer's language — not the system's.

Add two practical rules on top:

• Design for the 80/20. ~80% of users follow the most common ~20% of paths — invest the most design effort there, and don't over-engineer rare branches.^[7]
• Always offer a way forward. Every turn should leave the customer knowing what they can say or do next — and a route to a human when needed.

3. Verbiage & Standard Words

This is the section teams most often skip and most need — a shared vocabulary so every flow phrases the same things the same way. Define:

• Standard verbs/actions — pick one and stick to it. e.g. always "cancel" (not "void"/"stop"/"remove"); always "update" (not "change"/"amend"/"edit").
• Standard product/entity names — the exact customer-facing names for your products, statuses, and departments (and the synonyms customers use, for recognition).
• Standard micro-copy — the agreed phrasing for recurring moments: "Just to confirm…", "Got it.", "One moment while I check that.", "Is there anything else I can help with?"
• Numbers, dates, money, and spelling-out — how to format and read these (critical for voice: "£1,250.50", "the 3rd of July", read-back of reference numbers in grouped digits).
• Reading level & length — aim for plain, short sentences; set a target reading age and a max length per turn.
• Contractions — use them ("you're", "I'll") — they sound natural and human.

4. Words & Phrases to Avoid

An explicit "do not use" list is as valuable as the "use" list. Your guidelines should ban:

• Internal jargon & system terms — "CRM", "ticket ID", "back-end", "the system", product codenames. Use the words customers use.
• Blaming language — "you entered it wrong", "that's incorrect". Make errors the assistant's problem to solve, not the customer's fault.
• Robotic phrasing — "invalid input", "unrecognised command", "does not compute". Fail in human language.
• Over-apologising — a wall of "sorry" sounds insincere and weak. Acknowledge once, then help.
• False certainty & promises the bot can't keep — "your refund will arrive tomorrow" (unless it genuinely knows). Don't guarantee what you can't.
• Pretending to be human — if it's an assistant, don't imply otherwise. Be transparent; it builds trust and is increasingly a compliance expectation.
• Ambiguous confirmations — "Okay, done!" (done what?). Always say what was done.
• Dead-end errors — never leave the customer stuck with no next step.
• Overly casual filler / slang / emoji (unless your brand genuinely calls for it) — and never humour during a complaint or sensitive moment.

5. Greetings, Confirmations & Closings

Define the standard pattern for the moments that happen in every conversation:

• Greeting — brief, sets expectations, and (for a bot) is honest about what it is and can do. Don't make the customer sit through a long intro.
• Confirmations — confirmations give the customer feedback on how their input was understood, let them correct mistakes immediately, and establish common ground.^[8] Define when to confirm: always before a consequential or irreversible action (payment, cancellation, change of details); implicitly ("Booking you for Thursday…") for low-risk steps to keep things moving.
• Closings — confirm the outcome, offer anything else, close warmly. Don't just hang up.

6. Error Handling & Escalation

How the assistant behaves when it doesn't understand matters more than when it does — one badly handled error can outweigh dozens of smooth interactions.^[6] Your guidelines should mandate:

• Assume cooperation. Treat the customer's input as relevant and valid, and try to work out intent before erroring.^[6]
• Escalating, context-specific repair. First reprompt rephrases and helps; a second adds more guidance; don't repeat the same line. Each turn needs its own handling.^[6]
• No-input and no-match handling on every step (vital for voice).
• A clear escalation path. Define when the assistant stops trying and hands to a human — repeated failure, explicit request, high emotion, or a sensitive/high-risk case — and what context it passes over so the customer never repeats themselves.
• Never a dead end. Every error state resolves to either recovery or a human.

7. Making It Work in ACXD

In ACXD these guidelines aren't just a style doc for humans — they directly shape the build:

• They feed the instructions/prompts. The persona, tone rules, and "words to avoid" belong in the ACXD application's instructions so the generative AI follows them, not just the scripted nodes. Specific, unambiguous, grouped-by-topic instructions work best.
• They inform guardrails. The "don't say" list and the truthfulness rule map onto ACXD guardrails — output guardrails can catch off-brand, false, or banned-term responses deterministically.
• They become test and eval cases. "Does the assistant confirm before cancelling?", "Does it avoid jargon?", "Does it stay empathetic on a complaint?" become checks in your eval set.
• They're a documentation artifact. Treat the guidelines as a first-class, versioned document in your ACXD documentation set, kept current as the application evolves.

Frequently Asked Questions

Conclusion

A conversational AI guidelines document is the cheapest way to make an ACXD application feel coherent, on-brand, and trustworthy. Define the persona, voice, and situational tone; adopt the cooperative principles; set the standard verbiage and the words to avoid; standardise greetings, confirmations, and error handling; then wire it all into your ACXD instructions, guardrails, evals, and documentation. Write it once, apply it everywhere — and keep it alive from real conversations.

Related: the ACXD hub, ACXD guardrails, ACXD documentation checklist, documenting agentic self-service, and disambiguation in self-service.

Sources