There are many call types when using a VoIP platform. For example our Call History reports are very exhaustive and are designed mainly to provide call data for troubleshooting. This means that the platform registers and reports all Call Attempts made, even if these were not completed or failed. Call History is designed to track overall platform actions made by any user in your organization, so these are not call center reports. By definition comparing Wallboard Reports to Call History reports is not good practice, unless you consider the information in this document. If we used all this data to track your calls on the Wallboard then your statistics wouldn't be useful, believe us we tried it, and the data was all over the place our customers were not happy. Based on the necessities of our customers and on months of data evaluation we have determined how calls should be tracked, trying to offer the broader options with an accurate approach. However, we've learned that these cannot be final. In the process, we've identified different types of calls that we will incorporate as statistics in the future, call center statistics should be dynamic and not static. Just as your numbers change in real time, call behavior will also change. We've listed all call types and incorporated examples of how these are tracked and why.
We've corrected how inbound call events were interpreted, this has been done through evaluating all call events and the need to see exact calls that offer value for a Call Center. Inbound Calls have many interpretations on the platform side. Wallboard captures all events that come from the platform but some of these, for call center tracking are not necessary.
A correct inbound call for the Wallboard is a call that came from an external source and ended up ringing to an Agent. Examples of inbound calls that we track for your agents:
This is a regular Call Center Inbound Call. Basically, a call hits a Queue and it rings your agents when an agent Answers we register a successful Inbound Call.
Note: For queue dispatches to be counted correctly agents should only register one device per queue. You can still add that device to the queue. Just make sure you are not logged in twice in the same queue with different devices. Calls are still registered when multiple devices log on the queue but the agent status will toggle between online and offline since the agent is never truly offline or busy unless both devices are in the same status.
We've seen many call center applications that don't track direct calls to agents, but only those that hit a call queue. Based on our customer's needs we found that calls may come directly and not through a queue and these should count for your agent's call count and call time as well. So any call that originated by dialing a DID and ended in an Agent's device is counted as an Inbound call.
There are many ways to count Inbound Calls but there are some that we have noticed don't offer value and by definition.
Agents have different answering rule configurations and may have multiple devices on simultaneous ring. And you know what? It is a nightmare for a Call Center application. Each of your phones receives an independent call whenever a call hits your extension. So what do we do? All those phones ring but we group them in a single call so it really doesn't matter, we won't register those simultaneous calls independently and that way your statistics are efficient. So this means, one call hits and agent with 3 devices in simultaneous ring, the PBX reports 3 incoming calls but we know its the same call hitting 3 devices not 3 different calls.
So you need to track the time spent on actual calls to your customers and in the Call History you see all those Internal Calls (calls between extensions). These are not good for your stats so we don't include internal Calls in our Wallboard Reports. However we might consider Including them in future reports, but currently there's not enough demand for the feature and it simply doesn't offer enough value to our customers.
This is the typical call we were referring to when we talked about Call History tracking all Call Attempts. Many customers in Call Centers use the Click-To-Dial feature, this basically places a call on your phones whenever you click a number on a Supported Browser when using the Click-To-Dial browser extension, or when you're checking you call history and click on a number there. The problem with Click-To-Dial is it's behavior. It generates Call Attempts on different instances for example: If you are extension 202 you Click on a number (555-555-5555) the platform makes a Call to the user 202. The user 202 picks up the phone where the platform is dialing and when answered it generates a new call from the user 202 to the desired number (555-555-5555). So in call history a Click-To-Call is considered an Inbound Call to the extension soliciting the Click-To-Call (202) and then an Outbound Call made to the clicked number (555-555-5555). However we discard the Inbound Call for statistics and Wallboard Reports since the offer no value to the Call Center.
These are tricky, from the platform's perspective a Call answered by voicemail is considered an Inbound Call (we agree on that definition but we count also count a missed call). The platform considers a Voice Mail call an answered call because technically it was answered by the Voice Mail Application.
Outbound Calls are easier to interpret since they only go one way, we only discard Internal Calls and Click-To-Dial will only count the call made from the extension to the Outbound Number. Failed attempts, by wrong numbers vary depending if the VoIP Platform registered on event, sometimes it won’t even attempt to dial and those we won’t even have a record to evaluate.
We have defined missed calls previously but just to review it here are our considerations for Wallboard Reports:
Only those missed calls not considered internal will show up on the report.
Calls answered by the voicemail applications are considered missed calls.
Calls with a ringing event registered and no answered event are considered missed calls.
Now that general rules for missed calls have been defined we may explain this case. Queue dispatched calls that are not answered are not considered missed calls for any agent. The reason is the call may remain on the queue, and the platform will report more than one missed call for more than one agent (this is not useful and generates a lot of inconsistencies). For queue dispatches we consider a missed / abandoned call, whenever a caller ends the call without being answered by an agent. This gets registered as an abandoned call for the queue and is viewed in the Tiles Panel.
For SLA it is important to consider many aspects, first SLA is an inbound call metric the other of them being how we determine a missed call to remove issues where SLA calculation. We used to consider every call and it went higher than 100% since many devices produced many missed calls or many calls showed and answered. As we’ve stated before in this document we found out the platform reported voice mail calls as an answered call too only this time the call shows answered by the voice mail application. These calls triggered an answered and missed call at the same time, which resulted in a higher call count than the number of existing calls. This has been adjusted and voice-mail calls are no longer considered as answered calls but missed calls. With all the other adjustments, we guarantee our SLA is accurate.