Monitoring agent presence and call acceptance behavior

For inter-day management, team leads and QA-managers in contact centers often want to know how many calls were not actively accepted by agents. Sometimes, there might also be technical issues at hand. Therefore, good monitoring can be a quick and easy way to help agents getting their workstation fixed.

Moreover, for larger teams that are spread out over different sites or where agents are working remotely, team leads need to have an overview of the agent's presence (are agents actually available to take calls or are they on a break?). 

It's not always easy to keep track of all these different data points, you need to switch between systems and monitors. But we got a solution for. You can have all the data at one glance if you push this information to Geckoboard.

What the dashboard shows:

All data on the dashboard shows a daily score. So it will start at 0 the next day.

And that's what each tile shows:

• Rejected calls - Here you see how many times agents actively declined a call
• Busy on incoming calls - This tile shows how many times agents were busy to the babelforce platform when it tried to forward a call to them
• Agent unreachable  - This tile shows how many times agents were busy to the babelforce platform when it tried to forward a call to them
• Number of not accepted calls - In this tile we show how many times agents didn't accept calls that were forwarded from babelforce to them
• Agent presence overview - This list gives an overview of the current available statuses (usually referred to as Presence status) of your agents and at which time they switched to this status

If you are not sure what the difference is between "Presence" and "Line-status" or if you want to learn more about "unreachable", "declined" and "busy" we recommend you to read these two articles:

• Article on Presence status
• Article on in-line-status

The datasets

We created two datasets for this dashboard.

The first we called agent.status.change and it can be used to send data about presence and line-status. We define four fields:

• agentname
• status
• date
• time

{
   "fields": {
     "agentname": {
       "type": "string",
       "name": "Agent Name",
       "optional": false
     },
     "status": {
       "type": "string",
       "name": "Agent status",
       "optional": false
     },
     "date": {
       "type": "date",
       "name": "Date",
       "optional": false
     },
     "time": {
       "type": "string",
       "name": "Time",
       "optional": false
     }
   }
}

The second dataset, not.accepted.calls, we will use to analyze how many calls were not taken by agents even though the platform tried to reach them.

Here we have three fields:

• agentname
• date
• time

{
   "fields": {
     "agentname": {
     "type": "string",
     "name": "Agent Name",
     "optional": false
   },
   "date": {
     "type": "date",
     "name": "Date",
     "optional": false
   },
   "time": {
     "type": "string",
     "name": "Time",
     "optional": false
   }
 }
}

Sending data from babelforce to Geckoboard

In babelforce, you will need three Triggers and three Automations.

Triggers

First, you need the "Always" Trigger which is standard to every babelforce template.

Second, you need a Trigger that fires if either of the three agent states apply:

• busy
• declined
• unreachable

Make sure to select the logic type "Match any Trigger"

Third, create a Trigger for all incoming calls that are forwarded to an agent. It looks somewhat complex but don't worry. This Trigger will only fire if no agent picked up the phone.

Next, let's move on to the Automations we need.

Automations

This Automation always sends the defined data points to Geckoboard as soon as an agent changes their presence.

This Automation runs and sends the customized data to Geckoboard as soon as the agent line state changes to either busy, declined or unreachable. 

As you can see, we are sending data to the same dataset. Even though the content is different, we can reuse it for multiple purposes.

The last event sends customized data to the second Geckoboard dataset whenever a call is finished with the trigger "Inbound call not accepted".

Creating the reports on Geckoboard

Rejected calls Busy, on incoming calls, Agent unreachable  

All three tiles use the the same settings and use the dataset "agent.status.change". The only difference is the filter - make sure to select the correct Agent status filter for each of the tiles. If you want, you can easily switch on a goal as well.

Number of not accepted calls 

This tile uses the not.accepted.calls dashboard and has the same settings as the dashboard above. However, you do not need any filter.Agent presence overview 

The last tile uses the agent.status.change dataset again. You create three columns to see the agent's name, status and the time it was changed.

Important is the agent status filter. There is one important thing to keep in mind: if you use the same dataset as for the agent states, you need to avoid using the standard "Busy" presence activated. Best you give the unavailable presences more precise names, as for instance "busy-lunch", "busy-meeting", "busy-training", "finished-shift". Otherwise, agents who have the line-state busy will also appear in this list.