> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/apply-dialogue-studio-scenario-patterns.md).

# Apply Dialogue Studio scenario patterns

Apply reusable Dialogue Studio scenario patterns for IVR, chatbot, voicebot, return routing, SSML, and catch-node recovery.

Use this page to apply reusable Dialogue Studio scenario patterns when you need a stable starting design for IVR, chatbot, voicebot, return routing, speech output, or error-handling behavior.

## Before you begin

* Confirm which phase of the flow owns the pattern you want to add.
* Confirm that the baseline trigger, queue, and handoff behavior already works before you add a reusable pattern on top of it.
* Plan to validate the pattern in a controlled test flow before you apply it to production traffic.
* Keep a fallback route available so the conversation can continue if the pattern does not behave as expected.

## Start with simple building blocks

Most reusable Dialogue Studio patterns use the same core structure:

1. Start with the trigger for the relevant phase.
2. Add the evaluation or transformation step that drives the decision.
3. Branch to the intended next action.
4. Add an explicit fallback or escape path.

Keep the first implementation small. It is easier to validate one working pattern and then extend it than to troubleshoot a large imported flow all at once.

## Apply a simple IVR pattern

Use a simple IVR pattern when the caller should hear a prompt, make a choice, and continue on one of a small number of known branches.

The usual structure is:

1. Start on the incoming call trigger.
2. Play the initial prompt or ask the question.
3. Inspect the caller's DTMF or speech response.
4. Route to a queue, a follow-up prompt, or a fallback path.

### Keep the fallback route visible

Before go-live, confirm how the flow behaves when:

* the caller gives no answer
* the caller gives an unsupported answer
* the prompt plays but the next branch does not receive usable input

## Apply a chatbot or voicebot pattern

Use a chatbot pattern when the flow must process a text conversation and return an automated response. Use a voicebot pattern when the flow must process spoken input and return spoken output.

### Chatbot pattern

For a durable chatbot design:

* confirm who owns the external bot service, credentials, and language configuration
* detect the incoming message channel
* store or reuse the identifier and session state the bot interaction needs
* route on keywords, intent, or another evaluation result
* return a message, queue action, or disconnect path

### Voicebot pattern

For a durable voicebot design:

* confirm that the transcription service or plugin is installed, configured, and owned for the environment
* capture the spoken input or the transcription result
* send that content to the selected processing step
* transform the returned result into a voice response
* continue, re-prompt, or disconnect based on the result

{% hint style="warning" %}
If the voicebot path depends on transcription, timeout, or multi-step conversation state, validate those behaviors in a controlled test flow before you rely on them in production. Some environments can require transcription to be started again for each phase that uses it.
{% endhint %}

## Apply a previous-agent return pattern

Use a previous-agent return pattern when the service design should try a preferred return route for an agent who handled the conversation earlier.

Keep the pattern at the behavior level:

1. Observe the event or condition that makes the return path relevant.
2. Store enough state to identify the preferred return target.
3. Try the preferred return route only when the stored state is still valid.
4. Fall back to the standard queue or skill when the return target is not available.

Do not depend on this pattern without testing the timeout, eligibility, and fallback behavior in the target environment.

## Use SSML deliberately

Use *Speech Synthesis Markup Language* (SSML) when plain text is not enough to control pronunciation, emphasis, pauses, or other speech output details.

Good practice is to:

* keep the speech text readable before you add SSML markup
* test the spoken result with the voice configuration used in the target environment
* keep a plain-text fallback available when the advanced speech formatting is not required

For a simple SSML flow pattern:

1. Start from an audio-capable incoming conversation path.
2. Use a **Function** node to create the SSML string, for example in `msg.text`.
3. Connect the function output to a **Say** node.
4. Set the **Say** node message to `msg.text`.
5. Set the **Say** node method to **SSML**.
6. Test the spoken output with the speech engine used by the environment.

## Use catch nodes for controlled recovery

See [Configure a Catch node](/product-reference/dialogue-studio/dialogue-studio-example-flows/configure-catch-node.md) for the concrete Catch, Say, and fallback Enqueue example. This does not establish that every external request timeout is handled by that pattern.

Use a catch-node pattern when a selected node can fail and the conversation should continue on a safer branch instead of stopping unexpectedly.

When you add a catch node:

* keep the recovery path close to the failing branch
* log or inspect the failure in a test path before you simplify the output
* route the customer to a known safe next step
* avoid hiding a repeated failure that still needs investigation

## Verification

1. Confirm the pattern starts in the intended phase of the flow.
2. Test at least one success path and one fallback path for the pattern.
3. Confirm the conversation still reaches a safe next step when the evaluation, input, or external dependency fails.
4. Check the imported flow's node settings and message fields against your deployed version before using the pattern in production.
5. Record any prerequisite or timeout assumption that the production flow must preserve.

## Related topics

Go to **Incoming phase in Dialogue Studio** for the call-start trigger patterns that usually host IVR logic.

{% content-ref url="/pages/lB1YWsYrWzTQIPjgz4XT" %}
[Incoming phase in Dialogue Studio](/contact-center-configuration/building-your-callflow/via-dialogue-studio/incoming.md)
{% endcontent-ref %}

Go to **InDialogue phase in Dialogue Studio** for the live-session automation patterns that can host voicebot or transcription-driven behavior.

{% content-ref url="/pages/XOOwFrocTtvy9JZG1Iuc" %}
[InDialogue phase in Dialogue Studio](/contact-center-configuration/building-your-callflow/via-dialogue-studio/indialogue.md)
{% endcontent-ref %}

Go to **Configure advanced Dialogue Studio features** for the AI-driven routing and settings-access patterns that can extend these reusable designs.

{% content-ref url="/pages/tVbNw2DZ0Mb6w6i0kFlM" %}
[Configure advanced Dialogue Studio features](/contact-center-configuration/building-your-callflow/via-dialogue-studio/configure-advanced-dialogue-studio-features.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/apply-dialogue-studio-scenario-patterns.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.