AI in service management

Artificial intelligence has moved from research labs into everyday service tools. Service desk platforms classify and route tickets, suggest knowledge articles and draft replies; monitoring tools detect anomalies; change tools estimate risk; chatbots answer questions at three in the morning. Published summaries describe ITIL (Version 5) as built for a world where AI is part of how services are delivered and managed. This lesson looks at what AI can and cannot do in service management, how to choose good use cases, how to judge whether an AI system works, and how to keep people appropriately in control.

Larchmont's chief information officer, Ruth Akinyemi, has asked LTS for an AI plan. Vendors are offering AI features in nearly every tool Larchmont uses, staff are already experimenting with public chat assistants, and the board wants to know where AI will help reach the three-year targets. This lesson builds the use-case portfolio; lesson 7 looks closely at generative AI and virtual agents; lessons 8 and 9 cover governance and risk.

What we mean by AI

Artificial intelligence is a broad term for computer systems that perform tasks normally associated with human intelligence, such as recognizing patterns, making predictions, understanding language and generating content. Definitions in laws and standards vary. The OECD's widely used definition describes an AI system as a machine-based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.

These categories overlap, and many products combine them. The distinction matters because they fail differently. Rules fail predictably when cases fall outside them. Predictive models fail statistically: they are right most of the time and wrong some of the time, often in ways that reflect gaps or bias in their training data. Generative models can produce fluent, confident content that is wrong. Agents can take actions with real consequences. Each needs different controls.

Where AI helps in service management

AI can contribute to almost every practice. The most mature uses are in high-volume, text-heavy, pattern-rich work where errors are cheap to catch: ticket handling, knowledge, event management and forecasting. Uses that make or influence significant decisions about people, money or safety need much more care.

A useful way to think about AI in practice is by level of autonomy. At the lowest level AI only informs, for example by showing a dashboard of trends. Next it suggests and a person chooses. Then it acts but a person approves each action. Then it acts on its own while people monitor and can intervene. At the top it acts autonomously with periodic review. Most service management uses today sit in the middle levels, and moving a use case to the right should be a deliberate decision backed by evidence.

Choosing use cases

Organizations often start with the technology ('we bought an AI assistant, what can it do?') rather than the problem. A better approach follows the ITIL guiding principle 'focus on value': start from outcomes and pain points, then ask whether AI is the best way to address them. Sometimes a simpler fix, such as better forms, clearer knowledge or a rule, is cheaper and more reliable.

