I would like to kill call center challenges with one blog! In many call center environments, it is possible that an agent has a Direct in Dial (e.g. DID) number that a client might call and bypass the entire call center process! For a call center manager, this is very frustrating! You create a Contact Center to organize the flow of calls to your Technical Assistance Center, and clients by pass the process by calling your Agents/technicians directly!
Clearly, you can eliminate this by not giving DID numbers to Agents, but we end up doing this to facilitate an orderly problem resolution strategy. You might give a client a "homework" assignment and ask them to call you back. They might object to being put at the back of the queue again, so you give them a DID number that gets them directly back to you. The challenge is, that this call would not be accounted for in your contact center reporting! So how then do you provide this feature and also create a mechanism for enabling your contact center to capture all calls for Agent Performance reporting? One answer is to establish a "service" that has only one Agent in it! Then build out a DNIS/DID route point to IRN relationship that brings that DID number into the call center and routes it to the Agent.
Actually, it is not a bad strategy! The Contact Center can now account for all calls, even the ones that reach your Agent through a DID number and you can apply normal Contact Center routing tools like "overflow", which brings me to my second point! Is it possible to overflow calls to more than one other group? Based on more than one overflow time in queue?
The Contact Center provides a wide variety of methods for handling callers in queue awaiting service. One of the more interesting concepts is the ability to "overflow" a caller from one group to another group based on the amount of time they have been waiting in queue. This contact center parameter is set within the "service" and can be found in within the tab labeled "Overflow".
In figure One below, you can clearly see that we have a number of services defined, including a service named TAC1. Let us assume that this is a technical service group and that TAC1 is comprised of Agents/technicians that include Agent Gandalf, Kipling, Regan and Jack. You can also see that a service has been enabled by the name "Direct Kipling". This service was created to enable callers to Kipling's DID number to be brought into the Contact Center, and routed to Kipling even though they did not enter through the TAC1 service. Hopefully, we can now count the phone calls Agent Kipling is handling that otherwise would not be reportable!
In Figure One we can also see that we have set an "Overflow" counter that, should anyone be in the Kipling Queue for 10 seconds they will overflow to the TAC1 queue. What is interesting is that when you overflow in the ShoreTel Contact Center, you don't leave the queue you are in, you basically add another queue containing agents that have a cumulative effect on the call. Should that "overflow" not result in an available agent and the caller continues to wait for service, you can actually set a second timer that would "overflow" (e.g. expand the number of agents ) to yet another queue.
In Figure two, you can see the original call in the Queue for Kipling. After the pre-configured overflow interval is met, the call is distributed to the "overflow" queue but is also available to the original queue. You can see this in Figure Three, by noting that the call is now in queue in both the Kipling and TAC1 queue. In this way, if an agent becomes available, in either the original queue or the "overflow" queue, the call will be answered. Had we set up a second interval timer in the Service, we could expand the number of Agents to include the additional group specified by that timer. This is one of the more interesting, if not misunderstood capabilities of the ShoreTel "overflow" concept!
In Figure One we can also see that we have set an "Overflow" counter that, should anyone be in the Kipling Queue for 10 seconds they will overflow to the TAC1 queue. What is interesting is that when you overflow in the ShoreTel Contact Center, you don't leave the queue you are in, you basically add another queue containing agents that have a cumulative effect on the call. Should that "overflow" not result in an available agent and the caller continues to wait for service, you can actually set a second timer that would "overflow" (e.g. expand the number of agents ) to yet another queue.
In Figure two, you can see the original call in the Queue for Kipling. After the pre-configured overflow interval is met, the call is distributed to the "overflow" queue but is also available to the original queue. You can see this in Figure Three, by noting that the call is now in queue in both the Kipling and TAC1 queue. In this way, if an agent becomes available, in either the original queue or the "overflow" queue, the call will be answered. Had we set up a second interval timer in the Service, we could expand the number of Agents to include the additional group specified by that timer. This is one of the more interesting, if not misunderstood capabilities of the ShoreTel "overflow" concept!
