Contact Center Software for Asterisk Telephony

Before it became synonymous with ‘Google it’, searching was how we all went about our business on our web browsers when a particular item needed some clarification or a certain question needed some answering. With regards to the Q-Suite, searching can be custom tailored to meet specific needs, as far as how data is entered in order to query the database with efficiency. Search templates hold these structures so let us take a bit of a look as to how and why you may want to use them.

The Q-Suite has a standard default search template that contains a basic set of fields that can be effective at retrieving customer lead records: Phone Number, First Name, Last Name, and Disposition. While this may be entirely sufficient for some users, it may not provide enough information, both for entering and returning data. Something of note may be that the results of these searches will only contain the data corresponding to the fields that are present in the template. So as an example, the default template would return four columns of data for each successful result, and those columns map in a 1:1 ratio to the fields in the template. Many users, however, find themselves in the situation where they need more types of search parameters available in order to intelligently construct their data queries. Using a custom search template, any available lead fields as well as any custom fields in the Q-Suite can be selected as a search parameter. User generated fields, like Account ID or Customer Code for example, which can be unique for every record, can be used to pinpoint your desired results.

Another important distinction a template creator can choose is whether or not the search template will be available for agents to use via the agent portal. With this in mind, templates can be created with either an administrator’s or agent’s point of view. There may be some areas of interest regarding a customer record that are irrelevant to agents, and therefore it’s unnecessary to have those types of fields in agent accessible searches, but an administrator may be reliant on those fields, so taking the steps to have to correct data available to the proper user is paramount.

Searching doesn’t have to be complicated but it also doesn’t have to be unintuitive. Using specific templates to increase the speed and efficiency of your searches can greatly improve the way data is accessed, which can help streamline many of the processes in the day to day operation of a call center.

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.

Using Asterisk Scripts requires knowledge of asterisk and how the Q-Suite interacts with it. Due to this, often the scripts are implemented as custom work completely or partially depending on the client’s knowledge of asterisk and the complexity of the requirements.

These scripts are often used with star codes, and we actually use them to provide common functions in the product by including a few as system wide defaults any tenant can use. However, in addition to using star codes to access the Asterisk Scripts, they can be entered from many points of the system including DIDs, Auto-Attendants, the Dialplan Builder, etc.

Let’s take a look at a couple examples. The first is one that is included by default for checking the voicemail of the current extension. It’s all straight asterisk dialplan statements with the only Q-Suite specifics being the pbx_exten_num and acc variables which are set on each extension as it dials.

;Check Voicemail:
exten => s,1,ExecIf($[“${pbx_exten_num}” == “”],Hangup)
exten => s,n,Voicemailmain(${pbx_exten_num}@ihostpbx-account-${acc}-voicemail,s)
exten => s,n,Hangup

The second and more a bit more complex example is to record an audiofile and insert it into the db for use elsewhere within the system. Just note this was built previously for a client on our 5.6 product line on asterisk 1.4, so it would not directly work in the current line without a few adjustments.

; Record AudioFile:
exten => s,1,Answer()
exten => s,n,Wait(1)
exten => s,n(rerecord),Playback(dictate/record&vm-message&and-prs-pound-whn-finished)
exten => s,n,Wait(1)
exten => s,n,Record(indo-tmp-rec-${pbx_exten_num}.wav)
exten => s,n,Wait(1)
exten => s,n(replay),Background(indo-tmp-rec-${pbx_exten_num})
exten => s,n,Background(silence/1&vm-review)
exten => s,n,WaitExten(10)
exten => s,n,Goto(replay)

; accept.
exten => 1,1,AGI(load_audiofile.agi|${acc}|indo-tmp-rec-${pbx_exten_num}.wav)
exten => 1,n,Playback(vm-msgsaved)
exten => 1,n,SayDigits(${LOADED_AUDIOFILE_ID})
exten => 1,n,Wait(2)
exten => 1,n,Hangup

; replay
exten => 2,1,Goto(s,replay)

; rerecord
exten => 3,1,Goto(s,rerecord)

; invalid
exten => i,1,Goto(s,replay)

In this example it prompts the caller to record a message, plays it back to review it, then give the option to save, review again, or re-record. Similar to the first example we use some Q-Suite specific variables and also an AGI to save the audiofile into the database. Due to the AGI this is not something a client would solely do, so it would either all be custom work or just the AGI would be depending on the needs and experience of the client.

