Most contact-centre dashboards are full of numbers nobody acts on. Average handle time goes up, someone sends an email about it, and by next quarter it’s back down and nobody’s sure why. Meanwhile the metrics that actually predict whether customers are getting a decent experience sit two tabs deep in a report nobody opens. If you’re running Service Cloud, the platform gives you real levers to move the numbers that matter. Most teams just aren’t pulling them.
Start by throwing out the vanity metrics
Average handle time is the classic offender. It’s easy to measure, it’s on every wallboard, and it tells you almost nothing useful on its own. An agent who spends four extra minutes on a call because they actually solved the problem is doing better work than one who transfers it to make their number look good. I’ve seen contact centres where AHT was treated as a KPI for individual agents, and the predictable result was more transfers, more repeat contacts, and a worse experience dressed up as efficiency.
Occupancy rate has the same problem. High occupancy looks great until you realise it means agents have no time to update knowledge articles, no time for proper wrap-up, and no slack to absorb a spike. None of this means AHT and occupancy are worthless. They’re context metrics. They should never be the metric a team is optimising against.
First contact resolution is where Salesforce earns its keep
FCR is one of the few contact-centre numbers that correlates directly with customer satisfaction, and it’s also one Salesforce can genuinely move, not just report on. The lever isn’t a dashboard. It’s what the agent sees on screen in the first fifteen seconds of a case.
Three things drive FCR up in practice:
- A case layout that surfaces the customer’s history, open orders, and prior contacts without the agent hunting for them across three related lists
- Knowledge articles surfaced contextually against the case record type and subject, not buried in a search box the agent has to remember to use
- Guided flows for the handful of case types that make up most of your volume, so a newer agent follows the same resolution path a five-year veteran would take from memory
Case swarming beats escalation for complex issues
For the cases that genuinely need more than one person, escalation chains are slow. A case gets reassigned, sits in a queue, and the customer explains their problem again. Swarming, where you pull the right specialist into the existing case via Chatter or a quick huddle instead of reassigning ownership, keeps the case moving and keeps FCR intact even on the hard tickets. It’s a process change more than a technical one, but Salesforce needs to support it: visibility into who’s on the case, a place to record what was tried, and a way to close the loop without three separate handoffs.
Backlog and case age tell you more than volume does
Total case volume is mostly a function of how many customers you have and what’s happening in the business that week. It’s not something a Salesforce configuration change is going to move, and treating it as a performance number just creates pressure to close cases fast rather than close them properly.
Case age and backlog, on the other hand, are almost entirely within your control. A case that’s been open for eleven days without an update isn’t a volume problem, it’s a routing or ownership problem, and it’s exactly the kind of thing Omni-Channel and assignment rules exist to prevent. The fix usually isn’t more agents. It’s routing configuration that actually matches how work arrives.
Where routing configuration actually breaks
In most orgs I’ve reviewed, the routing model was built for the org as it existed two or three reorganisations ago. Skills-based routing gets set up once, at launch, and then nobody revisits it as products change and teams split. The result is cases sitting in a queue that technically has capacity, assigned to a skill nobody’s mapped to the agents who actually handle it anymore. Aging case reports catch the symptom. Fixing the routing model catches the cause.
Customer effort is the metric leadership actually cares about, even if they don’t call it that
Customer Effort Score doesn’t get the airtime CSAT does, but it’s usually the better predictor of churn, and it maps cleanly onto things Salesforce controls: how many times a customer has to repeat information, how many channels they have to switch across to get an answer, how many times a case bounces between queues before it’s resolved.
Every one of those is measurable in Salesforce today if you’re capturing channel switches and case reassignment history properly, which most orgs aren’t set up to do out of the box. It takes a bit of configuration: a field that increments on reassignment, a flow that logs channel transitions, a report type built to expose it. It’s not exotic work. It’s just work that usually loses out to whatever the next enhancement ticket is.
What this looks like as an actual build, not a wish list
If you’re trying to move these numbers rather than just report on them, the practical starting point is narrow: pick the two or three case types responsible for most of your volume, and build the layout, knowledge surfacing, and routing rules around those first. Don’t try to fix the whole case model in one release. A typical enterprise org has forty or fifty case record types and record pages, and most of the FCR problem lives in the five or six busiest ones.
Instrument case age and reassignment count before you touch anything, so you’ve got a real baseline instead of a guess. Then make one change at a time. Swap in contextual knowledge for the busiest case type, watch FCR for that type over two or three weeks, then move to routing. Contact-centre leadership teams that see one number actually move because of a specific change trust the next change a lot more than the ones who get handed a redesigned dashboard and told to trust the process.
Leave a Reply