Practice area · built
The front door to everything else — seven skills for the service desk lifecycle.
Most incidents don't start with an alert. They start with someone calling to say something is broken. The service desk is where that contact gets classified, resolved or escalated, and either fed into incident management or closed properly — and it's where the metrics that tell you whether any of it is working actually get captured.
See it run
One user contact, through the desk and beyond.
A finance user can't log in to the expense system. Watch it get classified, resolved at first touch, then reclassified as an incident when six more people report the same thing.
"Run all" streams the whole contact lifecycle. "Step through" reveals one skill's output at a time.
Deflection layer
Self-service chat, grounded in the public knowledge base.
A chat assistant that answers from the model's own memory is worse than none at all — it invents confident, specific, wrong instructions, and the user follows them. This one can only answer from articles it actually retrieved. Below is exactly how that works, call by call.
"I can't get into the expense system, it just spins after I log in."
Automated{ message, session_id, user_context{ locale, product_tier },
tools_available: [search_knowledge_base, create_ticket] }
The skill forbids answering support questions from memory, so the model emits a tool call rather than a reply. It searches on the user's symptom wording, not its guess at the cause — articles are written to be found by people describing what they see.
Automated{ "method": "tools/call",
"params": { "name": "search_knowledge_base",
"arguments": { "query": "expense system spins after login",
"top_k": 5 } } }
MCP is the interface, not the retrieval. It exposes two tools — search and create-ticket — and is where authentication, rate limiting, and audit logging live. The model can only do what the server exposes.
Automatedembed(query) → vector[1536] hybrid search: BM25 keyword + kNN vector similarity FILTER: visibility = "public" AND status = "published"
Hybrid retrieval — keyword catches exact error strings, vector catches paraphrases — then a reranker orders by actual relevance. The public-only filter is applied here, in the query, not by asking the model to behave. Internal runbooks aren't in the candidate set at all, so no prompt can talk the assistant into revealing them.
Automated · access enforced server-side{ results: [
{ article_id: "KB-1187", title: "Expense login hangs after SSO",
chunk: "...clear the SSO session and re-authenticate...",
url, last_updated: "2026-04-02", score: 0.91,
linked_known_error: "KE-044" }, ... ] }
Direct match → answer and cite. Partial match → say what was found and name the gap. No real match → say so and escalate. Similarity search always returns something, so judging relevance is a separate step from retrieving — the failure mode is treating a near-miss as an answer because it sounds confident.
Never invents steps · cites every source"That's a known issue — clearing your SSO session and signing
in again should get you through. [KB-1187] Did that fix it?"
{ cited: ["KB-1187"], known_error: "KE-044", awaiting_confirmation }
A user who reads an article and leaves is indistinguishable from one who gave up unless you ask. Confirmed resolution counts as deflection; silence counts as abandonment; "no, still stuck" goes straight to escalation without retrying the same article.
Automated{ "name": "create_ticket", "arguments": {
"short_description": "Expense login hangs after SSO",
"transcript": [...], "articles_tried": ["KB-1187"],
"outcome": "workaround did not resolve",
"channel": "self-service-chat" } }
The whole point is that the user doesn't repeat themselves. The ticket carries their own words, which articles were tried, and what didn't work — so the deflection attempt becomes a head start for the agent instead of wasted time. Classification then runs as normal.
Ticket created · human picks it upQuestions that found nothing are a ranked list of articles that should exist. This is the most valuable output of the system.
Two things people conflate
MCP is the interface; RAG is the strategy. MCP is how the model is given tools it can call — a server that exposes search_knowledge_base and create_ticket, holds the credentials, and logs every call. RAG is what happens behind that tool: embed the query, search a hybrid index, filter by visibility, rerank, return chunks. You can do RAG without MCP and MCP without RAG. Here they're stacked, and the split matters because it's the seam where security lives.
Access control belongs in the query, not the prompt. The single most common mistake in these builds is instructing the model not to reveal internal content. That's not a control — it's a request. The public-visibility filter runs in the retrieval query, so restricted articles are never in the candidate set and there is nothing for a clever prompt to extract.
- Automated search, retrieval, filtering, ticket creation
- Constrained answers only from retrieved sources, always cited
- Human-led anything destructive, irreversible, or requiring authorization
Where the assistant lives
Placement matters more than model quality. An excellent assistant on a portal nobody visits deflects nothing; a competent one in the channel where people already complain deflects a great deal. The rule is to meet users where they already are — and for most organizations that is a chat tool, not a portal.
Slack
Slack app or bot with slash commands, plus Workflow Builder for structured intake. ServiceNow, Jira Service Management (formerly Halp) and Zendesk all ship Slack integrations that create and sync tickets in-thread.
Why it works: people already report problems in Slack, usually in a team channel, before they ever think about a ticket. Catching it there means catching it at the moment of frustration — and a threaded answer is visible to everyone else with the same problem, deflecting contacts that were never made.
Microsoft Teams
Teams bot via Copilot Studio / Power Virtual Agents, ServiceNow Virtual Agent for Teams, or Jira Service Management's Teams app.
Why it works: the same logic as Slack, and usually the right answer in Microsoft-estate enterprises where Teams is where work already happens. Often the highest-adoption option with zero user training.
In-product / in-app
Embedded widget inside the application itself — Intercom, Zendesk Web Widget, Freshchat, or a custom surface.
Why it works: the highest-value placement, because the assistant knows context — which screen, which account, which plan, which version. That context sharpens retrieval more than any prompt tuning will, and it catches users at the exact point of failure rather than after they've given up.
ITSM-native virtual agent
ServiceNow Virtual Agent, Zendesk AI agents, Freshservice Freddy, Atlassian Intelligence.
Trade-off: tightest ticket integration and least plumbing, since it already lives in the system of record. But it only reaches users who came to the portal — which is the population least in need of deflection, because they were already filing a ticket.
Self-service portal
Search-first portal experience, with the assistant fronting the knowledge base rather than a keyword search box.
Trade-off: the traditional home for deflection and still worth doing well, but it depends entirely on the user choosing to go there first. Treat it as a destination, not the strategy.
Voice / IVR deflect-to-SMS
Genesys, Five9 or Amazon Connect (with Lex) recognising intent in the queue and offering to text a link rather than hold.
Trade-off: genuinely valuable during a queue spike, when hold times are the real problem. But a caller who wanted a person and got a text link will judge it harshly unless the offer is optional and the path back to a human is obvious.
Email auto-response
Inbound support email triggers a suggested-articles reply before an agent picks it up.
Trade-off: the weakest form. It is one-shot, cannot ask a clarifying question, and reads as a brush-off if the match is poor. Set a high confidence bar or skip it.
SMS / WhatsApp
For deskless and field workers who have no laptop and will not open a portal.
Trade-off: narrow but sometimes the only channel a population will actually use. Worth it when the alternative is those users never reporting anything at all.
Whichever surfaces you pick, they should all call the same MCP tools against the same index — one assistant with several front doors, not several assistants with drifting answers. A Slack bot and a portal widget giving different answers to the same question is worse than having only one of them.
When the assistant is unavailable
Deflection is the layer users hit first, so it's the layer whose outage is most visible — and an AI-fronted help centre that returns errors is worse than one that was never there. The rule is the same as on the incident side: the AI layer is never load-bearing. If retrieval or the model is unavailable, the surface falls back to plain keyword search over the same knowledge base, and the “contact us” path stays permanently available rather than being something the assistant decides to offer. Never let a failed assistant become a dead end between the user and a person.
The full three-tier degradation model — AI-assisted, deterministic fallback, human-run — is set out on the incident & problem page.
-
00
Self-service knowledge assistant
Governs the behaviour above — search before answering, judge relevance honestly, cite everything, never invent a step, and escalate with the conversation attached.
Why this skill exists
A support chatbot that answers from the model's own memory is worse than no chatbot. It will produce confident, plausible, specific instructions that are wrong for this organization — a settings path that doesn't exist, a workaround for a different product version, a policy invented from the general shape of policies. In support that isn't a harmless hallucination; the user follows it, it fails or breaks something, and the ticket they eventually file is now harder to solve because of the steps they took first.
So the entire discipline here is: **answer only from what was actually retrieved**, cite it, and say plainly when the knowledge base doesn't cover the question. A fast honest "I don't have an article on that, let me get you to someone who can help" is a good outcome. A fabricated workaround is the worst outcome this system can produce.
● Full skill source is encrypted. Unlock at the foot of this page to read it.
The skills
Seven skills, contact to closure.
Each one's actual source is viewable below — not a description of what it does, the real instructions.
-
01
Intake & classification
Sorts incident from service request from information ask, pulls the missing facts out of a vague report, sets priority from impact and urgency, and routes it.
Why this skill exists
Users don't report problems in the categories the process needs. They say "it's slow," "I can't get in," or "the thing is broken." Getting that into the right lane matters more than it looks: misclassifying a service request as an incident inflates incident volume and distorts every metric downstream, and misjudging impact means a one-user annoyance gets the same response as a site-wide outage — or worse, the reverse. This skill does that first sort well and pulls the specific facts that make everything downstream possible.
● Full skill source is encrypted. Unlock at the foot of this page to read it. -
02
First-touch resolution
Checks the known error database before improvising, applies the relevant TSG, and makes an honest resolve-or-escalate call instead of grinding.
Why this skill exists
Every ticket escalated unnecessarily costs far more than one resolved at the desk — in cycle time for the user and in tier 2/3 capacity that should be going to genuinely hard problems. But the opposite failure is worse: a tier 1 agent grinding on something for forty minutes that was never solvable at their access level, while the user waits. This skill exists to make that call quickly and honestly, and to make sure the cheap wins — a documented known error, an existing TSG — get checked *before* anyone starts improvising.
● Full skill source is encrypted. Unlock at the foot of this page to read it. -
03
Service request fulfillment
Entitlement, approval path, and a fulfillment sequence with honest timing — kept in its own lane so request volume never distorts incident metrics.
Why this skill exists
Requests and incidents are different work with different economics, and the discipline of keeping them separate is what makes both measurable. A request is planned, repeatable, and pre-approved — nothing is broken, so speed matters more than urgency, and the right answer is usually a standard workflow rather than judgment. When requests get handled as incidents, incident volume becomes meaningless as a signal and genuinely urgent work competes with laptop orders.
● Full skill source is encrypted. Unlock at the foot of this page to read it. -
04
Escalation & handoff
Functional vs. hierarchical escalation, and a context package complete enough that tier 2 never re-interviews the user.
Why this skill exists
Most escalations lose information. The ticket arrives at tier 2 with the user's original three-sentence complaint and no record of the twenty minutes tier 1 already spent, so the receiving engineer starts over — re-asking questions the user already answered, re-running checks already run. That's the single biggest source of avoidable cycle time in a support organization, and it's what makes users feel like nobody is listening. A good escalation is a complete handoff, not a forwarding.
● Full skill source is encrypted. Unlock at the foot of this page to read it. -
05
User communication
One-to-one requester updates — acknowledgment, progress, expectation resets, and responding to a chasing user without defensiveness.
Why this skill exists
Users judge support far more on communication than on resolution speed. A ticket resolved in two days with three updates along the way is experienced better than one resolved in one day with silence — because silence reads as nobody working on it. Most poor satisfaction scores come from tickets where the work was fine and the communication wasn't. This skill exists to make the updates specific, honest, and frequent enough that the user never has to chase.
Note the distinction from incident status updates: that skill broadcasts to many people about a service-wide event. This one is a conversation with one person about their ticket.
● Full skill source is encrypted. Unlock at the foot of this page to read it. -
06
Closure & satisfaction
Confirms before closing, writes a resolution record the next agent can actually search, and decides what becomes an article, known error, or problem.
Why this skill exists
Closure is where most of the learning in a support organization gets thrown away. The ticket gets marked resolved with a note like "fixed" or "user confirmed OK," and everything the agent figured out disappears — so the next person with the same symptom starts from nothing. Closure is also where satisfaction is won or lost: closing a ticket the user doesn't consider resolved is one of the most reliable ways to generate both a reopen and a bad score.
● Full skill source is encrypted. Unlock at the foot of this page to read it. -
07
Performance review
Reads the metrics against each other rather than singly, finds what's driving a movement, and turns it into an automate/document/investigate decision.
Why this skill exists
Service desk metrics are unusually easy to game and unusually easy to misread. First Contact Resolution goes up when agents close tickets prematurely. Average handle time goes down when agents rush users off the phone. CSAT looks fine when only satisfied users respond. A number moving is not the same as performance changing, and a dashboard full of green is not the same as a service working. This skill exists to read the numbers against each other rather than individually, and to get from "this went up" to "here's what to do."
● Full skill source is encrypted. Unlock at the foot of this page to read it.
Tooling
Where the desk actually runs.
The tool inventory a service desk touches, and which systems go hot at each step of a contact. Switch between an internal IT desk and a customer-facing support organisation — the lifecycle is the same, the estate underneath it is not. Conceptual architecture — not a live integration on this page.
Channels
Genesys / Five9 / Amazon Connect Slack / Teams bot Employee self-service portal EmailSystem of record
ServiceNow ITSM Jira Service Management Freshservice / ManageEngineKnowledge
KEDB Confluence / SharePoint / GuruEntitlement
Okta / Entra ID / ADAlerting & on-call
PagerDuty / OpsgenieVoice of customer
Employee CSAT surveyAnalytics
Performance Analytics Power BI / Tableau / GrafanaEscalates to
Incident management Problem management-
01
Intake & classification
Reads: the contact itself — call, chat, portal form, email
Writes: a classified, categorized, prioritized ticket
Captures: channel, contact type, category, priority
-
02
First-touch resolution
Reads: known error database, troubleshooting guides
Writes: work notes, link to the matched known error
Captures: FCR, KEDB hit rate, TSG coverage
-
03
Service request fulfillment
Reads: service catalog, entitlement in the identity provider
Writes: approval workflow, provisioning request
Captures: time to fulfill, approval wait, deflection
-
04
Escalation & handoff
Reads: assignment groups, on-call rotation
Writes: tier 2 queue — or an incident record when scope grows
Captures: escalation rate + reason, incident conversion
-
05
User communication
Writes: ticket correspondence, email, chat, SMS
Captures: time to first response, update cadence adherence
-
06
Closure & satisfaction
Writes: resolution record, knowledge article draft, survey trigger
Captures: reopen rate, CSAT, MTTR, article creation
-
07
Performance review
Reads: the full ticket estate and its captured measures
Writes: service review pack; problem records where volume warrants
Captures: the trends that drive automation and knowledge investment
Notice how often the system of record is hot — it's touched at every step. That's what makes it the place metrics live, and why a desk running on spreadsheets alongside its ITSM tool can never report reliably.
Escalation path into incident management
Most incidents don't start with an alert — they start with people calling. When the desk sees the same symptom from several users, or a single contact with enterprise-wide impact, the ticket stops being a ticket and becomes an incident. That trigger is a defined step in 04 · Escalation & handoff, not a judgment call someone makes informally.
{ trigger: "multi_user_same_symptom", contact_count: 7,
window_minutes: 21, service: "expense", ke_matched: "KE-044",
business_impact: "month-end close blocked",
handoff_to: "incident-triage-classification" }
The desk hands over what it already knows — symptom, confirmed user count, known error match, business impact — so triage starts with a classified picture rather than re-interviewing the first caller.
Key process indicators
What gets measured, and where it gets captured.
Metrics aren't a reporting afterthought bolted on at the end — each is captured at the step that produces it, because most of them can't be reconstructed later. Channel and contact type only exist at intake. Escalation reason only exists at the moment of escalation.
Demand
- Contact volume by channel phone, chat, portal, email — captured at intake
- Contact type split incident vs request vs information
- Volume by category the automation and knowledge investment list
- Self-service deflection rate resolved without an agent
Speed
- Time to first response what users feel most acutely
- Average speed of answer / abandonment staffing and forecasting signal
- MTTR by priority aggregate MTTR hides both ends
- Time in state working vs waiting on user vs waiting on another team
Quality
- First Contact Resolution the headline efficiency measure
- Reopen rate the counterweight — never read FCR without it
- Escalation rate with reason the reason is what makes it actionable
- Bounce-back rate from tier 2 handoff quality
- CSAT with response rate a score without its response rate is unreliable
- SLA attainment by priority
Capacity
- Backlog and aging by priority aging P1s and a low-priority pile are different problems
- KEDB hit rate falling hits usually means stale knowledge, not harder problems
- TSG coverage contacts where a guide existed vs didn't
- Cost per contact
Read them in pairs, never singly
Almost every service desk metric is misleading alone, and the most common management error is celebrating one number while its counterweight moves the wrong way.
- FCR × reopen rate — FCR rising while reopens rise means tickets are being closed prematurely. A worse outcome disguised as a better number.
- Handle time × FCR × CSAT — falling handle time with falling FCR means agents are rushing and pushing work downstream.
- CSAT × survey response rate — a high score from a 4% response rate tells you about the 4%. Dissatisfied users often don't respond at all.
- Volume × deflection — volume falling is only good news if deflection is rising. Otherwise users may have stopped asking.
- Escalation rate × KEDB hit rate — escalations up while KEDB hits fall means the knowledge base went stale.
Full skill sources
The complete instructions are encrypted.
The rationale for each skill is open above. The full operational detail — the matrices, thresholds, output formats and judgement rules — is AES-256 encrypted and decrypted in your browser only. The ciphertext is all that exists in the page source or the repository.
Recruiters and hiring teams: get in touch and I'll share access.
Hiring for TPM or incident management roles
I'd like to talk about how this kind of work applies to your team.
ahlevin@hotmail.comlinkedin.com/in/alanlevin
Want this running for your team
Interested in these skills — or something like them — supporting how your team actually operates. Let's talk about what that would take.
ahlevin@hotmail.com