1.1 - The Call flow editor (V2)

If you are not quite sure what a call flow is, we suggest you go back to our initial chapter that explains this part in detail.

Building call flows with babelforce is easy once you get the hang of it. To get started go to IVR call-flows > Call flows.

Each flow consists of Modules that you link to each other. Your call flow will look like a tree in the end. The flow manager gives you the option to view these trees, taking a number as entrance point. It could look like this for instance: 

Example_map_view.PNG

Each pictograph represents one module type. Below we will explain each of them.

However, to give you a more general idea of what these modules are before we get into too much details: You can imagine them to be building blocks which enable you to build anything you want in your call flow. Each of these blocks has special features. Some allow an input, others forward the call to a queue. But you will learn the details below.

For an overview, these are the eight modules available:

  1. ACD.png
  2. Audio_Player.png
  3. Switch_Node.png
  4. Input_Reader.png
  5. Agent_Queue.png
  6. Voice_Recording.png
  7. Simple_Menu.png
  8. Transfer.png

ACD_pictogram.pngAutomatic Call Distribution 

The module that you will always need is the Automatic Call Distribution (ACD). ACDs route a call into a call queue (customers may hear an audio recording while waiting). Without an ACDs, you could not connect your customers with an agent. In the most basic call flow we will discuss in the next section, you will only need to connect this module with a queue and a phone number and your team can start taking calls. The selections are defined in the setting section of the queue, but without the ACD you would never get the customer's call to the point of being selected at all.

The ACD also defines what's happening to a call that is not answered by one of your agents. You could, for instance, forward the caller to a 'sorry' audio if non of your agents is available. This takes us to the next module type: the Audio Player.

Audio_Player_pictogram.pngAudio Player

Audio Players are what they seem to be (no hidden features): they simply play an audio file. They don't do anything else, therefore they are usually linked to other module types. Or they are at the very end of a flow, saying good bye to a customer.

Often, Prompt Players will welcome a customer before they are forwarded to the queue, and they are in many cases used within an ACD (playing the queue wait music). So if you think back to the process maps from the previous chapter: Audio player where always green boxes. 

They can actually be used for a number of really cool features - but we'll get to that when we discuss Local Automations.

Switch_Node_pictogram.png Switch Node

You can imagine a Switch Node as a small program that makes numerous decisions based on a set of rules, all within a few milliseconds. In our process charts, these were those diamante shaped purpel decision points.

It's like being at an intersection with roads going in different directions to different destinations. Maybe you want to see your grandma? Or perhaps you want to go and buy a new chair? What's triggering your decision? Your grandma called and said she prepared your favorite cake - so are you hungry? Or maybe your back hurts terribly because your old chair broke? Where you go depends on the conditions and their priority at that moment you reach the junction.

The Switch Node obviously has no needs but you can feed it with certain triggers that are comparable to decision points at an intersection. Whatever way the call goes after entering the Switch Node depends on the testing of certain predefined conditions: Is the caller reaching you in or after business hours? From which number is the caller reaching the line? Is an agent logged into the system and ready to take a call? You can define as many conditions as you want and you can even test customer inputs in connection with the Input Reader. This leads us directly to the next module.

Input_Reader_pictogram.png Input Reader

With Input Readers, you are able to store customer inputs. For instance, you ask the customer to select a language or to choose which type of problem they have and they making their choice with the dial pad. This module plays a prompt, stores the DTMF response (any number between 1 - 9, *, #) and it offers a range of settings and therefore great flexibility. Input Readers often work together with a Switch Node which reads the customer's selection, and forwards the call accordingly. 

Agent_Queue_pictogram.pngAgent Queue 

This is a small but useful module that makes it easier for agents working in multiple regions or for multiple brands to recognize a caller's origin. For instance, if an agent picks up the phone, the Agent Queue tells the agent which language the caller speaks. This module is used within the ACD module.

Voice_Recording_pictogram.png Voice Recording

In case all your agents are busy or a caller reaches your line after business hours, Voice Recording module makes it possible to store any voice message from your customers. They can easily be set up at the end of any call flow. The recordings can be pushed to your CRM or helpdesk or stored on your own servers.

Simple_Menu_pictogram.png Simple Menu

A simple menu offers limited options for customers to make a selection. It is the simpler version of an Input Reader and can be used for directly routing calls to another module after a selection was made. The caller enters a numerical option, and based on this option is routed to a predefined module.

One disadvantage is the lack of a 'barge-in delay'. This means that customers cannot interrupt the prompt by pressing the number of their choice - they always have to wait until the end of the prompt. With Input Readers however, barge-in can be configured.

Transfer_pictogram.png Transfer

The Transfer module is the easiest way to forward calls to office workers that do not work in Support or Sales but have a direct line. It can be configured by simply mapping the employees phone number to this module and then link the employees device. This device can be reached via SIP ID, mobile number, etc.

The next section will look at triggers.

Have more questions? Submit a request