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.
Data Collection within an IVR is a feature we use within our Q-Suite, an Asterisk ACD System, to look up the customer via their caller id and associate it with a record already in the system.
I only briefly talked on this feature set and what it accomplishes for us, lets look at it in a bit more detail and a few other variations possible. In our scenario the main goal is to have the agent bring up the proper record quickly with the database lookup done by the IVR. The DB lookup is done in the IVR then the script page on the agent’s screen uses the information and seed a search to an external application.
- Direct DB lookup. A lookup to associate a caller with a customer list within the system. This would be a list of existing customer loaded into the system’s own database with the key usually being the caller id, but the key to match the caller to an existing customer could be any field if the IVR is configured to prompt for it.
- External API/web service. A lookup on an external system and associate the returned data with the caller. This can then be used by the scripts to provide the agent more data. Or to pass to the an external app within the script to save the agent from searching again. Depending on the case it may be best to simply pre-populate the search fields and have the agent submit after confirming the information or adding more once talking with the caller.
Using the IVR and collecting data is great as it tends to free the agent to be handling other calls while a caller navigates the IVR but can be abused and cause negative side effects. For example it can be annoying to the caller if too much data is collected which is not easier entered with a phone in the IVR. The goal should be to collect a small amount of relevant data and get caller to where they need to be. If passing to queue and ultimately an agent, make sure data collected that is required for the agent to know is passed along or accessible. I am sure we have all called systems and entered data only to be asked for it again from the agent. As I noted a confirmation of it might be required, but if the caller just entered their 16 digit card number perhaps just confirm the last 4 digits, name, etc. and assume the rest of the data is accurate when possible.
This post was delayed as I found another blog posted a similar topic just before my original planned posted date. So also take a look at the two-part article over at indosoftnotes.blogspot.com on IVR Data Collection.