---
title: A clear caller path
subtitle: Drafts, versions, and phone routes
author: IVR Cloud
date: 13 October 2026
abstract: An illustrative implementation brief showing the IVR document system. All organization names, records, and decisions are fictional.
---

# Define the call flow

IVR Cloud helps businesses configure telephone menus, route calls, manage contacts and campaigns, and review call history and voicemail. A useful configuration makes the caller's path understandable and the active route's version explicit.

This example describes a support line for Atelier Exemplu. It is a design specimen, not a validated production configuration or customer story.

::: {custom-style="Callout"}
**Illustrative example.** Draft, publication, and deployment are different states. Publishing a version does not by itself change the phone route.
:::

## Start with the caller's decision

![Illustrative version lifecycle: edit a draft, publish an immutable version, then deploy separately to a phone route.](ivr-workflow.png){width=6in}

The greeting introduces the organization. A menu offers sales on key 1 and support on key 2. Invalid keys, no answer, and unsuccessful transfers need explicit paths according to the actual configuration.

### Make each outcome readable

Name a branch after its actual result. Keep the start step and unconnected steps visible. A diagram is useful, but an accessible list or tree must also communicate the path.

### Keep the selected step in context

Show the selected step's type, message, and outgoing outcomes beside the flow. On a narrow screen, place the inspector after the tree rather than squeezing both panels.

# Keep versions distinct

The editable draft, latest publication, and active route can point to different revisions. Keep all three visible before changing a route.

| State | Example version | Meaning |
|:---|:---|:---|
| Draft | v4 | Editable flow |
| Published | v3 | Immutable version available for deployment |
| Active route | v2 | Version used by this example's phone route |

: Fictional version context

## Publication

Publication creates an immutable version after the application's validation succeeds. A suitable message is “Version published. You can deploy it to a phone number.” Do not state that callers already use it unless a separate deployment has succeeded.

## Deployment and rollback

A deployment identifies the endpoint, number, and published version. Rollback requires an earlier ready deployment. It is not established merely because another publication exists.[^version]

[^version]: These distinctions follow the current application's IVR screen and route contracts. Example version numbers and organizations are fictional.

# Review the proposed change

1. Confirm the greeting and all menu outcomes.
2. Check the root step and unreachable steps.
3. Confirm the published version selected for deployment.
4. Name the number and endpoint that will change.
5. Verify the actual route state after activation.

## Example record

```text
Account: Atelier Exemplu (fictional)
Flow: Customer support
Draft: v4
Latest publication: v3
Active phone route: v2
Proposed next step: review the draft's missing outcomes
```

> A published version and a live route answer different questions.

## Decision needed

Complete the missing menu outcomes before proposing activation. Keep the existing route state explicit throughout the review. This document demonstrates typography, tables, code, notes, and callout styles; it does not authorize an application or production change.