Leveraging APIs provided by an ACD System

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.

Call Center Load Balancing with Kamailio

Call center load balancing with Kamailio

Session Initiation Protocol (SIP) hasn’t officially been crowned king of call center technologies, but it has become ubiquitous. The wide availability of SIP service providers and the way Asterisk is pushing Open Source technologies into the call center has made it undeniable. Especially now with the widespread adoption of Cloud-based call center software and remote agents, SIP is cementing its importance. Continue reading “Call Center Load Balancing with Kamailio”

Automated Queue Callbacks in the Call Center ACD

When making a call into a call center ACD, it’s almost inevitable that you will end up waiting in a queue, while some form of hold music and/or periodic message plays until you eventually get connected to a live agent. With wait times being unpredictable at the best of times, being able to signal to the ACD that ‘Hey I’d actually like you to call me back when an agent is available instead of waiting for who knows how long here in this queue’ is a very solid option for people who do not want to sit around on hold. The ability for a caller to trigger this type of event is a standard, out-of-the-box feature of the Q-Suite. Continue reading “Automated Queue Callbacks in the Call Center ACD”

Efficiently Routing Inbound Callers with Data Sharing

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.