As you can see the Asterisk Scripts feature of the Q-Suite gives powerful direct access to asterisk’s dialplan. Leveraging these along side the numerous other features within Q-Suite allows for solutions to the variety of use cases brought to us by clients across the globe.

Are you losing customers to a bad dialplan? Trouble navigating an IVR is one of the most common customer service complaints people have. Why irritate your clients with a bad menu system? The truth is, it’s not always easy to build an IVR that is simple enough for most clients, yet sophisticated enough to route calls to the right party. Your call center’s ACD system may depend on it, however.

This past weekend I received a call which disconnected the moment I answered it. Wanting to make sure there hadn’t been a problem with the call itself or my phone, I called the number back. I had recognized the caller ID, and so was braced for a difficult IVR experience. I decided to try for a few minutes, then send an email out to everyone I knew at that company to see if there was an issue that needed attention. Much to my pleasant surprise, the menu system was clear and concise, and without knowing the identity of the caller, I was still connected to the correct party after pressing only two keys.

Things that can help you design a good IVR are:

1. Quality sound files. It’s important to make sure you call in and listen to the audio after you have uploaded the files to the system. All too often an audio file that sounded good in your recording software sounds quiet or muddy when Asterisk is forced to transcode and you have no control over volume.
2. Make the menu simple at each step. If your descriptions are long or there are too many options, people will get confused.
3. Make sure that it’s easy to reach a live person. People who get frustrated in the attempt to reach a live person are not going to be terribly happy once they finally get through.
4. Test, test, test. Verify your audio files, test that the options go where they’re supposed to, and make sure time of day elements are working. It’s unnecessarily cruel to let someone wait in a queue for an hour after your last agent has gone home for the day. It also lets you find the issues that may not be apparent in the design. Having your music on hold interrupted every 15 seconds with a customer service message may seem like a good idea, but if you’re waiting ten minutes to reach an agent, it might be its own form of torture for your clients.

Q-Suite 5.7 introduced the Visual IVR builder, which allows you to design your IVR in a drag-and-drop manner. The ability to revision the dialplan, upload audio files independently of the dialplan, and multiple options to reach your dialplan allow for simple version testing when designing and updating your IVR. Our intent is to make it as easy as possible for you to improve your client experience every time they reach out to you.

In the Q-Suite, we use PBX Routing Rules as the proper name for Time of Day scheduling. This feature is the backbone of the CTI Campaign Schedules, but is still quite useful for people who may not want to venture into the Contact Center portion of the product and are perfectly fine with sticking to the PBX aspect. Let’s have a look at a simple example showing how to use this feature.

Here’s a brief description of the available options:

• Name – This is just the name of your routing rule. Use something useful and descriptive for it so that it’s easily distinguishable.
• Default Action – Here you will choose the default destination of the routing rule. In case none of the Scheduling Options match, this gives the call a controlled destination. In this specific rule, I am designating extension 9000 as a Direct to Voicemail end point.
• Schedule Type – Options are Weekday Range and Specific Date.
• Date / Range – You can choose any type of day combination to suit your needs here.
• Start Time / End Time – Set the boundaries of your option.
• Linked To – This will be the desired end point for this particular option. You can select from the following types: Auto-Attendants, Conference Rooms, Call Queues, Ring Groups, Extensions, Asterisk Scripts, Routing Rules, Dialplans, DIDs, and Direct to Voicemail. In short, almost all of the PBX configurable options can be destinations, as well as the Contact Center Dialplans.

Here’s what our example will do:

• If it’s Monday though Friday, between the hours of 10:00 and 17:00, route to the Indosoft Main IVR; otherwise go to the 9000 Direct to Voicemail extension.

Like many features in the Q-Suite, you can configure routing rules to be as simple or as complicated as you need them to be.

As the title says it’s PBX DIDs in this highlight and sounds simple enough as you have a DID and you point it at an extension, IVR, or auto-attendant correct? Yes, but they can be used for much more.

Within the Q-Suite we have many options to link a DID:

As seen we have the DID number followed by features available.  These include the ability to record all incoming calls, ignore any callers matching a list of given Caller IDs to filter out unwanted callers, and the last is to email as calls arrive at the DID.

With a bit more detail the destinations are:

