Chris Crosby

Some of you know my disdain for the use of massive Excel files and what I call the “shotgun blast” approach to reporting. However, since they are a necessary evil in most environments today, I thought I’d point out how you can leverage Cisco Unified Intelligence Suite (CUIS) to automate them. One of the major challenges to creating “one-size-fits-all” excel workbooks is that they are largely a manual process as someone needs to export data from its source and then copy/paste it into excel, format it and then email. By combining CUIS with an Excel macro, we’ve had customers take this manual effort from a couple  hours a day down to a couple of minutes a day. Here’s how it works:

Every report in CUIS has what’s called a permalink, or distinct URL, that can be directly referenced by other applications or your web browser. Each report actually has four different permalink options that can be accessed depending on how you need to query the data. 

The first step is to create your CUIS report and run it for a filtered and relative date range (usually for a specific set of Skill Groups or Call Types for say “This Month”). Save a copy of this report with the filters intact and then follow the steps below. *Tip- I usually save these reports in their own category folder for easier management.

Step One: Locate the HTML Permalink for the report (make sure that it is a filtered report for a relative date range as mentioned above). Copy it to your clipboard. 

Step Two: Open Excel and find the Data>Import from a Web Query Function. Copy the Report Permalink into the New Web Query Address box. Excel will load a preview of the data. Click “Import”.

Step Three: Highlight the cell that you would like to use as the upper-left starting point for the imported data. Hit “OK”.

Step Four: Your CUIS Report data is now imported into Excel to format as you choose.

It’s truly that easy. I recommend creating an Excel macro to handle the above steps for you. Most customers create a “data” tab that the other formatted tabs reference to get their data and calculations. By using a macro you can have Excel automatically query CUIS and format all the tabs as needed. Then you simply save and email the file to whomever needs it.

Please feel free to reference the Cisco Unified Intelligence Suite End User Guide for additional detail. 

Enjoy.

Speech Recognition is about identifying what people are speaking.

Speech Analytics is about figuring out what people are saying.

I’m out at a customer site this week and overheard the following conversation from the Workforce Management Team:

The difference in customer experience between 93% Service Level and 100% Service Level is negligible. But the difference in staffing cost to us is huge.

Now, I’ll spare you my full rant about Service Level (you can find it here) but I think this is indicative of a larger perception and education problem in the call center industry. Simply put: Service Level is NOT a measure of Customer Experience. It’s an opaque metric.

Let’s assume for purposes of this argument that the service level goal is 93% calls answered within 20 seconds. By decreasing the goal from 100% to 93% you’re saying that it’s okay for 7% of your customers to sit in queue for longer than 20 seconds. Logically, and most likely what the Workforce Manager was thinking, the effect on customer experience by being answered in 19 seconds vs. 21 seconds is unnoticeable. However the real impact to Customer Experience between 93% and 100% is actually immeasurable from Service Level alone. You have no way of knowing how many of the calls in queue longer than 20 seconds were answered in 21 seconds or how many were answered in 20 minutes and 21 seconds.

Try explaining to the irate customer that listened to hold music for twenty minutes that his difference in customer experience was “negligible”.

Last fall I participated again in the ICCM Canada Keynote Panel: 60 Ideas in 60 Minutes moderated by Paul Stockford from Saddletree Research. Dave Butler over at NACC recorded the session and has been distributing the ideas presented in his monthly newsletter. I keep promising him that I’ll expand one of mine into an article for him, but in the meantime here is the one he sent out today. Since it’s one of my favorite rants, I thought I would share (pardon my grammar):

Take out the garbage, I am not talking about employees or customers, I am actually talking about reports and data. One of my pet peeves, and I could go on for hours but I will go on for 45 seconds, is when you walk into a call center and you see the reports that supervisors are looking at every day and the first column you see is calls answered,  and this is for an agent. Johnny had 27 calls yesterday and was logged in for 15 hours, blah, blah, bah, blah. Step back and ask yourself what value you are getting out of this information. So take your 30 column report and pare it down to four or five columns that you can actually impact and actually take action on. If you can’t impact whether an agent is logged on for six hours or seven hours, get rid of the column. Just say, you know what, what was their schedule adherence, or what was their hold %? In other words, what are the columns that you can influence? Then write out the business value for each column on the report. Are you going to see service level on there, or outbound calls? Write down why you need to see that so you can articulate that back to the people that are managing to that data every day and why it is important.

