Have you seen the Verizon commercial where the two guys download the 80’s tune “Rock the Casbah”, but instead of singing along to the correct lyrics they misinterpret them into something completely different? Over the course of the commercial they botch the chorus into “lock the cashbox” and “stop the cat box”, which takes a perfectly good rock song and makes it complete gibberish.

The commercial ends with the narrator stating:

“You don’t have to understand your music to understand how to get it all from your PC to your Phone” 

Albeit, I think the commercial is funny and is reminiscent of my grade school days running around the house playing air guitar and trying to belt-out Van Halen tunes (ok, maybe that was last week); it got me thinking about something not so funny: how often I see reports and metrics that end-up getting botched because somebody misinterpreted a few lyrics along the way.

Unfortunately in the contact center, you do have to understand your data to understand how to get it all from it’s source into your reports, dashboards and scorecards.

Here’s an example of what I mean:

Average Talk Time is almost always calculated as (Total Talk Time/Calls Answered). Seems simple enough right? We’ll, not always…

Some of you may have noticed in the Avaya CMS tables there are two fields that represent “total talk time”: ACDTIME and I_ACDTIME

According to the CMS documentation:

ACDTIME = The talk time of all ACDCALLS (calls answered) for an interval.

I_ACDTIME = The length of time during the collection interval that agents were on split/skill ACD calls.

What this means is that ACDTIME represents the total talk time for calls that were physically answered in that interval vs. I_ACDTIME which tallies up all of the time for a half-hour interval that agents were actually talking.

In this example, you would use ACDTIME for an average talk time calculation and I_ACDTIME for an occupancy calculation. Interchanging those two fields incorrectly in a report changes the tune completely…

Another common misinterpretation I see is in the Cisco ICM/IPCC Enterprise world. Cisco makes available both Calls Answered and Calls Handled for reporting purposes. These terms are often interchanged in verbal context, however according to the Cisco database schema:

Calls Answered = Number of calls answered by agents associated with this skill group during the half-hour interval.

Calls Handled = The number of inbound ACD calls answered and wrap-up completed by agents associated with this skill group during the half-hour interval.

So, Calls Answered are pegged to the half hour interval when the call is physically answered, and Calls Handled pegs when the call is actually finished. The difference seems subtle, and over the course of a day the grand total should be the same (except for calls running over midnight).

But what happens if you feed your WFM application Calls Handled instead of Calls Answered? You got it, inaccurate call arrival patterns and forecasts. What would seem like a relatively minor botch will end up having a significant impact downstream on your Service Levels and staffing efficiencies.

I remember as a kid cracking open my first cassette tape that actually had the lyrics printed on the inside of the cover. This was a novel concept as I no longer had to decipher them on my own. This same concept applies to your reporting. Most vendors publish a document that explains, like the examples above, the meaning and usage behind their database elements.

When designing a datamart or report, it’s critical that you reference these documents as your lyrical road map. Also review them whenever you upgrade your ACD or WFM system, as often times fields will change with new product releases.

The best way to avoid these types of pitfalls is to consult an expert or somebody that is familiar with each vendors’ nuances and understands your desired end game requirements. (cough, Latigent)

Before you know it, you’ll be Rockin the Casbah…

-Chris