The Business Case for Deflection
Northwind Retail's service desk takes 11,400 contacts a month from 19,000 store and head-office staff. Of these, 1,800 are password and MFA resets averaging 7.5 minutes, 2,400 are 'how do I' questions about the HR and stock systems, and the rest are incidents and other requests. The ITSM tool's self-service portal has been licensed for three years; 18% of users logged in during the last 90 days and 4% of contacts originate there. A chatbot pilot on the intranet handled 31% of chat sessions without handover, and the vendor reports 41% deflection. Follow-up sampling found that 22% of chatbot 'resolved' sessions produced a phone contact within 48 hours on the same topic. The knowledge base holds 640 articles; 58% have not been edited in two years, and an internal audit found 12% describe an interface that has since changed. Two proposals compete for a single budget line: a £180,000 AI virtual agent, or £40,000 to integrate self-service password reset and MFA re-enrolment with the identity platform. The desk is losing four agents a month and queue waiting time is up 40% year on year.
1. Which proposal would you fund, in what order, and why?
Read the worked answer
Sequence by volume × handle time × determinism × risk, not by vendor promise.
Password and MFA: 1,800 contacts at 7.5 minutes is roughly 225 hours a month of predictable, rule-based work. It is the largest single addressable block, it can be automated almost entirely by integrating self-service reset and MFA re-enrolment with the identity platform, and its failure modes are recoverable. £40,000 for that is the strongest return on the table, and it removes a category that is unattractive to work - relevant when four agents a month are leaving.
The 'how do I' block is larger at 2,400 contacts but far less deterministic, and the knowledge base is not fit to automate: 12% of articles are known to be wrong. Automating on top of that scales inaccuracy. The 22% 48-hour recontact rate already shows the pilot is displacing contacts rather than removing them; the 41% figure counts sessions, not needs resolved.
So the order is: identity self-service first; then knowledge remediation with named article owners; then a narrow virtual agent covering the top 20 intents, with a handover design that logs failure reasons and a success measure that includes a recontact window.
Is the £180,000 wrong? Not necessarily - it is mis-sequenced. Re-evaluate it once the top intents have trustworthy articles behind them and the identity category no longer distorts the baseline.
2. How should deflection be measured so that the business is not misled by the current pilot reporting?
Read the worked answer
Deflection must mean 'the need was met without a human contact', not 'the session closed'.
Build the measure in layers:
- Containment (leading): session ended without handover, by channel and by intent.
- Verified containment: no contact by the same user on the same topic within a defined window. Seven days is defensible for access issues; the pilot's 48-hour figure shows the current window is too short.
- Cross-channel detection: match user and topic against phone, chat and ticket records, otherwise you measure the chatbot's queue rather than the desk's.
- Volume: total contacts per 1,000 users, by category, before and after. This is the outcome measure; a fall in chatbot sessions with no fall in phone volume is channel shift, not deflection.
- Cost per resolved need, not cost per interaction.
Two reporting disciplines. Present a range with the assumption stated - for example verified containment of 24–31% with recontacts counted as failures - rather than a single vendor number. And keep a holdout: a set of intents deliberately left unautomated for a quarter, so change can be attributed rather than assumed.
The trap in the current pilot is survivorship. Thirty-one percent handled without handover looks respectable until 22% of those return within 48 hours, which implies a verified figure closer to 24% - the same order of magnitude as the wrong-article rate.
3. What governance does the knowledge base need for either investment to pay off, and who has to own it?
Read the worked answer
Knowledge is the actual product of both options, and it is currently unmanaged.
Ownership: every published article needs a named owner - ideally the product or service owner, not the desk - accountable for accuracy. The desk's role is to report defects, not to be sole author of material about systems it does not own.
Change-triggered review: make article review a task in the change model, so an interface change cannot be closed without reviewing the linked articles. The 12% stale-article finding is a symptom of no such link.
Decay and retirement: articles unused or unreviewed for 12 months get flagged, then retired. A smaller accurate base outperforms 640 unmanaged articles for agents and for automation alike.
Feedback loops: capture article-level helpfulness, and treat chatbot failure reasons and abandoned intents as demand signals for new or rewritten articles. That is the cheapest improvement source available.
Measures: percentage of articles reviewed in the last 12 months, article-level helpfulness, and percentage of the top 20 intents with an accurate article and a defined resolution path.
Caveat worth stating plainly to the steering group: knowledge management is a separate practice. The service desk can champion this and supply the demand evidence, but it cannot deliver it without accountability from service owners, and an AI investment on top of an unowned knowledge base will underperform in exactly the way the chatbot pilot did.