Feature Highlight: A Couple of Hidden Features

In my previous feature highlight posts they have often contained screenshots, details of the options, and given a sample a use case or two to help explain what could be accomplished with the features. The two that I’ll talk about today are mostly unseen in terms of the admin screens and really only come into play as a phone rings.  So they are not as obvious as the past ones seen as options on the admin screens but could be just as useful depending on your use case. Continue reading Feature Highlight: A Couple of Hidden Features

Feature Highlight: Conference Rooms

The common conference room, a necessity in today’s world with employees working from home, travelling, and distant customers. No product with PBX functionalities should be without one.

Lets take a look at the options for the conference rooms provided by the Q-Suite.
Q-Suite-Conference-Room-Admin-Page

The options seen are:

  • Name – a Friendly name. If the room is used for a purpose, as our example is, then it’s best to name it after that. This will be the name seen elsewhere within the system.
  • Extension – the extension used for directly dialing it from an extension.
  • PBX Server – This is hidden if your system has a single PBX server. In the case where there is multiple this can be used to distribute load or in the case of a geo-diverse system ensure the conference is on the server closest to the majority of participants to ensure quality and limit bandwidth usage.
  • PIN – a numeric pin to secure the conference with.
  • Disable first member message – If checked this will not playback a message stating the first member is the only one in the conference.
  • Announce user count on join – If checked this will announce to the user how many users are already in the conference they are joining.
  • Play music on hold for single member – If checked this will play music on hold when the conference has a single user. Otherwise the user will only hear silence.
  • Music On Hold Class – what music on hold to play when it’s a single user conference and the above is checked.
  • Suppress enter/leave sound – If checked a user joining or leaving the conference will not trigger the tones to be played to all conference members.
  • Announce names on enter/leave – If checked each user joining will be prompted to record their name before they join. This recording will be used as the join or leave

With all of these options you can configure the conference rooms you needed. However to fully leverage conference rooms, or any single feature, the ability to combine and interlink them to suit your needs is required. Let’s take the example of a daily standup which needs a conference room for a few remote employees. It’s always starts at 8am and lasts about 30 minutes. One way to ensure outside callers do not use it outside of this hours is a pin but you can also mix it with the Routing Rules so the DID or IVR/Auto Attendant option is not configured to point directly to the conference room but to a routing rule first. This routing rule will only route callers there at 8am until 8:30, although I’d recommend 15 mins earlier at least to allow early callers in and maybe a bit longer depending if the meeting has a strict end time or not.  The routing rule can then send them to an auto attendant or elsewhere in the system if it’s outside of the hours — add multiple rules to allow different routing if it’s before to note they are to early, or if they are late to send them to a recording of the conference to hear what they missed.

How to Avoid using a “Courtesy Disconnect” as the IRS Calls it.

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:

[youtube https://www.youtube.com/watch?v=Nn_Zln_4pA8?rel=0]

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Feature Highlight: Auto-Attendants

decision business analyze In the past we have covered the Q-Suite’s Visual Dialplan Builder with its ease of use and capabilities to handle any, from basic to very complex, requirements of an IVR. However, before the Q-Suite had the dialplan builder, we had the auto-attendant features, which allowed for a menu structure to provide the caller options to select and be sent within the system. One can argue the dialplan builder can do everything the auto-attendants can and I would not disagree. However, the auto-attendant configuration screens have been kept in the product due to their ease of use that allows anyone to have a multi-level menu system up and going within minutes. Continue reading Feature Highlight: Auto-Attendants

SIP Phone Configuration the Easy Way

Phones Over SilhouetteFor 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.

Feature Highlight: Asterisk Scripts

Within the Q-Suite we have our dialplan builder with extensive options to route and manipulate calls. The dialplan builder meets the needs of most situations but from time to time you need to get low level and go right into the asterisk dialplan. If it is only a couple of statements the dialplan builder has the Execute command, but when it’s more involved that’s where the Q-Suite’s Asterisk Scripts option comes in. Continue reading Feature Highlight: Asterisk Scripts

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.

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.

Returning for 2015, What was missed during the holidays.

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.