Let's start looking at Local Automations with a very common use case:
- Customer is calling your hotline
- Customer reaches an IVR and hears some welcome audio
- The moment the customer hears the prompt, babelforce has already send out a request to Zendesk and created a voice ticket, documenting the customer's call
Finding Local Automations in babelforce manager
In our use case, you may have a single Text to Speech Module connected to a phone number:
Double click on the Welcome Audio and find the tab "Automations". Whenever a Local Automation is connected to the call module, you will find it under this tab. In the example below, the "Action" of the Automation is called voice ticket create.
Basics you need to know when working with Automations
The following steps are central for both Local and Global automations.
-
Setting up an integration: To allow babelforce to interact with any external system, you need to grand babelforce access (we call this Integration).
- Please read this article before you continue on how to set it up for Zendesk.
- In case you don't use Zendesk, we have other systems you can use instead, find an overview here: Everything on pre-build integrations
-
An Automation is very specific: often, you will need a row of automations to achieve whatever goal you have.
- For instance, one automation creates a ticket, in another automation you might want to add the customer's call reason to the ticket - in this case, you will need something we call "update" ticket.
- On a more technical level you may say that Automations, in most cases, translate to specific API calls to the system
- Automations can be difficult to set up: The better you know what you want in which scenario, the easier it gets to design your Automations. Nevertheless, it takes time to make them work correctly. Also, as two systems communicate with one another, there might sometimes be delays or maybe, when going live, you will discover that large traffic causes the communication to slow down. In these cases, you will have to revisit and maybe rethink some of the setup you made
- Think outside the box: We at babelforce will always try to help you with a good solution. However, sometimes, you might know your system better than we do. Or your partner does. In this case, you might have a much better solution in mind than we do. Just give it a try or ask the team what they think about it.
Setting up the local Automation: A voice ticket for every incoming call
Go to your call flow in the map view and open the first call module after the phone number with a double click:
Find the tab "Automations" and click on the blue "+" to add a new automation
A new dialog opens. The first part you could fill as follows:
| Name in babelforce | What it means | Example value |
| Label | The name of the Local Automation, indicating what it is used for | "Create ZD Ticket" |
| Position | In most modules, decide between "Before" and "After". This decides whether an Automation is executed when the call first reaches a module (before) or when it leaves a module (after) | In our case, "Before" makes sense as the ticket should be created the moment the call reaches the Audio module |
| Priority | The highest priority will be executed first, Automations with the same priorities run at random. Priorities are not easy, we will focus on them in more detail later. | "1" (as there are no other Local Automations) |
| Action | This drop-down presents all available out-of-the-box Actions babelforce offers. In a later section, we will explain each of the categories in more detail |
find Zendesk > Tickets > Lookup enduser & create voice ticket You can of course also use the Omni-channel ticket, however, you need the right subscription with Zendesk for it to work |
| Trigger | In any automation, you have the option to define conditions (within triggers) that restrict it from being executed. This can easily get complicated and it will be looked at in detail in the next chapter. | Use the Always trigger built in the last chapter (this means that the Automation is always executed whenever a call reaches the call module) |
The image below highlights the discussed fields and presents the example values.
Once you selected the right action, a dialog is added with relevant details. Even though you will see a long list of fields, there is little you really have to do. Let's first look at what you see without changing anything.
In the image below you see two fields which you should consider adjusting:
-
Integration: from the drop down select the connection you setup with your Zendesk (if you see none, you need to set it up, also see the section above on the basic of Automations)
-
You can save the Automation as soon as you selected an integration as this is the only required field. All other required fields are filled with defaults.
-
- Subject: We do suggest adjusting the Subject to something that fits your processes. Right now, it will only say "Incoming Call" but for a first try you can also just leave it this way
Below you see an example Automation containing more data. We will explain what the fields mean and whether they are relevant for now.
| Field label | Description | Example values |
|
These fields are all related to the lookup of the end user. We suggest for now not to adjust them for now. The standard setup is to always either lookup an end user in Zendesk, if no user exists, create a new one and attach the ticket. | Leave the standard setup as is |
| Call type | Select what type of call you are logging | Inbound (standard) |
| Push to agent | The ticket can be pushed to the agent taking the call. However, as it is created BEFORE an agent takes the call, this setting is not relevant. We will need a separate action to push the ticket when the call is connected. | false (standard) |
|
Zendesk offers a number of standard fields. You can select any value that matches your processes within Zendesk.
Tags are often used for reporting. Please consider, fields like "priority" might only make sense to fill once you know what the call's priority actually is (you could add a priority after identifying the customer's call reason). |
See image below for examples |
|
To fill custom and additional fields or groups, you need to identify the respective ids of these objects as well as the allowed values. It is an advanced feature we suggest you only use if you already have some experience with expert Zendesk setups. | See examples in picture: added one custom field as well as a group id |
| Requester ID |
When creating this automation, this filed will always be prefilled. The Request ID is returned by Zendesk to babelforce when looking up the end user who created the call. Do not remove this placeholder unless you have a clearly defined process in which you handle users differently. |
{integraiton.zendesk_v2. enduser.id} |
| Assignee id |
If you create the ticket, for instance, when connecting to an agent or after the call, this field makes sense: you add a placeholder representing the agent's id ({agent.sourceId}). However, in our use case, you have no assignee (unless you want to auto-assign all incoming tickets to a specific user). Therefore, just leave it empty |
Below, you see an example of a ticket that was created when the call connected to the call module. There you see the title containing the number of the caller. Also, you can see that tags, contact reason and priority that were added in the Automation above. You also see some basic information about the call - a service from Zendesk whenever you use a voice ticket.
Comments
0 comments
Please sign in to leave a comment.