How do I control process flows?


This article summarises briefly all the core mechanisms of the babelforce manager to create customer experiences and end-to-end service processes. If you want to learn about process flows in detail, we recommend you to read our tutorial, however, this article provides a short overview of babelforce mechanisms.

You can control every aspect of both the end-user journey as well as the back-end processing of information. The core means to control processes are:

1. Triggers - define conditions used to evaluate the current context

2. Selections - dynamically choose the agents who will handle end-user interactions

3. Events - interaction and system events that you can use to fire off an action

4. Actions - produce a change or effect the next step in a component or an interaction channel

Here is an example scenario that can be created using all of these control mechanisms:

The user calls the customer service hotline, the call gets routed to the right agent in the contact centre. The agent receives a ticket in Zendesk at the same time as the call arrives. The ticket already has the name and details of the customer. The ticket is also tagged with information about the caller and the call.

So how do you configure the babelforce manager to do this:


An inbound call to the babelforce telephone number for your contact centre (event is "Inbound Call") results in action "Lookup end-user" in Zendesk and a second action to create a new ticket.

Simultaneously, a trigger checks that the hotline number called is the one for the support team. This information is used to make a selection of available agents who are in the support team. Other agents who handle other processes will not be called.

Once the agent accepts the call, the event "Call bridged" is used to execute the action "Push ticket" to the that agent.

The actions that do things to Zendesk tickets are also configured to add tags with additional information so that Zendesk can process the ticket. The link between an event and an action can itself depend on a trigger: e.g. only tag the ticket with "brand_a" if the support telephone number called matches "445012345555".

The same core mechanisms are then available for you to reuse in all kinds of other situations. For example, the call can be routed in the IVR based on triggers. So you can define common sets of conditions in triggers and make use of them repeatedly for all kinds of interaction and process implementations.




Have more questions? Submit a request