Modernizing the service desk: requests, knowledge and agents

When people talk about AI agents at the help desk, the conversation usually goes straight to incidents: classifying alerts, suggesting the probable cause, assigning the right team. It is a good use case, and we cover it in incident triage with agents. But much of a service desk's daily work is not incidents. It is requests: an access, a laptop, a license, a password reset, a question about how to do something.

Those requests are repetitive, predictable and, in many cases, still depend on someone reading an email, copying it into a ticket, asking for whatever was missing and passing it to another team. Modernizing the service desk starts there: putting requests in order, turning what people know into reusable knowledge and, only then, putting agents on the front line. This article proposes that sequence.

A request is not an incident

ITIL 4 separates two practices that many organizations merge into a single queue. Incident management aims to restore service when something fails. Service request management handles predefined, user-initiated requests: nothing is broken, someone needs something the service already expects to deliver. Both arrive through the service desk, the single point of contact with users.

The distinction matters because it changes how the response is designed. An incident requires diagnosis; a standard request requires a known procedure, defined approvals and, ideally, automatic execution. If both go to the same queue with the same form, simple requests wait behind complex problems and analysts spend diagnostic time on tasks that do not need it.

If you are still building your practice foundation, in the five ITIL 4 practices to start with we explain why service request management is among the first.

Start with the catalog

No agent can fulfill a request nobody has defined. The first step is a catalog of standard requests, where each item has:

• A name users understand, not the internal system's name. "Access to a shared folder", not "File server ACL provisioning".
• The minimum data required, asked for once and validated on entry.
• The approval rule: no approval, direct manager approval or data owner approval. Explicit, not left to the analyst's judgment.
• The fulfillment procedure, with the responsible team and the committed time.
• The item owner, who reviews it when the service changes.

You do not need to catalog everything. It is best to start with the highest-volume, lowest-variation requests, which usually account for a large share of demand. Those that do not fit the catalog keep arriving through a general channel and are reviewed periodically to decide whether to add them.

Knowledge as a by-product of daily work

The second piece is knowledge. Many knowledge bases fail for the same reason: they are written as a separate project, by a separate team, and they age without anyone noticing. Knowledge-Centered Service (KCS), the methodology maintained by the Consortium for Service Innovation, proposes the opposite: knowledge is created and improved as part of resolving each case.

The KCS v6 Practices Guide organizes the method into two loops:

• The Solve Loop: capture knowledge in the workflow, structure it so it can be reused, reuse it by searching before solving, and improve it every time it is used.
• The Evolve Loop: look after content health, integrate it into processes, assess performance and sustain it through leadership and communication.

For a service desk that will use agents, KCS has a practical consequence: the agent is only as good as the knowledge it draws on. An outdated, ambiguous or expert-only article produces outdated, ambiguous or incomprehensible answers, now at scale. Knowledge quality stops being a documentation topic and becomes a service quality topic. The same principle applies to the technical information support teams use; we develop it in living documentation with agents.

Self-service and automated fulfillment

With the catalog and knowledge in order, self-service stops being a portal nobody uses. Users find the answer or the right form without opening a ticket, and the request arrives complete.

The next step is to automate fulfillment of standard requests: approval triggers execution without an analyst copying data from one system to another. We recommend choosing candidates with three criteria:

1. Stable procedure: always the same steps, with few exceptions.
2. Available integration: the target system has an API or an automation tool that can run the step with traceability.
3. Bounded risk: an error is detected and reversed without significant harm. Privileged access or access to sensitive data keeps human approval even when execution is automated.

To decide what to automate first, the value and complexity prioritization framework helps: high-volume requests with a simple procedure are usually quick wins.

Agents that serve and escalate with context

Only with that foundation does it make sense to put an AI agent on the front line. Its job is not to replace the catalog or the knowledge base, but to connect them with the person asking for help.

A well-designed service desk agent does four things:

• Understands and classifies: it tells a request from an incident, identifies the catalog item and asks only for the missing data.
• Resolves with authoritative sources: it answers with cited knowledge articles, not with what the model "remembers", and starts catalog requests through the same integrations the portal uses. Having the agent act through controlled integrations rather than shortcuts is a design condition; we cover it in integration first.
• Respects approvals and permissions: it verifies the requester's identity, does not approve on anyone's behalf and does not run anything the catalog does not allow.
• Escalates with context: when it cannot resolve, it hands the person a summary of the request, the data collected, what was already tried and the articles consulted. The user does not repeat anything.

That last point shapes much of the experience. An escalation without context forces the user to explain everything again and the analyst to start from scratch. An escalation with context is, in practice, a better-written ticket than the one the user would have opened.

Metrics to know whether it works

Traditional service desk metrics are still useful, but they need to be read differently when an agent handles part of the work. This table summarizes the ones we recommend tracking:

Metric	What it measures	How to read it	Trap to avoid
First contact resolution	Cases resolved without escalation or reopening	Separate the agent's rate from the people's rate	Closing cases the user does not consider resolved
Fulfillment time	From request to delivery, per catalog item	Compare against each item's committed time	Averaging very different items
Knowledge use	Cases resolved with a linked article, articles created or improved	Should grow together with resolution, not separately	Counting published articles instead of reused articles
Escalation quality	Escalated cases where the analyst did not have to ask again	Shows whether the context the agent hands over is useful	Not measuring it and finding out through complaints
Reopen rate	Closed cases that come back	Counterweight to first contact resolution	Opening a new ticket instead of reopening
Satisfaction	User perception at case closure	Split by channel and by type of service	Surveys with response rates so low they represent nobody

No metric is read on its own. First contact resolution that rises while reopenings also rise is not an improvement. We recommend setting targets before putting the agent into production and reviewing them with the service owner, not just the technical team.

The human role

Modernizing the service desk does not remove people; it changes what they do. Analysts spend less time copying data and more time solving cases that have no procedure, improving the articles the agent uses and spotting patterns that deserve to move into the catalog or into problem management.

New responsibilities also appear: someone owns knowledge quality, someone reviews the agent conversations that ended badly and someone decides which requests the agent may start and which require approval. Those decisions are documented and governed like any other permission: with the agent's own identity, least privilege and a record of every action.

If the agent serves external customers or handles personal data, the definition of what it may answer, what it records and when it must hand off to a person should be validated with Compliance and the data protection function before going to production.