Dialogue design

Genesys Cloud IVR dialogue design decides whether the first minute of a contact builds confidence or frustration. Customers judge your organisation by how quickly they are understood, how clearly they are guided and whether they feel trapped. A menu that mirrors your org chart, a prompt that rambles, or a bot that repeats "sorry, I didn't get that" three times all send customers to the operator option or to a competitor. Good dialogue design does the opposite: it recognises intent quickly, collects only what is needed, and hands over to the right person with the context already captured.

The benefits reach well beyond the customer. Clear dialogue reduces misrouted calls, shortens handle time because agents receive the right contacts, and raises containment in self-service without forcing it. It also protects your brand, because every automated word is an expression of who you are. QVCCS treats dialogue as a design discipline in its own right, with its own stage in our delivery lifecycle, its own artefacts and its own sign-off at the design authority review, rather than as the prompt text someone types into a flow at the end of the build.

Every channel has its own rules. Voice is linear and ephemeral, so prompts must be short, front-loaded and easy to remember, with menus kept to a handful of options and the most common reasons first. Speech input lets customers say what they want in their own words, but needs careful confirmation strategies and sensible fallbacks to keypad entry. Digital bot flows in Architect support quick replies, cards and carousels, but customers type quickly and expect a bot to keep up. Our consultants design each conversation for its channel while keeping the persona, vocabulary and outcomes consistent across all of them.

We design the whole contact, not just the menu: the greeting, identification and verification, data dips that personalise the journey, business-hours and emergency messaging, agent escalation and the in-queue experience. Waiting is part of the dialogue. In-queue flows let us plan comfort messaging, the Play Estimated Wait Time action with a playback mode chosen to suit your service, position in queue where it helps, and when to offer a callback using the Create Callback action. Each choice in the dialogue design specification is mapped to the Architect capability that delivers it, so our developers build exactly what was designed.

Most of the effort in a good dialogue goes into what happens when things do not go to plan. We specify every no-input and no-match path, how many retries are allowed, how the wording changes on each attempt, and when the customer is escalated to a person rather than asked again. We design for background noise, accents, withheld numbers, unexpected answers, failed data dips and customers who simply want an agent. These paths become explicit negative and failure-path test cases, so a bot that fails gracefully and passes on what it has learned is proven, not hoped for.

Accessibility is built in from the first draft. We consider customers with hearing, speech, cognitive or visual impairments, customers using assistive technology, and customers who are anxious or vulnerable. That shapes pacing, timeouts, plain-language wording, alternatives to speech and keypad input, and a clear route to a human at every stage. Architect prompts hold recorded audio and text-to-speech per language, and several text-to-speech engines can be configured, so we agree voices, pronunciation of brand and product names and the balance of recorded and synthesised prompts in the prompt list, keeping the experience consistent in every language.

Dialogue design sits between customer research, brand, compliance and Architect build, so we bring a multidisciplinary team from our own bench to each engagement. A Senior Business Consultant / Business Analyst leads discovery and contact-reason analysis; a Business Analyst holds the requirements and the Requirements Traceability Matrix; a Solution Architect keeps the dialogue aligned with routing, data and integration design; a Senior Developer prototypes and builds in Architect. Testing starts before build: scripted walkthroughs and early prototypes let real customers and front-line agents react to wording and structure while change is cheap. Once built, our testers work through every no-input, no-match and failed data dip, run dialogue usability and accessibility sessions, and use Architect replay mode to inspect executed flow instances when a path behaves unexpectedly.

Every engagement begins with evidence: contact reasons, volumes, recordings, transcripts, existing flows and reporting, plus workshops with operations, brand, compliance and IT. From that we produce a persona and style guide, current-state journey maps and the dialogue design specification and prompt list, recording every prompt, path, variable, data dip and error branch against a requirement in the RTM. The specification is peer reviewed and passed through the design authority review before build, and it stays under change control afterwards. The style guide is practical rather than decorative: it fixes how the brand refers to itself, which words customers actually use for each product, how numbers, dates and amounts are spoken, and how formal the tone should be in each channel.

Some of the most useful decisions are small. Menus work better when the action comes before the key, as in "for billing, press one", so callers listen for their reason rather than memorising numbers. Marketing messages before the menu lengthen every call and are best moved to the queue or removed. Legal and regulatory statements should be as short as the rule allows and placed where they apply. Language selection belongs at the very start, and remembering a customer's choice saves the question next time. Terminology should match your website and letters, so customers recognise the words they hear. And the route to an agent should be visible rather than hidden, because customers who feel trapped are the ones who complain loudest.

Dialogue is never finished, because customers, products and policies keep changing. After go-live we use Genesys Cloud CX reporting, flow outcomes, performance views and, where licensed, speech and text analytics to see where customers hesitate, repeat themselves, opt out or abandon. We listen to recordings and read transcripts alongside the numbers, then run optimisation reviews against agreed KPIs and recommend specific changes to wording, menu order, intents or escalation rules. Each change goes back through the same specify, review and test cycle, so a quick fix to one prompt does not break the consistency of the rest. QVCCS supports and maintains your flows in line with your support model, alongside your provider or under our own SLA.

Good governance keeps the dialogue coherent as more people contribute to it. We maintain the persona guide, prompt list and dialogue design specification as living documents in the handover pack, so new journeys, seasonal messages and emergency announcements follow the same style and structure as everything else. Prompt changes are versioned and traceable, recorded audio is managed alongside text-to-speech, and every release is checked against accessibility and compliance requirements. When you are ready to add virtual agents or move more contacts into self-service, the same discipline applies, so new automation feels like a natural extension of the conversation your customers already know.