• Agent - directly to an agent’s personal queue.  This is useful if the agent does not have a personal extension but still needs to take direct calls.
• Auto-Attendant - sends the caller to an auto attendant menu.
• Asterisk Script - a custom asterisk dialplan, which can be used for ultimate lowlevel control over the call.  This is usually reserved for some custom work due to the knowledge needed to setup properly.
• Conference Room - directly into a conference room.
• Dialplan - into our dialplan which can do anything a dialplan can do and setup with ease with our dialplan builder.
• Direct to Voicemail - goes directly into a voicemail box of any PBX user’s extension skipping ringing the devices on the extension.
• Extension - to a PBX user’s extension on the system. For a 1:1 DID to Extension mapping.
• Ring Group - directly to a ring group of PBX extensions.
• Routing Rule - to a routing rule which can route on time of day or a specific day.  This is often used to automatically open or send callers to the normal working hours IVR/auto-attendant then afterhours a closed/list
• Trunk / Number - dial out over another Trunk to a specific number.  Often used to forward to another system and can be useful when moving from an old system in stages when the incoming trunks/DIDs are all grouped together from a SIP provider, PRI, etc.

With the Q-Suite all the common options for destinations are provided given as seen. If a DID is to reach something not listed above then a Dialplan can direct it anywhere using the dialplan builder interface. One example would be the ability to listen or coach agents remotely. Instead of having a hidden or silent option in a menu, one could configure the dialplan to limit the functionality to specific Caller IDs or ask for a PIN prior to allowing access.

I don’t think they were this careful

We once received a call from a client who was down. It turned out that he kept his server sitting open so that the cleaning staff could vacuum it out periodically. One overzealous cleaner (and it doesn’t take much here to count as overzealous) accidentally knocked a Pika card too hard, knocking loose several of the DSP modules. Those were the days when we were a little cautious about exposing too much functionality and monitoring to clients.

Fast forward a decade. Tightening of regulations along with an increasingly competitive environment have eliminated many of the fly-by-night call centers and the inexperienced management running them. These days, small doesn’t mean unprofessional or inexperienced personnel. Our design philosophy for the Q-Suite has changed to match. Building more functionality into the administrative interface and adding monitoring can save a lot of time in tech support calls and improve confidence in the system. It also gives call center staff the ability to fully utilize the features in the Q-Suite or adapt to changing conditions without having to arrange for a configuration change.

Early on, this effort was focused on minimizing support time. Routine tasks we were expected to perform time and time again were good targets for a screen. The earliest example might be the “Logout Agents” screen. A common issue was an agent logging in twice from different locations, or two agents accidentally trying to use the same phone. A screen showing all the active sessions, all the active “seats” (corresponding 1-1 with a phone at the time), and one button for “Logout Agent” and one for “Hangup Phone”. Today, clients can view live calls going through each Asterisk server, monitor the database for large or stalled queries, update agent assignments on the fly, even examine all the data items available to the agent screen in their current call, just to give a few examples. This saves everyone time and money. Watching data and calls as they flow through the system allow dialplan builders to test and spot gaps in call flow logic and data gathering. Seeing that a data item is not being collected allows the client to resolve their own issue which may initially appear as a reporting issue. When everything is going well, this functionality is not normally required, but when it’s wanted it’s important to have.

Open Data and it’s uses have been making the news lately. Governments are liberating data that tax-payers paid to collect. This trend is creating many opportunities for new business ideas as well as enhancing existing ones.

Indosoft’s Q-Suite has the ability to plug into many of these data sources. While some sources are provided as flat files, others have an API that can be queried directly. One example is real-time address validation. This can be done before a delivery or service vehicle is assigned to be dispatched. Municipal data sources are usually updated much faster than a commercial data provider.

While Q-Suite has the ability to consume open data, it can also be used to provide it. Your organization could provide live queue wait times, up-to-date employee directories and much more.

Our design allows you to integrate with an almost limitless amount of external sources. Your tax dollars are paying to collect the data, so why not make use of it?

Failure is not an option. Failures are disruptive, and a disrupted call center floor is an expensive headache to manage. The promise of Asterisk, which was replacing monolithic telephony hardware installations with multiple commodity servers running call center software, was a lowering of the total cost of ownership. The promise has been fulfilled, but enterprise contact center installations have to be mindful of the possibility of hardware or software disruptions. This is why we introduced the HAASIPP, to allow call survival, and the Overseer to manage processes and allocate them between servers in a high availability solution.

The Overseer and its watchdog are tasked with monitoring processes, and moving delivery of services from an active to a standby process if a disruption is detected. Problems with service can take many forms:

• A networking issue may make one or more servers unreachable
• Asterisk has become overloaded or unresponsive
• Web server thread usage exceeds a set threshold
• A monitored process has died
• A monitored process has exceeded a set threshold for memory usage
• A disk becomes full
• Database replication falls behind or breaks
• and so on…

