Your call center is constantly having to deal with new challenges. Your client decides things now have to be done this way or that. Regulations change and now you need to record your data differently. Or not record it at all. A new business opportunity springs out of nowhere, and you have to respond quickly to capitalize. When you’re handling change every day, it’s important to have a flexible call center system. Our Q-Suite software is such a system.
The telephony side
Whether it’s dialing in, dialing out, or transferring, telephony is still the linchpin of the call center. Your callers want to talk to an agent. Your agents need to talk to your leads. You need access to voicemail, queues, and all the other tools. Here’s how you make telephony work for you:
The Dialplan Builder
The dialplan is the basic unit of configuration for systems based on the Asterisk PBX. Even if it’s just a direct connection from a trunk to a phone, you need some logic to tell Asterisk what to do. On basic systems you have to modify text files on a linux system, reload, and hope for the best. A visual dialplan builder frees you from the tedium and guesswork. You can script complex IVRs, or even just build a chunk of logic that will be included somewhere else. The interface gives you a drag-and-drop way to build and visualize your call flow. Once you have your dialplan, your software should include multiple ways to get to it, including from another dialplan.
Once you have your hands on a dialplan builder, you may need to have your dialplan make decisions based on information that’s either already stored in a database somewhere, or generated on the fly. The dialplan builder that comes with Q-Suite gives you four ways to get this information easily:
- A local database lookup. Q-Suite provides two ways to pull data from its database:
- A lead lookup. Leads stored on the system can be searched, and if a match is found, information from that lead can be pulled into the dialplan, or modified if needed.
- A simple lookup table. This is different from a lead lookup, in that you can set some variables based on a single piece of information. The logic could be something like the phone number for a regional office, where you provide the postal code and it returns the phone number, a code that should be stored with the lead, and a reference number. These can be set up very easily in the admin interface by entering fields manually beforehand, or uploading an excel file with the right fields set.
- An external web service. A web service can be called with parameters you provide in the dialplan. These could be based on things like caller ID, the destination that was dialed, or information provided by the caller or from a previous lookup (or web service). You can chain a bunch of these if you need to, but it’s usually not necessary. It’s pretty simple to build a web service that handles all the logic needed on its side if multiple things need to be processed, then return a single result.
- A remote database request. Sometimes the information you need is in an external database. While a web service gives you more flexibility, you don’t always get to choose what you have to connect to. MSSQL and MySQL are common options. You set the parameters for your lookup, and the dialplan component makes the request and returns the result.
- Asking the caller for input. Sometimes you just have to ask the client for information. Whether it’s as simple as choosing an option, or entering a 16 digit account code (which might be a bit much, by the way), sometimes you just have to get the information from the source. It’s a bit old school, but still perfectly valid. The prompts played are all configurable in the Q-Suite admin interface.
Once you have the information you need, you can use branches, jumps and other means to get from one point to another inside the dialplan as needed. Data you’ve collected can be stored in the database and passed to the agent interface if needed.
One option that is hardly ever used, but is available on Asterisk systems, is calling an AGI (Asterisk Gateway Interface). The interface itself can be a bit tricky, but if you absolutely, positively have to program some logic on the system itself, it’s available. You simply write a program that can be executed on the system which can access dialplan variables (including stuff you’ve accessed through the above methods), do some processing, and return a result. The call can be manipulated directly, or more typically you return a result which can be used in a later branch.
The PBX side
Other options for updating the way your system works are provided under the PBX functionality. Service codes can be defined by adding a service through the admin interface. This does require a knowledge of Asterisk dialplan writing, but the code is placed in an appropriate spot. Several services, such as Voicemail access, are already pre-built, and only need to be assigned a star code, eg *99.
Auto attendants work much like dialplans, with configurable prompts, menu options, and the ability to go to other auto attendants (or even dialplans configured by the dialplan builder). With extension Find-Me-Follow-Me, voicemail and other functionality, the PBX can be as sophisticated an entry point for calls as IVR system.
The Agent Interface
Often, it’s not the telephony side that needs to change, but the agent interface that needs an update. Luckily, you don’t have to settle for a locked-in version of the screen. An easy to use client interaction script builder gives you the ability to present information and handle the call flow from the agent side in a natural and easy to read manner. By hiding sections until the right conditions are met, or displaying certain components, you can make sure the agent can only enter data or read script passages that make sense in context. This can be further modified in four ways:
- Data from web services. Your web service can accept details pushed out from the agent screen, and respond appropriately. This allows custom processing to occur in the same way a web service does in the dialplan builder. Recently, Q-Suite has added the ability to process a return in XML so the agent can be presented with multiple results, and populate the script with only the values that match. So if the postal code is sent to the web service, it can reply back with the three offices that serve that region, and have the agent choose the correct one based on additional information from the caller.
- Modifying HTML and CSS. You can add or modify the themes directly from the admin interface. No fussing with code directly on the system. The agent script builder also allows HTML to be written directly into the fields. The use of TinyMCE in the script builder itself allows you to do so in a much friendlier way.
- Adding a Javascript component. The script builder allows the addition of Javascript to the agent script. This allows your call center to add functionality to the screen without having to modify the source files on the back end. Javascript is widely used in web development, so it’s a great option. You can make powerful changes with little effort this way.
- Using an external page. You can open an external page, with a URL that can be populated with values unique to the call. This can give you the call control ability of the agent screen while allowing the agent to use a custom web application. When the agent is required to enter information into a third-party website, or use an external CRM, this is a better choice than custom development to replicate that work.
Of course, if you really want to customize the whole experience while using the power of Q-Suite, you can use the call center software APIs provided alongside with Q-Suite.
These allow you to develop your own application, but still leverage the power of Q-Suite. You can create your own interface, extend someone else’s, and generate your own reporting this way. Even if you plan on using the provided interface for 90% of your functionality, being able to completely control that remaining 10% can be invaluable.