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.