What services are expected to run and parameters for each are configurable, depending on the local situation. A balance must be struck between allowing a temporary situation to resolve itself (such as a large number of threads being temporarily created, or delays in processing new calls) and failing a service, moving it to another server. However, the Overseer must be able to act decisively in the case of a failure, especially when call survival is configured. Settings can be configured for individual services as well as the system as a whole; a server that is struggling under load is probably a bad candidate for acting as the primary for a service.

The Overseer process itself has to be monitored in some manner. A hierarchy of servers is configured on install, and in the case of an inability to contact the main overseer, an individual server’s overseer process will attempt to communicate with each server down the list until it believes itself to be the master. This gives a predefined order that all servers can agree on, so if more than one server is down and that includes the master Overseer, a new master can be established automatically. As long as a set of servers that comprise the full set of required services can communicate with each other, the Overseer can bring up the system and make it active. In cases where the Overseer is managing a system configured for high availability of services, thought must be put into the infrastructure. A fully redundant install of the Q-Suite is of little value if all the servers are plugged into the same switch and the switch experiences a fault. However, with a little preparation, the Q-Suite with redundant hardware and the Overseer can be quite resistant to faults.

Of course, monitoring is essential. A status board reports the current status of services from the Overseer’s perspective. Clicking any service can bring up a more detailed list of components that are monitored for that service, and a testing history can be used to determine when any problems may have arisen. Colour-coding makes it instantly obvious if there is an issue. Green indicates things are satisfactory. Orange lets you know there is a warning, usually indicating some parameter exceeds the usual bounds. Red lets you know there is something wrong.

A lot of work has gone into the Overseer to make sure it’s testing the things that matter, and only failing over if something is seriously wrong. It’s a cornerstone of our high availability strategy.

Let’s look at the following scenario that may come into play in a call center:

• You want to track data about how the customers feel they were handled by your agents
• Customers call into your center in order to talk to a CSR
• At the conclusion of the call, you want the customer to be transferred to a post-call survey where they will answer questions regarding their experience

I can see two glaring issues here:

1. The agent forgets to transfer the customer
2. The agent has just dealt with an irate customer, fears that the customer will leave horrible feedback, and simply does not perform the transfer

These two outcomes can be completely avoided by using the Q-Suite’s feature to assign a transfer DID to custom dispositions. The DID, which will typically be an internal number, will already be configured to route to a dialplan that houses the post-call survey. With this level of automation, poor or negligent agent behavior can be bypassed with 100% certainty. The center administrator simply creates custom dispositions and sets the transfer DID as desired. These dispositions are then assigned to the relevant campaigns. As the transfer is blind, the operation is transparent to the agent and behaves the same way as any other standard disposition.

Capturing post-call data regarding the interactions between your agents and customers can be invaluable to your operation. The data can serve as a reference as to how your staff is performing, can be leveraged to develop training and QA, and can shed some insight as to how pleased your customers are after talking to agents.

When managing PBX extensions and their users the requirement to limit what can be called is often needed. This can be done heavy handed at the trunk level but then no calls can dial out to the blocked numbers.

Using the Q-Suite feature Restricted Numbers is a more refined solution to the issue. It can be setup to restrict certain PBX extensions from dialing a set of numbers while allowing others. For example this is useful if only a group of users are allowed and expected to make international calls while another group are to be restricted.

Configuring this is easily done by setting up the “Restricted Number” list. On this list you can setup exact numbers, block by prefix, postfix, or using a pattern from anywhere in the dialed number. There is also an option when a filtered number if attempted to dialed to redirect the user to an extension or DID. This allows sending the user to almost anywhere in the dialplan, perhaps to play a message informing them of why the dialing is restricted.

As seen in the screen capture we have a few simple rules configured. The first is to block any number starting with ‘011’ to catch international numbers as the example earlier mentioned. In this case the user is not redirected and the system rejects their dial attempt will not complete their call.

Each extension can have a dialing permission configured by the administrator. The options here are:

• Allow Calling All Numbers - completely unrestricted.
• Disallow Calling Restricted Numbers - any dial made from this extension is filtered again the restricted number filters.
• Allow Internal and Emergency Calls Only – restricts it even further to only allowing internal extensions be to reached or emergency services.

With all these options it easily allows different groups of PBX Extensions to be configured with the dialing restrictions needed to suit a wide range of requirements of a PBX solution. The Q-Suite has a full featured Multi-Tenant PBX in addition to the extensive feature set for Contact Centers.