Tomorrow is the IRS tax filing deadline if you live in the US. If you call for help and their system is overloaded it will hang up on you, which they call a ‘courtesy disconnect’. Which brings me to back to a recurring topic on this blog and others which boil down to mistakes in IVR design.
If you haven’t seen the clip of This Week Tonight about the IRS take a look. The ‘courtesy disconnect’ segment starts around 2:23. But read on below for some suggestions for dealing with an overloaded system. Due to language this is clip is not safe for work:
So it’s understandable that near the tax filing deadline the IRS would have a higher than normal call volume. Something that can happen to any company which should be planned for and tested prior. Not being in the US I have never called the IRS and have no first hand experience but after searches and reading a number of articles it sounds like they are hanging up after a person has been waiting for a time. Of course the IRS can get away with this as their customers can not leave and go elsewhere. But if they wanted to improve customer relations they could implement this differently. I would suggest any of the following to improve similar situations:
- Max Caller Limit on Queues. This ensures the limiting is done prior to the caller waiting and any caller over the limit will hear a message to call back at a later time. Of course one has to be careful here if the queue times out and sends to another we could end up in a situation like the IRS is doing and hangup up after a caller already waited. So it should only be on the first queues a caller can enter.
- Enable Queue Callback Feature. This is where the caller in the queue is offered to leave a callback number and is later called back, usually keeping their position in the queue. Be sure to combine this with option 1 as having thousands of callers leave a callback number but never get a call is just as bad as a courtesy hangup.
- Common Questions and Answers. Often callers have the same question and if the IVR can provide these answers it can save the queue and staff answering those calls. This is especially useful in cases for general status which could be due to a temporary outage of a service for example. These can and will cause an influx of callers all asking the same question until that’s resolved.
- Higher Staffing Levels. Not easy as it often requires hiring new people and that takes time. However in this case it’s known this time of year will have increased call volume so having more staff to answer the calls is the simple, although not cheap, answer to improve the situation. Just ensure your system is capable of scaling to the needs and the hardware can power it. Alternatively go for a hosted system to avoid the hardware costs for a yearly surge which I am sure drops significantly the rest of the year in cases like this.
For large installations configuring all the VoIP phones can be a pain. Perhaps you have polycom SIP phones which I have seen in the past delay starting the web configuration interface until after the phone is ready to handle calls. This is great when the phone is in use as the user can use the phone sooner while not waiting on the processes providing the configuration interface, however when configuring a large number of phones it causes delays if manually configuring each phone. Even when the config interface comes up fast it’s still a labour intensive task to go through each phone manually configuring them. During this manual process mistakes can and will, especially given a large enough set of phone be made, some of which may not be initially obvious. For example, if the dtmf mode of the 47th phone configured today left at the default of RFC2833 but the system is using SIP INFO? That phone gets used for a while but then the user goes to use an IVR and has to file a trouble ticket to get it resolved after finding out dtmf isn’t functioning as expected.
The solution to this manual headache and time drain? Provisioning. This is where the phone system will have the configuration for each phone and the phones download their configuration so they are synced with the phone system options.
Provisioning is usually accomplished via a tftp where the phones configuration files reside. At boot the phone gets an IP via the local dhcp server and the dhcp response has an extra configuration setting, usually Option 66, to inform the phone where the tftp server is. From the tftp the phone will generally request a general model configuration file, this can handle firmware upgrades and common settings specific to a model or make of phones. After that file a request is usually made for a file with the MAC ID to differentiate the phones. This MAC ID file is specific to that individual phone and will contain the details of the SIP connections, extensions, and anything else just for that phone.
The Q-Suite supports provisioning a number of SIP phones from various manufactures. With easy support via templating to extend to new models as needed. The administrator only needs to collect and input the MAC ID’s and choose the proper template when configuring the extensions and the generation of the config files will be done for them. With DHCP Option 66 is set properly boot up the phones and they’ll be functional and making calls.
In a number of previous posts I have mentioned APIs in passing. Sometimes it’s the system calling an API of an external application while other cases are using the APIs provided by the ACD System. While most systems will offer some level of API integration it can vary greatly, which is why it’s important to know what you are looking for in terms of APIs. Lets look at the possibilities with the various levels of provided APIs that could be leveraged in an ACD System.
- Data Management/Manipulation — this is often the first level of APIs a system will provide as it’s the most common requested. These APIs would provide ways of loading data into the system like contacts or user accounts. It often helps with data synchronization between systems, take the user account for example perhaps they are all managed with one piece of software and re-creating them in the ACD System is a duplication of work and manually doing so can cause inconsistencies. Using an API allows for this to be automated and if any new or user changes are done in the main user system they will be pushed out automatically.
- System Control — this is typically the second level of APIs a system will provide as it is a bit lower and allows external control of various components. This type of API can provide a wide variety of options which could be pushing the changed data to be active/live on the system, logging out users, changing queue properties, etc. Or even as low-level as restarting a service, moving a service from one server to another for maintenance, etc.
- Developing a Custom UI — this requires a full suite of APIs that allow full control and functions that the ACD System’s UI can do. Often a business will require an ACD System to integrate tightly with a current application and this can often be the best solution.
The Q-Suite has an extensive list of APIs which allow all the levels mentioned above and have a number of customers who have developed a custom agent interface. While most if not all functionality provided by the APIs is available from the admin or agent screens it’s often more productive to integrate these calls with other systems to improve the desired workflows.
Companies which operate all their systems independent and keep the data in silos are often overlooking important efficiency which comes with data sharing between these systems. This can certainly true for Inbound ACD systems not linked to external applications which make the system less dynamic and user-friendly.
There are a few common ways to do this with a modern ACD Enterprise level solutions.
Loading the Contact List into the ACD System’s internal database. This allows a quick lookup to be done via the dialplan components to the internal database which can contain the information the agent needs right away. Loading can be done periodically uploading the list by file to the admin interface or by integrating with an external system via API. Using the API minimizes delays by allowing almost instantaneous sync by an automated process. Of course if the list is mostly static perhaps manually uploading is acceptable.
Remote API Call. Would be a remote call to another system’s API to preload some data at the time of the call. This can be done at various times with one common one being within the dialplan when the Remote Call is done to preload some data and/or route the call. This can also be done later while the call is on the Agent screen but at this time it’s already to late to route the caller to another queue automatically but still a valid case and is often paired with the dialplan lookup to load more details the agent needs.
Just in Time collected data from forms online. This allows skipping a portion of the IVR, redirect to special queues with skilled agents ready to talk, or just pre-populated on the agent’s script to save time on the call. Allowing the agent to get back to taking another call sooner and caller appreciates the shorter time accomplishing what they called for. The form could for be sales or support, for example, with the main DID can being common for those who did and did not fill out the form but anyone who has is directed to bypass a portion of the IVR or a special queue. The system handling the form can either push the data to the ACD System’s database or be available via a Remote Call as mentioned above.
These are just a few ways to bridge systems and make a companies data more accessible. Most companies will not get or want to go as far as true Open Data but freeing the flow within is hardly ever negative.
As the new year rolls in and we start to get back into the normal work day lets review a few posts that might have been missed.
Stephen over on indosftnotes.blogpost.ca continues with Part 3 of How to Populate Client Info which is timely and I can envision uses with open data that James talked on blog.indosoft.com.
Planning an upgrade or new system in 2015? These posts covering pros and cons of On-Premise or Cloud Solutions for your Contact Center may help with your decision. Both options have their benefits even for those who want to get under the hood although going with a shared cloud solution will limit some options for how deep one can dig.
We’ll be back to the normal weekly posts starting next week.