> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/call-routing/call-flows/call-flow-best-practices.md).

# Call flow best practices

Build call flows that reach someone: the right order of nodes, a backup for critical calls, and practical advice for every node.

A good call flow decides quickly, keeps the caller informed, and never loses a call silently. This page collects what works, node by node. If you are new to call flows, build [your first flow](/call-routing/call-flows.md) first.

## Plan the flow

**Decide before anything speaks.** [Branch](/call-routing/call-flows/branch-node.md) and [Support hours](/call-routing/call-flows/support-hours-node.md) nodes are silent and take no time, so put them at the top. A good order is:

1. **Branch**: a flood guard, then routing on who is calling.
2. **Support hours**: split on when the call arrives.
3. **IVR menu** or **AI voice agent**: ask the caller what they need.
4. **Create alert**, then **Route call**: reach a responder (see [Critical calls](#make-critical-calls-reach-someone)).
5. **Voicemail** and **Create alert** on the paths where nobody answers.

**Fill every branch.** A branch with nothing in it ends the call at once, without a word, just like **Call ends**. Before you assign a flow to a number, check every **No one available**, **No input**, **Out of hours**, **Fallback** and **Else** branch.

**Build on an unassigned flow.** Changes to a flow that is assigned to a number apply immediately, even to calls in progress. Assign the flow once it is finished and tested.

**Name things.** The flow name is read out to every responder who picks up ("This is *Support hotline*. You have a caller on hold.") and appears in every alert summary. Give nodes an **Optional title** and Branch branches a clear name, so the canvas and the call flow logs are easy to read.

**Write prompts in the flow's language.** Speech output, speech recognition and the system sentences (such as "invalid input") use the language the flow was created in, which is the ilert UI language of the person who created it. Create the flow with ilert set to the language your callers speak. The [AI voice agent](/call-routing/ai-voice-agent.md#which-languages-does-it-speak) is the exception: in its conversation, it follows the language the caller speaks.

## Make critical calls reach someone

A phone call is a single channel. If the responder's phone is on silent or has no signal, a flow that only rings people has nothing left to try. And if the caller gives up and hangs up while on hold, **nothing below the Route call node runs**: no voicemail is recorded and no alert is created.

For calls that must not go unanswered, create the alert **before** you route the call, and give it a short escalation delay:

* **Create alert** (with **Accept alert on answer** and a delayed escalation policy) → **Route call**
  * **Call completed** → **Call ends**
  * **No one available** → **Audio message** ("We have alerted our on-call team and will call you back.") → **Call ends**

Here is what happens on a call:

1. **Create alert** raises the alert. Its escalation policy has a delay, so nobody is notified yet.
2. **Route call** rings your responders.
3. **A responder answers and confirms the call** with a keypress or by voice. ilert accepts the alert in their name, which cancels the delayed escalation.
4. **Nobody answers, or the caller hangs up.** The alert stays open and escalates once the delay runs out, through push, SMS, voice and every other channel your responders have set up.

### Set it up

{% stepper %}
{% step %}

### Create an escalation policy with a delay

Create an [escalation policy](/on-call-management-and-escalations/escalation-policies.md) with the same escalation rules as your usual one. At the top of the escalation rules, change **Immediately** to a delay, for example **5 minutes**. See [Choosing the delay](#choosing-the-delay).
{% endstep %}

{% step %}

### Add a Create alert node directly above Route call

Add a [**Create alert**](/call-routing/call-flows/create-alert-node.md) node directly above the **Route call** node and configure it:

* **Alert source**: your call-routing alert source.
* Enable **Accept alert on answer**.
* Enable **Override alert source defaults**, select the delayed escalation policy, and set **Notification priority** to **High (with escalation)**.

The override applies the delay only to these calls. Low priority would not escalate at all, so the backup would never fire. If the alert source is used only for this line, you can make the delayed policy and High priority its defaults instead.
{% endstep %}

{% step %}

### Add the Route call node below it

Add a [**Route call**](/call-routing/call-flows/route-call-node.md) node beneath the Create alert node and add your targets. It must come after Create alert, because answering can only accept an alert that already exists.
{% endstep %}

{% step %}

### Tell the caller what happens next

Under **No one available**, add an **Audio message** telling the caller that the team has been alerted, followed by **Call ends**. Avoid a Voicemail node here: its recording is only attached to an alert created after it, so it would not reach this alert.
{% endstep %}
{% endstepper %}

### Choosing the delay

The delay must cover the longest time the Route call node can spend on a call. A responder whose phone goes to voicemail adds a little time, because ilert asks the mailbox to confirm before moving on. At the default 45-second ring timeout, allow about **1.5 minutes per target for each round of calls**, rounded up:

| Route call setup (45-second ring timeout) | Delay     |
| ----------------------------------------- | --------- |
| 1 target, or all targets simultaneously   | 2 minutes |
| 3 targets in sequential order             | 5 minutes |
| 3 targets in sequential order, 1 repeat   | 9 minutes |

Each **Repeat** adds another round. A team target counts once for each member who can be called. The delay can be at most 15 minutes, so if your setup rings longer than that, reduce the targets, the repeats or the ring timeout.

Only an ilert user can accept an alert. If an external phone number target answers, the alert is not accepted and escalates once the delay runs out.

{% hint style="warning" %}
**If the delay is shorter than the ring time, ilert starts paging while the call is still ringing**, so responders get notified about a call that is about to be answered. When in doubt, round up.
{% endhint %}

### Use it only where it matters

This setup creates an alert for **every** call that reaches it, including wrong numbers. Keep it to the calls that need it:

* Put it in one [IVR menu](/call-routing/call-flows/ivr-menu-node.md) branch, for example "Press 1 for a production outage".
* Or put a [Branch](/call-routing/call-flows/branch-node.md) node in front and send only known callers down this path, for example **Caller number** is any of your key customers' numbers. **Else** takes the normal flow.
* During an outage, many people call at once. A first Branch with a flood guard such as `trigger_count.5m >= 20` sends the extra callers to a message instead of creating an alert for each one.

## Route call

**Prefer schedules over users.** A schedule target is resolved when the call comes in, to whoever is on call then. Team targets ring each member individually.

**Make sure responders can be called.** ilert dials only **verified** phone numbers. A target that cannot be called is skipped silently: a schedule with nobody on call, or a user without a verified number. If every target is skipped, the call goes straight to **No one available** without ringing anyone.

**Tell responders which number calls them.** The call shows the call flow's own number, not the caller's. Responders should save it as a contact and let it through Do Not Disturb. The caller's number is in the alert.

**Sequential or simultaneous?** In sequential order, a responder whose phone goes to voicemail costs extra time before the next one rings. With **Call all targets simultaneously**, everyone rings at once and the first to confirm takes the call, so one mailbox does not hold up the others. External phone numbers can only be used in sequential order.

**Only use staffed external numbers.** An external phone number is connected without a confirmation step. If that line has its own voicemail or menu, the caller is connected to it and the flow counts the call as completed.

**Say something before and after.** Route call itself says nothing to the caller. Put an **Audio message** in front ("Please hold while we connect you.") and another one under **No one available**. While waiting, the caller hears hold music, or your own file if you upload one.

## Audio message and Call ends

**Keep messages short.** An Audio message cannot be skipped and starts with a one-second pause. For greetings in front of a menu, see [IVR menu](#ivr-menu).

**Explain before you hang up.** **Call ends** hangs up immediately, without a goodbye. Put an Audio message in front of it wherever the caller deserves an explanation.

**Choose the voice before you upload sound files.** Changing the flow's **Voice** clears uploaded sound files on its nodes. After changing it, check every node that used one.

## Voicemail

**Write a greeting that says how to finish.** A recording can be up to about two minutes. It stops after five seconds of silence or when the caller presses `#`. Say "Leave a message after the tone and press # when you are done, or just hang up."

**Fill No voicemail left.** A recording of two seconds or less counts as no voicemail. Add an Audio message there, or a Create alert if even a silent call matters.

**Create the alert after the voicemail.** The recording and transcript are added to an alert created **after** the Voicemail node. A caller who hangs up during the recording still counts as having left a voicemail, so the alert is still created.

## Create alert

**Know what the alert contains.** The summary reads "Incoming call *+caller* for *flow name*". The alert also has the caller's number, a link to the call log and, after a Voicemail node, the recording and transcript.

**Watch for alert grouping.** If the call-routing alert source groups alerts (for example "one open alert"), a new call is added to the open alert instead of creating its own. Use one alert per call for phone lines.

**Test after changing the alert source.** If the source is missing, the node is skipped and the call continues without an alert. After changing it, make a test call and check that the alert appears.

**One node, one alert.** Two Create alert nodes on the same path create two alerts.

## Support hours

**Use exceptions for holidays.** An exception overrides the weekly hours in both directions, so you can close on a public holiday or open on a Sunday without a second flow.

**Give the phone line its own support hours.** Editing support hours changes every flow and alert source that uses them. If the line's hours differ from your alerting hours, create a separate definition.

**One window per day.** Each weekday has a single window, in the time zone of the support hours definition. For a lunch break or a shift past midnight, nest a second Support hours node.

**Use the node for whole-flow splits.** When only one Branch condition depends on time, use `now is_in` in that condition instead.

## IVR menu

**Put the greeting in the prompt.** Callers can skip the IVR prompt with a keypress but not a separate Audio message, so an Audio message in front of the menu delays every call.

**Keep the prompt short.** Each attempt plays the prompt twice, and every retry plays it again. Long prompts add up quickly.

**Keep Retries at 1 or more, and say the valid keys.** With **Retries** set to `0`, a single wrong key can end the call.

**Use 1 to 9 for options people will say.** Speech recognition understands the numbers one to nine. Use `0`, `*` and `#` for keypad-only options such as "repeat" or "operator". If spoken numbers are misheard, turn voice detection off.

## Branch

**Always build Else.** A condition that cannot be evaluated counts as not matching, so calls end up in **Else** more often than you might expect, for example when the caller withholds their number.

**Put the flood guard first.** A counter only counts calls that reach its branch.

**Route on what the AI voice agent learned.** A Branch node after the [AI voice agent](/call-routing/ai-voice-agent.md) can use what the agent collected from the caller.

See the [Branch node](/call-routing/call-flows/branch-node.md) page for conditions and examples.

## AI voice agent

**Make Fallback reach a person.** The call takes **Fallback** not only when the agent does not understand the caller, but also when AI is not available, for example when your AI credits are used up. Route Fallback to a Route call or a Voicemail, never to an empty branch.

**Put Route call after the agent.** The agent briefs the responder on what the caller needs before the call is connected.

**Put a Support hours node, not a Branch, directly under an intent.** The agent tells the caller what happens next, and it can only predict that correctly through Route call, Voicemail, Create alert and Support hours nodes.

## Test and monitor

**Test by calling.** There is no simulator. Assign the flow to a test number, call it, and try every path: answer, don't answer, press a wrong key, call outside support hours.

**Read the call flow logs.** Under **Call routing** → **Call flow logs**, each call shows the path it took, the branches a Branch node checked, and the AI voice agent's transcript.

## FAQ

**Does answering the call resolve the alert?**\
No. The alert is accepted, not resolved. The responder resolves it once the caller's issue is handled.

**What if the call drops right after someone answers?**\
The alert is already accepted, so it does not escalate. The responder who answered owns it and can call the customer back.

**Can I reuse parts of a flow?**\
Yes. Use **Copy subtree** and **Paste subtree** to reuse a part of a flow. Each phone number has one flow.


---

# 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://docs.ilert.com/call-routing/call-flows/call-flow-best-practices.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.