Larchmont scored candidate use cases on five criteria: value (how much it moves a three-year target or cuts cost), feasibility (data availability and quality, integration effort, vendor capability), risk (impact of errors on customers, staff, safety, law and reputation), readiness (process maturity and people's willingness) and time to value. Each criterion was scored 1 to 5, with risk scored so that 5 means low risk.

# Score and rank AI use cases (weights and scores invented)
weights = {"value": 0.30, "feasibility": 0.20, "risk": 0.25, "readiness": 0.15, "time": 0.10}
cases = {
    "ticket classification and routing": {"value": 4, "feasibility": 5, "risk": 4, "readiness": 4, "time": 5},
    "agent assist: suggested replies":   {"value": 4, "feasibility": 4, "risk": 4, "readiness": 3, "time": 4},
    "customer virtual agent for tracking": {"value": 5, "feasibility": 3, "risk": 3, "readiness": 3, "time": 3},
    "change risk prediction":            {"value": 3, "feasibility": 3, "risk": 3, "readiness": 2, "time": 3},
    "automated driver scheduling":       {"value": 5, "feasibility": 2, "risk": 1, "readiness": 2, "time": 2},
}
ranked = sorted(cases.items(), key=lambda kv: -sum(weights[k] * v for k, v in kv[1].items()))
for name, s in ranked:
    score = sum(weights[k] * v for k, v in s.items())
    flag = "  <- high risk: needs full impact assessment" if s["risk"] <= 2 else ""
    print(f"{score:.2f}  {name}{flag}")

4.30  ticket classification and routing
3.85  agent assist: suggested replies
3.60  customer virtual agent for tracking
2.85  change risk prediction
2.65  automated driver scheduling  <- high risk: needs full impact assessment

The ranking puts ticket classification first: high value, good data from years of tickets, low harm when wrong because analysts can correct it, and quick to deploy. Automated driver scheduling has high potential value but scores lowest because it affects workers' hours, pay and safety, involves labor agreements and fatigue rules, and depends on data Larchmont does not yet have. It is not ruled out, but it would need the full impact assessment described in lesson 9 before any pilot.

Data: the foundation

Predictive AI learns from historical data, so its quality depends on that data. If past tickets were often miscategorized, a model trained on them will learn the same mistakes. If urgent tickets from small customers were historically ignored, a priority model may learn to ignore them too. Before building or buying, teams should check that data is available, accurate, consistently labeled, representative of the cases the model will see and lawful to use for this purpose.

Larchmont found that 23 % of historical tickets had been closed with the category 'other', and that categories had been renamed twice in five years. Before training a classifier, the service desk spent four weeks cleaning a sample of 20,000 tickets and agreeing a stable category list. This unglamorous work was the main reason the classifier performed well.

Judging whether AI works

A vendor claim that a model is '95 % accurate' says little on its own. For classification tasks, accuracy can be misleading when classes are unbalanced: if only 2 % of tickets are security incidents, a model that never predicts 'security' is 98 % accurate and useless for the cases that matter. Better measures look at each class. Precision is the share of items the model labeled as a class that really belong to it. Recall is the share of items really in the class that the model found. There is usually a trade-off between the two.

# Confusion matrix and per-class measures for a ticket classifier (invented test data)
labels = ["network", "access", "booking app", "hardware"]
# rows: true class, columns: predicted class
m = [
    [410,  12,   8,  20],
    [ 15, 520,  25,   5],
    [  6,  30, 380,   4],
    [ 25,   3,   2, 235],
]
total = sum(map(sum, m))
correct = sum(m[i][i] for i in range(len(labels)))
print(f"overall accuracy: {correct / total * 100:.1f} %")
for i, lab in enumerate(labels):
    tp = m[i][i]
    pred = sum(m[r][i] for r in range(len(labels)))
    true = sum(m[i])
    print(f"{lab:<12} precision {tp / pred * 100:5.1f} %  recall {tp / true * 100:5.1f} %")

overall accuracy: 90.9 %
network      precision  89.9 %  recall  91.1 %
access       precision  92.0 %  recall  92.0 %
booking app  precision  91.6 %  recall  90.5 %
hardware     precision  89.0 %  recall  88.7 %

Testing should also check performance for different groups and situations: customers of different sizes, regions and languages, and periods such as peak season. A model that works well overall but poorly for French-language tickets, or for small customers, can create unfair outcomes. After deployment, performance must be monitored continuously, because models degrade when the world changes, a problem called drift. A new product, a merger or a change in how customers describe problems can all make yesterday's model wrong.

Keeping humans in control

Human oversight is a principle in nearly every AI framework, but it must be designed, not assumed. A person who approves hundreds of AI suggestions an hour without time to check them is not providing real oversight; this is sometimes called automation bias or rubber-stamping. Effective oversight gives people the information to judge outputs (such as the model's confidence and the reasons behind a suggestion), the authority and time to override, and feedback loops so that corrections improve the system.

Larchmont's service desk designed oversight into the classifier. Tickets classified with high confidence are routed automatically; low-confidence tickets go to a triage analyst; any analyst can reclassify a ticket with one click, and reclassifications are logged and used to retrain the model monthly. A weekly sample of 100 automatically routed tickets is reviewed by a senior analyst to catch systematic errors.

When AI interacts with people or informs decisions about them, transparency obligations may apply. The FTC has brought cases under its authority over unfair and deceptive practices against companies that made misleading claims about AI or used it unfairly. Some states have specific rules, such as California's law requiring bots used to sell or influence votes to identify themselves and Utah's 2024 law requiring disclosure of generative AI in certain consumer interactions, and states including Colorado and Texas passed broader AI laws whose scope and timing changed during 2025 and 2026. With no general federal AI statute, existing consumer protection, civil rights and sector laws remain the main legal guardrails.

Build, buy or embed

Most organizations will use AI mainly through features embedded in products they already buy: the service management platform, the collaboration suite, the monitoring tool. Some will build their own models or applications on top of AI services from cloud providers. A few will train models from scratch. Embedded features are quickest but give the least control over how the AI works and what happens to data; building gives more control but needs skills and ongoing maintenance.

Whichever route, the questions are similar: what data does the AI see and where does it go, can the supplier use it to train their models, how is accuracy measured and reported, what happens when the AI is wrong, who is accountable, and can the feature be switched off? Supplier management, covered in ITIL-141, extends naturally to AI suppliers, and lesson 9 lists contract terms worth seeking.