I couldn’t have said it better myself

I came across a clever demonstration of Analytics from a Business Intelligence software provider called QlikView, and thought it worth sharing. Note- In an indirect way, Latigent competed with QlikView and I always admired their clever marketing campaigns. In this application of their analytics tool, they dumped radio airplay data from  MediaGuide.com into an OLAP cube and overlayed the QlikView front end (demo found here).

Originally I just wanted to play around with the data, so I filtered based on the greatest band of all time, Van Halen.

Unexpectedly, a couple of things struck me about the results:

1. The top two most played songs both appear on the album 1984, but 1984 is the second most played album: Seems a bit counter intuitive at first, but upon closer inspection we discover that the album Van Halen’s songs may be played fewer times, but there are more of them. The aggregate is greater by more than 300 song plays. There is a lesson to be learned here about product distribution, and a pretty good example of Chris Anderson’s Long Tail theory in action.
2. Why the big disparity between the “David Lee Roth Van Halen” and the “Sammy Hagar Van Halen”? My assumption is that this is most likely because Van Halen is on tour right now with David Lee Roth. No doubt radio stations are heavily promoting this tour by spinning the vintage favorites. My hypothesis though is one that is impossible to prove given the current data set. One would “just need to know” that these guys are on tour to draw that conclusion. Without this information, what conclusions would you draw? Would they be accurate? Is mine accurate?

Now, an interesting exercise would be to take the chart below that displays where these songs are being played and overlay the tour schedule. Also, the data is only available from Feb 24, 2007 to current. What would a wider data set show us? Is the distribution reversed when they’re on tour with Sammy Hagar? What about when they’re not on tour?

This example demonstrates that the unlocked power of analytics is not just about spotting trends that you otherwise would not have, but its often in finding and qualifying external (and sometimes non-structured) data points and quantifying their impact. It also causes you to ask questions and seek answers that you otherwise wouldn’t: What long tails are hiding in your data? How can you leverage them? What external events influence your business? How do you qualify them, and quantify their impact?

What else do you not know you need to know?

Looks like Pentaho closed a $12M Series C round of financing. This is exciting stuff. With the consolidation of large Business Intelligence players its opening the market for the already under served SMB and for Enterprise BI projects looking for a lower cost of ownership.

The only real question is if these guys will join the ranks of Zimbra and become a promising start-up swallowed by a behemoth too soon…

“The process of discovering what you don’t Know you need to Know.”

-Chris Crosby

OK, so the title is a bit overstated, but now that I have your attention:

A couple months ago Google [quietly] released a hosted charting API. Albeit it lacks the sex appeal of their big splash products like GMail or Google Docs, it tapped my imagination.

The basic concept is that your application passes parameters to a URL hosted at Google. It allows you to define things like chart type, size, colors, data values, etc. For example, hitting this URL,

 http://chart.apis.google.com/chart?cht=p3&chd=s:hW&chs=250x100&chl=Hello|World

returns the following image:

Part of the reason this grabbed my attention is that its very similar to Latigent’s BlueVue (now Cisco Unified Intelligence Suite ((CUIS))) “API” for accessing reports & charts from other applications (except you don’t actually pass the data to CUIS, since that’s the real point of having a full blown BI App What I find amusing here is that Google, whether intentionally or not, has basically entered into the 3rd party control business. Very few people ever build their own charting control as its not core to their application, and there are inexpensive alternatives to coding your own. Google just introduced another inexpensive option. Now, I seriously doubt that Google will ever cut into the market share of guys like Dundas, but it could certainly address the needs of some low-level apps.

Expanding on this hosted API/3rd Party Control concept, it’s reasonable to think that a creative developer could duct-tape together the APIs from Google Docs, Google Maps, Google Charts, Google Reader (unsupported “API” here) and Google Search Appliance to come up with a rudimentary and functional presentation layer for a reporting application.

When you pepper in things like databases in the cloud, one begins to ponder if every aspect of an application will eventually be distributed, and perhaps the next software evolution will be nothing but middleware that glues stuff together.