AI Service Desk: The Number to Check First

Before you buy AI for your service desk, measure one thing: the share of your closed tickets whose resolution was already written down somewhere. That number, not a vendor's deflection rate, sets the ceiling on what any AI assistant can do for you. You can produce it this week from your own ITSM export, at no licence cost, and it tells you whether to buy now or write first.

This is written for the IT manager, service desk manager or CIO at an organisation of 250 to 5,000 people running TOPdesk, ServiceNow or Ivanti, with an ICT partner, an internal team, or both. We build and evaluate AI systems alongside the ICT partner you already have. We do not run service desks and are not asking for your pager, which is a separate problem.

What did TOPdesk actually ship, and when?

On 16 September 2026, at its Unlocked event in Utrecht, TOPdesk introduced TOPdesk Robin, an AI assistant that answers end users in the self-service portal and, on the operator side, summarises a ticket, suggests a solution and drafts a reply. TOPdesk's own recap of the day puts rollout from October 2026, grounds Robin in your own knowledge base, and states that customer data stays in the customer's region and is not used to train external models. Teams comes first, WhatsApp and Slack later, and an MCP integration makes TOPdesk data available to the AI tools your teams already use, Copilot included.

This matters more here than a launch in San Francisco would. TOPdesk is a Delft company, founded in 1997, and a platform you will meet constantly across the Dutch mid-market and public sector. Robin is not something to watch from a distance; it is arriving in the platform you already run, and somebody will ask you in a steering committee whether to switch it on.

Two details from TOPdesk's AI documentation are worth more than the announcement. Every AI feature is off by default and only an application manager can switch it on, and the free early access that gave all SaaS customers these features ended on 31 March 2026. Categorisation, knowledge item generation and portal search sit in one package; the answer assistant, triage, summarisation and both halves of Robin sit in the higher one. TOPdesk also documents post-market monitoring to investigate AI incidents in accordance with the AI Act.

The third announcement is the one almost nobody will quote, and it is the most useful. TOPdesk also shipped an AI readiness dashboard showing the state of your knowledge base and where it needs work, plus a service for teams that need help improving it. Read that as the vendor saying in public where the binding constraint is. Not the model.

Why is deflection the wrong number for an internal service desk?

The case against deflection rate is already made, and made well. An analysis by Twig argues that deflection counts abandonment as success, that no standard definition exists so vendors can inflate it, and that one vendor's claimed 80 to 98 per cent lands at 44 to 87 per cent under independent analysis. If you were about to make that argument yourself, don't. Cite it.

That argument is usually made for customer support. Where it has been made for an IT service desk, as in Service Desk Agents' reconciliation of the circulating benchmarks, it lands on fixing your own definition and measuring your own number. Fair, and still one step short: three things about an internal queue change what is worth measuring at all.

Your users cannot leave. A customer who gives up stops being a cost. An employee who gives up walks to a colleague's desk or messages an engineer directly. The ticket does not disappear; it moves off the books. Deflection goes up and the work goes somewhere you cannot see or staff for.

Your tickets are not mostly questions. A large share are requests for change: access to a drive, a licence, a replacement laptop, a mailbox permission. An assistant can answer those perfectly and still not complete them, because completion needs a privileged action and an approval. That is governed by your change process, not your knowledge base, and we have argued that not every change to an AI system belongs in the CAB. Granting an assistant the right to act is exactly the change that does.

Your return is capacity, not revenue. If the desk absorbs a fifth fewer tickets you do not invoice less; you redeploy someone, or stop recruiting. So the question is which categories leave the queue, not how many, because only some of them free a whole person.

Which number should you measure instead?

Measure the answerable share of your own queue. The method takes one person about a day.

• Export 300 closed tickets from your single busiest queue. One queue, not all of them: mixing workplace, accounts and application support hides the distribution you are trying to see. The last 300 is fine if volume is steady; if the queue is seasonal, draw them at random across a year.
• Exclude nothing. Duplicates, nonsense and "resolved, no reply from user" are part of your reality.
• Have one senior operator answer two yes or no questions per ticket. Was the resolution derivable from something already written down, in the knowledge base, a runbook, a vendor article or an earlier ticket? And could it have been completed without a privileged action?

• Count four buckets: answerable and self-completable; answerable but needing a privileged action; not answerable because the resolution exists only in somebody's head; and not answerable at all, because it was real diagnosis.

Three hundred tickets at about ninety seconds each is seven or eight hours of one senior operator's time. That is the entire cost, and it buys a number no supplier can give you.

