Let's move to the Integrated processes > Global Automations tab. By pressing the "Add" button in the upper right corner of this tab, you can create new Global Automations.
After you set a label and the priority, you are asked to select an Event. A list of 6 main categories is presented to you.
You can open any section to select a specific event, for instance like this:
So what are all these Events?
You can imagine them as a set of Triggers. They fire under certain conditions which we roughly explain in the table below. It's not a technical description, but it gives you an idea of what each Event does.
Events will fire as soon as they become true, under the condition that you use the Trigger "always". We'll explain in section 2 of this chapter how you can combine Events and Triggers to control the automation and integration processes more granularly. But we mention this because you should always keep one thing in mind: try to define Events as precisely as possible so they only apply to the cases you want something to happen (as for instance a ticket creation only when a call is bridged).
| Description | Use cases | |
| Agent | ||
| Agent created | Whenever an agent is created this Event applies. This can either be an agent created on the platform (internal) or an agent synchronized from an external source (like your Helpdesk or CRM) | There are many reasons why this is useful: Maybe management wants to receive an email for every new agent created. Or your IT guys have to set up a new phone device for every new agent so they need this information and every time a new agent is created, they receive a ticket in their internal ticketing system. You could also imagine that your billing system wants to be informed about new licenses |
| Agent deleted | Whenever an agent is deleted this Event applies. | The reasons are the same as for "Agent created" just reverse: Management has to ensure that all personal data is deleted when an employee leaves, IT wants to delete the phone provisioning and billing knows that they have to pay for one license less next month. |
| Presence changed | Every time an agent actively switches from available to busy or to any other presence state you might have created in your account, this Event becomes true. | Monitoring presence changes is central for many contact centers, especially if your team is spread out or working remotely. This event allows you to see exactly when which agent changed her status. You can do calculations based on the result (how long did one agent stay in which status, etc.). For personal planning, this information can be crucial. |
| State changed | There is a difference between "Presence" and "State". While the presence is actively influenced by the agent, the agent "state" is a technical status that reveals to the queuing algorithm whether or not a call can be forwarded to an agent. Also, the state (also referred to as "line-state") reveals if there is an issue with a babelforce user. Find out more about the different states here. So whenever a state changes, this Event fires. |
This event is also mainly used for reporting purposes. Team leads and supervisors are able to see which agents are currently in a call but they can also have reports available if an agent is unreachable or busy, which usually indicates technical problems. This way, agents can be supported and technical problems can easily be recognized and debugged. |
| Agent updated | An agent is updated means that the agent-user receives a new phone number, a name change or a new email address. | To receive information on agent updates can be crucial. IT might need to adjust the telephone device or the team lead needs to know if a different phone is used. |
| Call | ||
| Call Created | As soon as any call, regardless of the type, reaches the platform, this Event fires. This also means you need to be careful to use this Event as it fires for Inbound and Outbound calls. As every Inbound Call also creates Outbound Calls when they try to connect to an agent, you might not get the results you are expecting. So only use this Event if you feel comfortable combining Events with Triggers. | Usually, you use this Event in connection with Outbound Calls conducted by agents. The moment the Outbound Call is created, a record is put in your CRM or helpdesk. |
| Inbound Call | The inbound Event only fires when the call signal of an Inbound Call (type = inbound) reaches the babelforce platform | If you want to run any process the moment an incoming call is created this is the Event you need. Imagine, you want to have a log for any new call, or maybe a ticket: you found the Event you were looking for. |
| Outbound Call | The Outbound Event only fires when the call signal of an Outbound Call (type=outbound) reaches the babelforce platform. Outbound Calls can either be resulting from an incoming call (the agent is called by the platform to then connect to the caller) or they are initiated by agents or the outbound dialer. | This Event is necessary if you want to run processes whenever an Outbound Call is created. For instance, you want to count how often the platform tried to reach a certain agent. Also, you can use this Event to create tickets or records whenever an Outbound Call is made by your agent. |
| Call finished | Every time a call is finished this Event applies. Watch out: this Event fires every time a call is finished. For instance, incoming calls that are calling to an agent will finish at least twice: the Inbound and the Outbound to the agent both end and each time the Event applies. This means you need to carefully define at which point the Event is supposed to apply by adding the right trigger. | There are many scenarios for this Event: adding talk time, call duration, queue wait time, call recording or any other information that might only be available after a call was finished. |
| Call bridged | The moment an Inbound Call is successfully connected with an agent this Event fires. | You can use this Event to create records or tickets for incoming calls, add or set tags or print and push customer information whenever the agent is talking to the customer. |
| Call Taken | This Event fires the moment a call initiated by an agent is taken by the customer | For instance, you use this Event if you want to create a ticket for an outgoing call only if the customer who was called took the call. |
| Call transferred | This Event fires whenever a call was successfully transferred to another agent. | Most managers want to know how calls were forwarded to other agents. With this Event, direct transfers can easily be tagged. |
| Call transferring | If calls are forwarded to a queue and not to another agent you want to use this Event. | For monitoring, quality assessment, and process improvement this is a crucial Event. Often, it is used if customers either called the wrong number, selected the wrong reason in IVR or had to be escalated. Each case can tell a story about the implemented processes and can help to make them better. |
| Recording | ||
| Voice Recording deleted | Whenever a voice recording is deleted, this Event fires. | It is relevant for any business process that requires information about the deletion of a voice recording. For instance, recordings are only deleted in case of a customer complained. Whenever this happens the compliance team receives a ticket and can review the case. |
| Voice Recording finished | If a voice recording is completed and stored the Event is true | Whether you record calls or offer a voice mail to your customers - you want to be informed about it. Ideally, you have a link to the recording which you can send via email or add to a ticket or record. |
| SMS | ||
| SMS received | This Event becomes true the moment the platform receives an SMS | With this Event, you can set up any kind of process that should be initiated the moment an SMS is received, for instance, create a new ticket, inform a certain group of people about the SMS, etc. |
| SMS sent | Sending out an SMS will trigger this Event | You want to use this Event if you are planning on keeping a record of the SMS you sent. |
| Transaction | ||
| Transaction created | With each created transaction this Event fires. | As transactions help you to log certain Events within babelforce, you can have these logged out to any system of record. For instance, you might want to be informed every time a customer with a certain ID is leaving a voice message. Whenever this customer is triggering a transaction you also receive an email notifying you about it. |
Now you know at which point an Automation can be run. However, this alone does not do anything. To create the magic you will need the last element of the Automation: Actions that are performed at the defined point within the flow. We will give an overview of all available Actions in the next section, 1.2.
