Home > LiveOps EXTRAS! > Application Notes > App Note 022 - Call Flow Best Practices

App Note 022 - Call Flow Best Practices


This Application Note will introduce you to several Best Practices when creating your own Call Flows using the LiveOps Call Flow Authoring tool, also known as CFA.


It is important to realize that your Call Center’s menu system may likely be the first interaction a caller has with your business. This menu system (commonly referred to as an Interactive Voice Response system, IVR, Voice Script or Voice Application) should portray your company in a positive light, be clear and easy to understand and offer helpful choices rather than a confusing maze.  It should also represent your company’s desired branding in an appropriate manner.
This Application Note will provide helpful tips and concepts for you to adopt (and avoid) to make your Call Flows and Menus as customer friendly and error free as possible.

Menu Structure Best Practices

When designing a customer-facing menu structure you need to consider many different areas including menu choices, menu depth, voice recordings and other nuances.

Prompt Content and Menu Wording

Consider the branding of your company.  Compose the content of your prompts and menus using text and wording that reflect your brand.

Is your business a financial institution?  Or a children’s clothing store?  The wording of your prompts and options could be very different depending on your industry and target audience.

Voice Talent

Does your voice talent reflect the branding you want? Think about the type of persona you want to present to your customers and obtain voice talent which embodies that feel.

It isn’t necessary to hire professional voice talent.  Professional-sounding recordings can be created in-house with free recording software (like Audacity).  But do take the time to recruit someone whose voice and delivery reinforces your image and brand.

Keep it Simple

Design your prompts and menus from the caller’s perspective, not your internal process.  Don’t present more than five options in a menu.  And use only two (or a maximum of three) menu levels.

Escape Routes

Depending on your business drivers, you may want to offer an “escape route” to your callers: either a spoken prompt (e.g. “Press ZERO to speak directly with a representative”) or a hidden option (‘0’ transfers the caller to a receptionist but it is not explicitly mentioned in the spoken menu prompt).

Default Options

Think about how you want the call to be handled if the caller does nothing, or presses an invalid key for that menu. You want to make sure you give them a couple of chances (guided by the right messaging) to press the right option. 

If they don’t press any key or press the wrong keys where should they be sent to?  An Agent?  A Receptionist?  Back to the top of the menu?

Call Arrival Best Practices

The Arrival Phase of the LiveOps Call Flow Authoring tool controls how a call is handled when it initially reaches your Call Center. 

Arrival Prompts

It is usually a good Idea to have two separate messages configured here: One for your initial Greeting, and another for the main menu or main messaging prompts.

Separating these two messages into two distinct recorded prompts allows for more flexibility if you need to change menu options later.

Open Hours

You can do a Business Hours check upon call arrival to determine where in the call flow it is appropriate to send the caller: either to the Main Menu during business hours or to an after-hours message or Holiday Greeting.

Transfer Best Practices

When transferring a call out of your Call Center, it’s advised that you play a message telling the caller they are being transferred. Think about where they are being transferred to as well.

Voice Mail

For instance, if you know that all after-hours calls will go to an external voice mail system, make sure the voice mail greeting the caller will hear meshes well with the Call Center transfer messages or prompts. 

For example, make sure you are not repeating the greeting they just heard.  And that the voice talent used to record the two messages matches.

Transfer Failures

You should consider what should happen if a transfer is not successful.  Do you want your Call Center to wait for an answer before completing the transfer, or take the call back and try dialing another number?

Disconnecting Calls

If you decide to hang up on a caller (after hours, queue is too crowded, estimated wait time is too high) you should, at the very least, play a message to the caller indicating that the system is about to hang up on them.

Reporting on Transfers

To ensure that you can report on transfer failures and other similar incidents, you can create and use Call Attributes.  
For example, consider creating a Call Attribute called “Xfer Reason” with options such as “After Hours VM”, “Too Many Errors”, “External Xfer Failure” and “CFA Intentional Disconnect”.  Set this attribute accordingly prior to taking any of these actions.  You can then run reports that display the “cause” for why calls were not answered by an agent.

Note: For additional assistance, consult with your LiveOps Implementation Team on the best use of reporting and disposition attributes in your call flows.

Queueing Best Practices

The Queue Phase of the LiveOps Call Flow Authoring tool controls the experience for a caller while waiting for an agent or representative. This phase of the caller experience should align with the call flow in terms of branding.


LiveOps provides a limited amount of basic, license-free music option.  Many customers choose to add their own licensed music files.  Music played while in queue and music played to a caller when placed on hold can both be set separately. 

Note: All music is subject to legal and licensing considerations.  Please obey all relevant laws and regulations.

You can obtain licensed music from many sources.  And there are quite a few websites that offer free or low-cost music-on-hold (MoH) files.  Consider the following sites:



Consider using the “music while in queue” time to provide relevant information to your customers, such as upcoming events, new product announcements or special offers.

You can also let callers know how to connect to you on the web or through social media.

And consider changing your messages frequently to align with your marketing strategies.

Digit Collection Best Practices

Collecting information from the caller can be useful.  For example: collecting an account number for contract verification; or collecting a user ID for assignment to the proper team, region or queue.

If the digit collection is lengthy or complex, you can consider adding appropriate of “sorry prompts” prompts that change depending on the number of times a caller is attempting to enter their input.

Escalating Error Prompts

The CFA “Collect Digits” action has built-in error controls but does not have any built-in escalation logic by default.

With some creative design you can create escalating error prompts that play a different error message based on the number of error attempts.  For example, the first time the caller enters an invalid entry you can play "I'm sorry, I didn't get that."  The second time the caller errors, it plays "I'm sorry, I still didn't get that.  Your account number is an 8 or 9-digit number located in the upper left hand corner of your paper statement." 

Escalating error prompts may need to be different based on the type of error as well (i.e., No Input, Too Few Numbers Input, Too Many Numbers Input).

Escalating error prompts take more effort to create as compared to using only the standard Collect Digits action's built-in error logic. 

Escalating Error Prompts - Example

Here is an example call flow that collects a 3-6 digit Store Number (with optional # termination), allowing a maximum of 3 tries overall. 

We start by clearing the relevant variables: StoreNumber and StoreNumberInputCounter.




Then we use a “Loop Until” action that controls what prompts to play.

The main “Collect Digits” action and an “If | Then | Else” action are embedded within the Loop action.

Notice how the Minimum Digits to collect is 1 instead of 3, and the Maximum Digits to collect is 7 instead of 6.  Also notice that the Maximum Tries is 1.




The “If | Then | Else” Action inspects the variables and plays the correct error prompts.




A final embedded “If | Then | Else” action controls final error prompts and logic for Too Few Numbers and Too Many numbers input.





Most of the time, escalating error prompts do not need to differentiate between 'Too Few Numbers Input' and 'Too Many Numbers Input' – both cases are just considered 'Invalid Input'.  The 'No Input' vs 'Invalid Input' error types are usually separate though. 

The call flow example above would be simpler if you chose to combine the “Too Few/Many” error types together.  But this example shows a more complete scenario in case the hyper segregated escalating error logic is needed.

You can apply the same principles to creating escalating error prompts for the Menu action.

Additional Resources

Version Information

Date Version Contributors Content
May, 2015 1.0

Katherine Pietrycha

Matia Walker

Initial AppNote
Last modified


This page has no custom tags.


This page has no classifications.