Then do the arithmetic in your own units. Say the queue carries 1,200 tickets a month and your sample puts the first bucket at 22 per cent. Assume the assistant resolves 60 per cent of that bucket, not all of it, because an article can exist and still not be retrieved, and a user can read a correct answer and raise the ticket anyway. That is 1,200 × 0.22 × 0.60, about 158 tickets a month, to weigh against the licence step the feature sits behind. Both percentages are illustrative; replace them with yours. If your first bucket comes out at 6 per cent, no licence tier makes the sums work, and the honest project this quarter is writing rather than buying.

What does the sample tell you that a vendor demo cannot?

A demo runs against a curated knowledge base and questions chosen to match it. Your sample gives you two things it cannot: the real distribution of your queue, and the size of the third bucket.

The third bucket changes the plan, because it is the only one where buying earlier makes things worse. An assistant grounded in a thin knowledge base answers confidently from the nearest available article, your operators catch it being wrong twice in the first fortnight, and the pilot dies of lost trust rather than technical failure. TOPdesk's readiness dashboard measures the knowledge base. Your sample measures the queue against the knowledge base. Only the second question tells you what to buy.

The sample has a second life. Three hundred tickets with a human judgement attached is an evaluation set: the artefact that tests any supplier's claim against your own traffic, and the next supplier's with the same ruler. Keeping it is what keeps the switching decision yours.

Why does a Dutch ticket queue behave differently from an English one?

Here the English-language guidance stops helping. Your users write in Dutch, your operators partly in English, and product names and error strings arrive in English inside Dutch sentences, so a real ticket reads "de Outlook-plugin crasht bij het opstarten van Citrix". Your knowledge base may be in either language or both. Retrieval quality is a language question before it is a model question.

There is now a measured reference for this. MTEB-NL, published on 15 September 2025 by Banar, Lotfi, Van Nooten, Arhiliuc, Kliocaite and Daelemans, is a Dutch embedding benchmark covering 40 datasets across seven task types, released with companion E5-NL models. Two of its findings bear directly on a service desk.

The first is sobering in a useful way. On the retrieval tasks the authors report 58.2 nDCG@10 for their Dutch-tuned e5-large-trm-nl against 59.1 for multilingual-e5-large. Dutch retrieval is workable, not solved, and nothing like the hit rate a demo implies. The second is worth knowing before a supplier tells you otherwise: on retrieval specifically the Dutch-tuned large model did not beat the general multilingual one, even though compact Dutch-tuned models matched or beat much larger multilingual models across the benchmark overall. "Use a Dutch model" is not automatically right, and neither is "use the biggest model". It is a measurement, per corpus.

The authors flag as a limitation that the benchmark still leans partly on machine- and human-translated datasets rather than natively Dutch ones, which they say limits how far it captures Dutch nuance and context. Translated test data flatters a model on Dutch it will never meet. Your 300 tickets are native, code-switched, abbreviation-ridden Dutch written by your own staff, which makes them a better test of your situation than any public benchmark.

Who ends up owning the knowledge base and the evaluation set?

You will be offered this three ways: as a feature in a higher tier of the platform you already own, by your ICT partner as something they configure or resell, or as a build alongside your stack. Which is right is a separate argument, made in reading what an AI badge actually attests to.

The question that survives all three routes is ownership. After go-live, who holds the knowledge base, and who holds the evaluation set? Both have to stay with you. The platform route has a real advantage here: the knowledge base is already in your tenant and stays there. It also has a metering question worth settling before signature. A community member's post on ServiceNow's forum, not official documentation, describes Foundation, Advanced and Prime tiers replacing the legacy AI SKUs from 9 April 2026, with consumption counted in "assists" at tenant rather than user level. Its author is explicit that the exact per-action values are not publicly disclosed. Treat the mechanics as confirmed and the numbers as unpublished, and ask your account team for the pool size in writing.

What would we do in the next four weeks?

Week one: pick the busiest queue, export the 300 tickets, and agree the two questions with the lead operator so the judgements are consistent.

Week two: judge the sample, count the four buckets, and write the distribution somewhere a steering committee will see it.

Week three: turn the third bucket into a writing list ranked by ticket frequency, and give it an owner with hours in their week. That work pays off whichever route you eventually buy.

Week four: take the sample to your platform vendor and your ICT partner and ask each to run it. Not a demo. Your tickets, your judgements, their system, and a number you can compare.

If the result is "write first", that is a result, not a delay. The organisations that get a useful answer out of an AI service desk in 2027 will mostly be the ones that spent this autumn writing things down. We have made a smaller version of this argument for owner-run firms and their customer-facing queues, where the buckets are simpler and nobody has a licence tier to clear. Our approach to applied AI in mid-sized organisations, our implementation practice in the Netherlands and our guide to writing an AI usage policy set out how we sequence the rest.

Last updated 7 October 2026.

Frequently asked questions