MetroHealth service desk: symptom pressure

Ranking by value and by cause-versus-symptom:

1. Problem management on the database failover fault (cause). Four P1s in six weeks is a known error being repeatedly worked around. Every recurrence costs 9 hours of major incident effort plus business downtime. This is the single largest avoidable cost and it is unambiguously in scope for problem management.
2. Knowledge management plus request automation for the 35% simple demand (symptom relief, high volume). Password resets and access requests are candidates for self-service and automation. Note that this reduces volume reaching agents, not the underlying need - so it must be paired with knowledge quality, otherwise the chatbot will be trained on the same 900 untrusted articles.
3. Diagnosis and resolution capability at first line (shift left). FCR of 42% against a 70% target suggests agents are escalating rather than resolving. This is a competence and authority issue as much as a tooling issue.
4. Chatbot (last). A chatbot built on untrusted knowledge will automate wrong answers and damage trust further.

Order matters: the manager's instinct is to buy the chatbot first because it is visible and fundable. But automating a broken knowledge base multiplies the defect.

Why it has not happened:

• Incident management is measured on restoration time (MTTR), so 'restart applied' is recorded as a successful resolution. The process is working exactly as measured.
• Nobody owns the link between repeated incidents. Four incidents, four separate tickets, no aggregation.
• The knowledge base is distrusted, so the workaround is held in people's heads rather than documented and improved.

Design:

1. Detection: trend recurring incidents by CI and symptom, not by ticket. Set a trigger - e.g. two occurrences of the same symptom against the same configuration item within 30 days automatically raises a problem record.
2. Ownership: a named problem owner with authority to pull in the database team, and a target date. Priority is set by business impact and recurrence rate, not by how recently it happened.
3. Known error record: document the failover workaround properly (not 'restart applied') so the service desk can apply it consistently and fast while the root cause is pursued.
4. Root cause and resolution: investigate the failover mechanism itself; the output is a change, not a document.
5. Closure criteria: the problem closes when the change is deployed and no recurrence is observed over an agreed period - not when the paperwork is complete.

Guard against: problem management becoming a documentation exercise. If the only output is a report, it has failed.

Measures that tell you something:

• Article reuse rate - proportion of tickets where an article was linked and the ticket was resolved without escalation. Rising reuse is the behaviour change you are buying.
• FCR on the targeted categories - e.g. access and password issues, measured separately from overall FCR so the effect is not diluted.
• Article freshness and ownership - % of articles reviewed within their review period, and % with a named owner. Stale knowledge is a maintenance failure, not a writing failure.
• Agent-reported trust - a short periodic pulse, because agents will route around knowledge they do not trust and no metric captures that directly.
• Repeat contacts for the same issue within 7 days - the inverse of a good article.

The misleading measure: article count or article views. Publishing more articles does not improve resolution, and view counts are inflated by people opening an article, finding it wrong, and closing it. Volume of knowledge is not quality of knowledge.

Also watch: if FCR rises but repeat contacts also rise, you have speeded up the wrong answer.