2.1.1 - Inbound Calls (Calls from Source Queue)

The first call source we are looking at is Queue. All calls matching this source are initiated by customers, so they are incoming. But it's a bit more complicated than that, so let's look at the details.

Differentiating "Parent" and "Child" calls

When your service receives an incoming call, there will always be a "Parent" call with the following parameters:

  • type = Inbound
  • source = queue
  • domain = external

Whenever the platform tries to connect one of your agents with this incoming call, it will create a  "Child" call that has these parameters:

  • type = Outbound
  • source = queue
  • domain = internal

If the agent doesn't pick up or rejects the Child call, the platform will call the next available agent, and so on. This means, there can be a very large number of Child calls for each Inbound Parent call. You recognize a successful Child call by looking at the call duration which will be greater than 0. There also are ways to differentiate Child calls by hangup reason, but this will go too far for now.

To understand this better, let's look at some examples.

Use cases

First use case: Call Duration

Let's say you create a ticket for every call. You learned how to do that in section 1.5. Whenever the call is finished, you want to know how long the call lasted. In other words, you want to have the exact time between the start and the end of the call printed in your ticket.

To achieve this, babelforce needs to update the ticket. So you need two events, one to create a ticket and another to have it updated. The update happens on the finished events, that's when you add the call duration to the ticket (placeholder: {call.duration}). 

Give it a try: Build an event on "Call Finished", select as Action "Update Ticket" (in your Helpdesk type) and take the trigger Always.

Now call your test number, have your agent accept the call and end the call. You will see that you don't only have one but two updates on your ticket. One duration will be longer than the other.

What happened? Remember, every Inbound Call also has a Child call (which is an outbound call connected to the agent). This means, the moment the customer hangs up the call, not only one call is ended but two (the Inbound and the Outbound call). So what you now see in the ticket is the call duration of the Parent call (which is the full length of the phone call) and the duration of the Child call (which is the equivalent to the talk time of the caller with the agent).

 

What you do instead: You build a trigger that only fires if Call type: inbound is given. See the screenshot for details.

And that's how the event should look like in the end:

As you can see, we are using the trigger you build above. Now your ticket will only have one update informing you how long the whole call lasted.

Second use case: Talk Time

As you remember, in our first try to update a ticket with the call duration, the tickets were updated twice. This use case wants to look at the second update, the talk time.

Every time, a call that was connected to an agent is finished, we want to add the talk time to the ticket. This way you know how long your agent talked to the customer.

Again, you will need to build a trigger that fires on the Child call to ensures that you only print the Talk Time. It's slightly more complex than the one we build in the use case above. But let's look at the details.

You will need three conditions:

  1. Call duration > 0 - you will need this condition to avoid printing the talk time of unsuccessful calls. What if you don't? Imagine you have a call that tries to reach three different agents but none of them is answering the call - what would happen? Without this condition you would have three updates on the ticket all saying "Talk time: 0 seconds". 
  2. Type: Outbound is given - here you ensure that no update happens on an Inbound Call, in other words, it fires on the Child call
  3. Call source: queue - the last conditions ensure that the trigger only fires on calls that came from the queue

You are probably wondering why it has to be so complicated. Wouldn't be the Call type: outbound & the condition on the call duration enough? And you are right, if you are only planning to integrate Inbound calls (so you decide not to integrate Outbound, Dialer or Transferred calls) you actually do with the first two conditions. However, if you are planning to integrate all calls that are leaving your platform, you need to make sure that the trigger only fires once and only under the conditions you want them to.

To round that up, exchange the trigger in the event you created before and adjust the ticket description in the event. It could look like this: 

 

And this could be the result in your Helpdesk:

Now that you learned all about Inbound Calls, let's move on to calls that you or your agents do to call a customer, usually referred to as "Outbound Calls". There are four different Outbound call sourced, we will start with API. 

 

Have more questions? Submit a request