AI in Professional Services: from task to value

Case: "let's do AI for the Service Desk"

Elena Varga runs the ENGAGE Service Desk at Aldervane Advisory LLP. Last year her team received 18,400 tickets. The duty agent reads each ticket and sends it to one of 14 support groups. Almost one ticket in four is later passed on to another group, and every such reassignment adds hours to the resolution. At the quarterly review David Okonkwo said: "Let's do AI for the Service Desk."

That is not a problem statement. It is a wish. It is unclear which decision should get better, who makes it, based on what data, and what an error costs. The Digital & IT group you work in has to turn the wish into a task — or honestly say that AI is not needed here. This unit teaches exactly that. The rest of the course will keep coming back to this case: it will become the Triage PoC.

Three different classes of solution

Rule-based automation. The behaviour is fully described by logic that can be written down in advance. "If Password reset is selected in the form, send it to Identity." A rule is cheap, testable and explainable. If the task can be solved this way, AI is not needed.

Analytics answers questions about the past: how many P1s there were in the quarter, which group reassigns tickets most often, how time to first response has changed. The result is a report on which a human decides.

AI/ML is needed when the rule is hard to write out by hand but there are examples of correct answers, or when you need to work with the meaning of text:

• predict the probability of an SLA breach;
• suggest a group from the free text of a ticket;
• find similar past incidents;
• prepare a draft reply to a client.

Within AI, the course distinguishes classical ML (u05–u10) and generative AI (u11–u14). These are not synonyms either.

The order of the questions is not accidental: from cheap to expensive. In a real use case, approaches are often combined. For the Triage PoC: rules for obvious forms, ML for free text, analytics to measure the effect.

Five questions before choosing a technology

1. Which decision or action do we want to improve? Not "the Service Desk" but "the initial routing of a ticket to a support group".
2. Who makes this decision now, and how long does it take? The duty agent, 3 minutes per ticket on average.
3. What data is available at the moment of decision? Subject, text, service, sender. Not "the final group in which the ticket was closed": at the moment of routing it does not exist yet. We will return to this trap in u05.
4. What does a correct result look like and how will we know? The ticket was not reassigned and did not breach the SLA.
5. How much does an error cost — in each direction? A P1 sent to the wrong place costs hours of downtime for a client project. An extra ticket for a strong group costs minutes.

"Use an LLM for ServiceNow" is a weak framing. "Cut the reassignment rate from 23% to 12%: suggest a group to the agent from the ticket text and leave the final decision to the agent" is already an engineering task. It has a metric, a baseline and a boundary of responsibility.

Where value arises — and how to calculate it

Typical for IT in professional services:

• triage of requests;
• search over internal knowledge;
• document analysis;
• workload forecasting;
• anomaly detection;
• summarization;
• assistance for developers and testers.

Value is counted in business units, not in accuracy. A rough estimate for the Triage PoC: 18,400 tickets a year. If a suggestion saves the agent one minute on 70% of tickets, that is 18,400 × 0.7 × 1 / 60 ≈ 215 hours a year. That is roughly six working weeks of one agent. Whether that is a lot or a little depends on the cost of the solution, and u15 will deal with that.

But the main value here is most likely not in the agent's minutes but in reassigned tickets. Every reassignment of a P1 means hours the client waits. A good framing names which of the values we are buying.

Human-in-the-loop

In many enterprise scenarios, AI does not replace the human's decision but lowers the cost of making it: it suggests a category, highlights a risk, prepares a draft, shows evidence. There are three typical role splits:

• AI suggests, the human decides. Suitable for the start and for expensive errors.
• AI decides on its own if confident; the rest goes to the human. This saves more but requires measured confidence (u03, u09).
• AI decides, the human spot-checks. Suitable only for cheap and reversible errors.

The higher the cost of an error and the harder it is to undo, the closer to the first scheme. Human-in-the-loop is not free insurance. If an agent confirms 300 suggestions per shift, they stop reading them, and the control exists only on paper (u14).

Cost

Even the simplest AI use case costs more than a model subscription:

• Data. Export, cleaning, labelling. For the Triage PoC, that is weeks of work for Rahul Mehta, data engineer.
• Evaluation. A baseline of "how it is now" and an honest measurement of "how it has become".
• Process change. Agents are trained to work with the suggestion; instructions and SLAs change.
• Maintenance. The model ages along with the data: new services appear, groups get renamed.
• Risks. Confidentiality of ticket texts, errors on rare but expensive cases.

Sometimes the honest outcome of the first unit is "three rules in the ticket form are enough here". That is a result too.

The course's first principle

Don't ask "where can we apply AI?". Ask: which decision do we want to improve, why is the current process insufficient, what level of error is acceptable, and what will the solution cost? Only after that is the technology chosen.