Beyond the scorecard – Why your CX Metrics might be lying to you ..
2Ring Dashboards & Wallboards Blog Cisco
Part 1/3
At 2Ring, we’re proud to collaborate with top industry voices, like this year’s Cisco Insider of the Year 2026 – Marco Hirschmann. Instead of talking about technology or products, we asked him to share his honest perspective on what really happens inside contact centers today. We started with a topic many leaders rely on daily: CX metrics—and why they don’t always tell the full story.
In your experience as a Cisco Insider of the Year, what is the single biggest mistake companies make when they try to improve their customer experience?
Marco: The most common mistake I see is that companies focus too much on improving their satisfaction scores instead of fixing the actual underlying problems. A dip in NPS or CSAT triggers a flurry of initiatives, such as friendlier scripts or faster response times, and when the scores recover, leadership considers the job done. But the real causes of customer frustration remain completely untouched.
What makes this especially dangerous is the false sense of security that metrics create. Research by Esteban found that only 1 in 26 unhappy customers actually complain. The rest leave. Your scores can look perfectly healthy right up until the moment your retention numbers collapse.
Until companies connect their CX data to real business outcomes like retention and lifetime value, they will keep treating the symptom and missing the disease entirely.
Why do you think leadership teams fall into this trap so often?
Marco: There are three main reasons. First, the metric becomes the goal. As the saying goes, when a measurement becomes a target, it stops being a good measure; teams eventually learn how to influence the number rather than the actual experience the number was meant to reflect. Second, CX is often treated as a “silo”—something belonging only to the support or CX department. In reality, customer experience is the result of every decision made across product, operations, sales, and finance. Fixing the front-line interaction without fixing what is happening upstream is like putting a nicer ribbon on a broken package.
Finally, companies listen to what customers say but ignore what they actually do. Surveys capture recent emotions, but behavioral data, repeat contact patterns, and silent churn tell a much more honest story. Instead of asking how to make customers feel better about a bad situation, we should be asking: “Why does this keep happening, and what needs to change so it stops?”.
If you were to redesign a contact center’s KPI dashboard today, what would you include?
For a supervisor in real time, I would include queue depth and wait times by skill group, agent states, current service level against target, and the longest call waiting. That last one is the early warning signal. It tells you someone is about to abandon before it shows up anywhere else. This has to be live, configurable, and available without IT involvement. You need set thresholds so metrics change color or trigger an alert to solutions like Cisco Webex Teams or MS Teams before the problem becomes a problem.
For a manager looking at historical data, I would include First Contact Resolution by contact type, repeat contact rate broken down by reason code, handle time trends over time, and SLA compliance week over week. Luckily, 2Ring Historical Reporting is built on Microsoft Fabric and Power BI, with prebuilt reports that support year on year, month on month, and week on week comparisons, drill-throughs, and dynamic filters. For anyone familiar with Power BI, the learning curve is very short.
One thing I always recommend is bringing in data from outside the contact center. So pull data from CRM systems like ServiceNow and Salesforce into the same dashboard view. That matters because a lot of what drives contact center performance lives in those systems, not in the contact center platform itself.
Other vendors do this too. Genesys Cloud has good native reporting, NICE CXone has its own analytics layer. Five9 has reporting built in. But what most of them share is the same limitation. Real-time and historical live in separate tools, often with separate logins and separate data sources. The gap between what a supervisor sees live and what a manager sees in a historical report is where decisions go wrong. The reason I prefer is the approach that both jobs are handled by one layer, sitting on one data source. Design your dashboard around the role, not the platform. Give supervisors what they need to act right now. Give managers what they need to stop the same problems coming back. And make sure both views are looking at the same data.