JKL-5 Group's VoIP Voyager

So back on the 23rd of April, I got a message via my LinkedIn profile from a contact with a short "can you call me at today please".  I gave him a call and the conversation was "Michel, save my project".  The company had phone number slated to be on the front page of a Montreal daily with 200,000 copy circulation for the following Tuesday.  They had an "Asterisk guy" who had been working on the project for a month and at this time, they still couldn’t resolve a number of issues including IVR greeting message quality.  Ontop of that, the original IVR design had been scrapped because he was having problems delivering the design.

I jumped in.  There was no way I was going to have a high-visibiltiy deadline turn into a disaster for a client.  I talked with the chap they working on the project (we’ll call him Jack) to find out where the roadblocks were. 

The first major problem was IVR menu message quality.  This is a regular "gotcha" on systems without a TDM telephony card for either copper or digital phone lines.  Without a physical TDM device, people forget to configure either Zaptel or DADHI which means there is no high-resolution timing source to synchronize against.  With out that time synchronization, audio playback quality suffers.  Sometimes it suffers a lot.  The answer is to install and run ztdummy or the DADHI equivalent.  The service provider, when Jack contacted their support for how to do that, told him they didn’t support DADHI or Zaptel.  I found that hard to believe, but he insisted that’s what he was told.

I discussed options with the client (we’ll call him Steven) and he decided he would take advantage of JKL-5’s Cloud PBX service and host from there.  Its a full multi-tenant "bare" Asterisk environment;  you get an SSH account and a directory with the extensions.conf and such to work with as you please.  Or, if you don’t want to worry about that stuff, I’ll handle it for you and you just point your ITSP account at it.

Well, it turns out the next major issue was that he didn’t know much about Asterisk.  He was a Linux guy with seven years of experience with RedHat.  He knew Asterisk was a Linux application, so it followed to him he ought to be able to make this fly.  He was using a service provider environment but was completely restricted to using the provided GUI;  he didn’t know how to work in the underlaying Asterisk Dial-plan Language (I call it ADL).

So we took a look at the original IVR design.  It wasn’t simple, but it wasn’t a monster, either.  Jack couldn’t build anything even close to it without a GUI;  and we couldn’t get the dialplan off the original service provider PBX because all they gave you was the GUI.  That meant building the whole thing from scratch, including a "recording booth" application.  The total was 80 lines, done twice;  once for French, once for English.

I recently had a customer approach me with an interesting request. They operate a small customer service queue as part of their Asterisk system. The "agents" are busy with other tasks, and they only have one or two people logged into the queue at any time, which is usually more than enough for day-to-day call volume.

However, every once in a while, they get a high call volume that results in someone getting an upset caller about how long they’ve been waiting. The solution they wanted was to use Growl for Windows (GFW) on the agent group desktops. The idea was to get a notice sent to all potential agents if a call is in the queue for more than one minute, so that additional agents put down their other work and get logged in.

I used the Ruby programming language to create a simple Asterisk Manager Interface (AMI) connector to poll the status of all queues on the PBX. From there, I test if any of the calls has been waiting in queue for more than 60 seconds. If so, I trigger the Ruby-Growl gem and send out a Growl alert. Here is what it looks like:

The app in the background is the control panel for Growl for Windows (GFW). The black bubble in the right upper corner is an example notification. One immediate though that comes to mind as someone who has worked both on the floor and in the PBX room of a major call center, is that this would be a great tool for a larger call center. When a queue gets into trouble, every supervisor has a (GFW) alert pop up on their PC. So even if they’ve got their eyes off the Wall Board, they still get the warning they need to get out and fix the problem before SLA gets murdered.