Deflection is up. So is the number of people giving up. Most dashboards cannot tell those two apart, so the target gets hit either way.

This page is about the case and knowledge model: what a case is, how it is categorised, what agents see, what customers can self-serve and how an AI answer stays safe. The call centre page is about the layer on top: telephony, Omni-Channel routing, voice and the contact centre operation itself. Most organisations need both, but they are different projects with different risks, and it is worth knowing which one you are actually buying before anyone quotes for it.

Deflection is the most requested and most gamed metric in service. In most dashboards, a customer who searches, fails to find an answer and gives up is counted as deflected, which is indistinguishable from a customer who found what they needed. That is how deflection rises while satisfaction falls. We report abandonment alongside deflection and look at what people searched for before leaving, because that list is the actual backlog of articles worth writing.

By making it worth trusting, which is an ownership problem rather than a content problem. Articles written once for a launch and never revised go stale, agents get burned answering from them, and after that they answer from memory permanently. Every article needs an owner and a review cycle, and the fastest starting point is usually to delete aggressively: a small base that is right beats a large one that is sometimes right. It also matters more than it used to, because Agentforce reads the same articles.

The knowledge has to be curated and the boundary has to be explicit. An agent grounded on stale or contradictory articles will give a customer a confident wrong answer, which is materially worse than no answer. We scope what it may address, ground it on reviewed content, make it show its sources, and put a named human in front of anything touching refunds, credits, access or contractual language. Then we watch answer quality in production, because that is where drift appears rather than in the demo.

Usually a symptom rather than the disease. Record types tend to multiply because each team wanted its own queue, so the taxonomy ends up describing the org chart instead of the customer problem. The test is whether you can answer "what do customers contact us about" from your own reporting. If you cannot, the model is not doing its job, and consolidating it is normally the highest-value thing on the list.

First-contact resolution, reopen rate, backlog ageing, deflection paired with abandonment, and contact reasons trending over time. That last one is the one people skip and the most useful: if the same reason keeps climbing, the fix usually is not in service at all, it is in the product or the billing process that keeps generating the contact.