A great service desk is often a warning sign.

The SDI Spark 26 keynote in full. Why service desks were really built. The uncomfortable truth that lives underneath them. And what changes when you stop optimising the desk and start designing the dread out of the service.

// the opening

An ŌURA ring, an AI agent, and a question that wouldn't go away

I wear an ŌURA ring. Nine months old now. It's basically a tiny wearable that sends me daily feedback like, "Mark, have you considered not living like this?"

Last month the battery suddenly dropped from five days to two. So I opened support in the app. Within seconds an AI chat appeared. I'll be honest, I wasn't optimistic. I explained the issue. It asked permission to run diagnostics. A few minutes later it confirmed a fault and escalated automatically. Then I received an email. "A replacement ring has already been shipped." No back and forth. No interrogation. No ticket chasing. No waiting for someone to validate my experience. Just clarity. Resolution in motion. Confidence restored.

And what struck me was this. At no point did I feel like I had entered a system. I felt like I had been helped. There were no categories. No severity codes. No forms to decode. No sense that I was now responsible for feeding a process. It solved the problem I had. It did not optimise the workflow it owned.

And if I'm honest, that made me slightly uncomfortable. Because it exposed how much of our industry still designs support to protect the system, not the person.

If support can feel like that — if friction can disappear like that — then what exactly have we built most of our service desks to optimise for?

Why great service desks shouldn't exist — title slide
// the talk · why great service desks shouldn't exist — opening to the room
// the question

Why do service desks actually exist?

The polite answer is support. The honest answer is this: to absorb the mess we design into our services.

Before anyone tweets about me in the first two minutes, this is not a pop at service desk people. It is the opposite. Some of the best people in our industry sit in support. They have judgement. They have empathy. They can smell nonsense from a mile off. They understand what the user is feeling, not just what the dashboards are reporting.

If your service desk is brilliant, that might be the problem.

Because sometimes brilliance in the desk is not maturity. It is compensation. It is exceptional humans, spending their days buffering users from services that were never designed to be easy to live with.

We celebrate the desk for being heroic, when the real question is — why are we asking for heroism in the first place?

This talk is not about making service desks better. This is a talk about the future shape of service. Where the desk becomes a sensor, not a warehouse. And I am not here to sell you a new framework, a new tool, or another diagram. They are coming, eventually. I am here to challenge and change the mental model.

// the lens

Stressed humans don't behave like tidy process inputs

Quick detour, because this is the lens behind the whole talk. Rory Sutherland is a behavioural scientist at Ogilvy. His view is simple: people don't experience systems rationally, they experience them emotionally.

IT service management keeps trying to solve emotional moments with engineering logic. Portals, categories, scripts, severity codes. And then we act surprised when stressed humans do not behave like tidy process inputs.

ITSM is the only discipline I know that sees a stressed human and thinks, "what they need is a drop-down box."

So when I say dread, confidence, reassurance — I am using that behavioural context. Because it explains why a service desk can look brilliant, and still be compensating for design debt.

I read something recently that captured the difference in mental models perfectly. Someone walked into a customer support function expecting to see rows of people on phones. Instead, it looked like a control room. Monitoring. Tuning. Fixing the system. And that is where this is going. Support as an operating system, not as a queue of tickets.

// 01 — how we got here

2010: control felt like reliability

Rewind to 2010. The UK is still wobbly after the financial crisis. Politics is about elections, coalitions, austerity. The iPhone 4 lands. Then the iPad. Suddenly everyone in IT is Steve Jobs and an expert in user expectations. Tech is changing. Expectations jump overnight, quietly, without asking permission.

Inside IT, the world still feels fragile. Limited visibility. Slower change. Less automation. More risk. So we did what made sense at the time. We reached for control.

Because in 2010, control felt like reliability. If you could standardise it, ticket it, route it, measure it, you could calm the organisation down. We did not build a service desk. We built an anxiety blanket. Then we called it governance.

That is the moment in time the modern service desk model really made sense. Not as a service experience. But as a risk control system.

Same desk. Same SLAs. Different humans. Different reality.

Here is the bit we do not like admitting in IT. We love the idea that service is consistent. Same playbook. Same incident process. Same SLA. Same scripts. Same inputs, same outputs. Except that is not how humans work.

Back in 2010, I was delivering break-fix support to two retail customers. Same service desk. Same tooling. Same SLAs. Same categories. On paper, identical. In reality, one customer felt calm, and the other felt chaotic.

What was different? Not the desk. Not the SLA. Not the process. It was the people. Customer A was a cinema chain. Younger staff. Comfortable with tech. Customer B was a tourist retailer. People were less tech-confident, and the perceived cost of getting it wrong was higher. Same service. Different humans. Different reality.

Why great service desks shouldn't exist — chapter divider
// the assumption we built around · the model that worked in 2010, applied to a world it was never built for

Here is another behavioural truth: friction is not evenly painful. The same form, the same portal, the same script costs different people different amounts. For a confident user, it is a nuisance. For an anxious user, it is a barrier. Under stress, it becomes a threat.

And IT keeps making one mistake — we mistake standardisation for equality. That is why the service desk ends up compensating. Not because the desk is broken, but because the design assumes the wrong type of human. We designed for an imaginary user — confident, calm, reads the knowledge base before calling, never on a deadline — and then blamed support when reality arrived.

It was not a support problem. It was a design problem.

// 02 — what users actually feel

Ticket: keyboard. Truth: payroll.

Picture this. Last working day of the month. A payroll analyst. Coffee. Slightly tense already. They open the payroll system and something fails. Maybe a keyboard. Maybe a token. Maybe the laptop decides to have a moment.

Small problem. Catastrophic timing.

In our current model, we ask them to do something genuinely absurd. We ask them to translate dread into our taxonomy. Not "I cannot run payroll." Not "people might not get paid." We ask for a category. Nothing says "I've got you" like a mandatory drop-down while three hundred people are waiting to be paid.

So they log something like: "keyboard not working." We triage. We route. We measure time to close. We congratulate ourselves on process. Everyone looks busy. Nobody feels safe.

Because the truth is, it was never about the keyboard. The truth is three hundred people might not get paid today. The ticket is not the incident. The SLA is not the experience. It is not a technical issue. It is an anxiety situation.

Label it 'keyboard' and the machine wakes up. Label it 'payday risk' and the humans wake up.

Now imagine a different model. "I cannot run payroll." That is it. No forms. No categories. No guesswork. The front door is a conversation, not a form. It pulls context automatically. It knows it is month-end. It runs diagnostics. It does the boring admin in the background. And while it is doing all that, it does the real job. It tells the person what is happening. What happens next. And what the safe fallback is. And it escalates to a human not because "hardware", but because the impact is human.

That is the moment the service desk stops being a ticket factory. It becomes an emotion management function disguised as a technical function. That is the magic — not because incidents disappear, but because the panic does.

Notice what changed. The admin disappeared. The context got pulled automatically. That is the opportunity of AI in support. Not replacement. Removal of needless labour, so humans can restore confidence.

And here is the tragedy. We know this. We still make people do admin at the worst possible moment, because we built the front door for routing, not reassurance.

// 03 — design as desire

Peter Tarka and the difference between usable and desirable

I have always loved design. In truth, I'm a failed wannabe designer. So I want to show you Peter Tarka's work. He is a digital artist and designer who builds these hyper-clean, playful 3D worlds. The kind of work brands use when they want to feel modern, optimistic, premium — without saying a word. Which is also exactly what most IT portals attempt to do, but with a very different emotional outcome.

Peter Tarka illustration — naming the magic moment
// design that makes you lean in · ask not what this is, ask what behaviour it invites

And that is the bit I care about. Because he is not designing objects. He is designing emotion. Joy. Curiosity. A tiny pull towards the thing. He makes you want to participate.

So while these images are on the screen, do not study the craft. Study the effect. Ask yourself: what behaviour is this design inviting? You smile. You lean in. You get that itch to explore.

Good design does not just make something usable. It makes something desirable. It makes you want to participate. And desire is not a nice-to-have. Desire is how you get people to do the thing you need them to do. Because when something is well designed, people comply willingly. They explore. They self-serve.

Now contrast that with how most IT front doors are designed. Capture, not attraction. Audit, not appetite. Routing, not reassurance. So people do what humans do. They avoid it. They delay. They workaround. They turn up late, and then we punish them for being late. And then IT says, "users are the problem."

No. Design created the behaviour. Ask yourself — what feeling does your service desk create before it solves anything?

The dominant feeling is dread

Think about the dominant feeling most people have when they need IT. Dread. Not because they hate technology. Because they have learned what asking for help feels like.

And this is the thing we keep missing in service management. Emotion is not a side effect of the experience. Emotion is the experience. So when the front door feels cold or accusatory, people behave differently. They do not engage early. Then we call them irrational. But the experience trained them.

Most people get two routes. One: call the service desk and get met with language that is technically correct, but socially cold. Acronyms. Scripts. Categories. Severity. It is like being mugged by a thesaurus. Politely, of course. And with a satisfaction survey at the end.

Two: the portal. The tax return, except you are stressed, and the questions are clearly written by someone who hates other humans. And probably has not ever spoken to one. And then, every time, the dance starts. A ticket comes in, and the first response is not the help you need. It is: "Please provide more information." As though they were withholding information intentionally.

// 04 — agency, choice, and the placebo of control

Crocs, placebo choice, and the hidden value of agency

Let me give you a weird truth about humans. We do not just want a solution. We want a sense of control while we wait for the solution. Behavioural science has this idea of placebo choice. Give people one way to do something, you get modest uptake. Give them a different way, still modest uptake. Give them a choice between the two, and uptake jumps. Rationally, nothing changed. Psychologically, everything changed. Because choice signals agency.

Most service desks do the opposite. They strip agency away at the exact moment someone feels exposed.

So imagine your future front door is not "fill in the form." It is "tell me what you are trying to do" — and then it offers simple choices. "Do you want a call now, or a live chat?" "Is this blocking you, or slowing you down?" "Do you want to keep working while we fix it, or do you need a safe workaround now?"

The choices do not need to be perfect. They just need to return control to the human. That is not nice UX. That is a reduction in dread.

Why great service desks shouldn't exist — chapter divider
// what users actually feel · stress is the design condition we keep refusing to design for

Rory Sutherland tells a story I love. Crocs — fashionable industry's greatest practical joke. Crocs. Proof that comfort beats taste, every single time. Anyway, Crocs wanted to get shoes onto the feet of kids who needed them. But instead of trying to find those kids, they gave them to schools. Kids who went to school went home wearing them. Other kids saw them. And suddenly more kids came to school asking for shoes.

That is behavioural design. Change the context and you change the outcome. Great desks do that all day, usually without being allowed to call it design.

// 05 — the metric problem

XLAs were progress. Then we put them in Excel.

For a moment we almost recognised this. Almost. We tried XLAs. That was progress. Then we did what IT always does. We turned lived experience into a reporting mechanism. And of course it probably ended up in Excel. Because if it is not in Excel, did it even happen? Somewhere out there, an analyst is feeling seen right now.

Metrics are a measure of the past. But feelings are not metrics. Service is a human system. And when the system is built for process, the only way it works is when humans start bending it. That is why great service desks can look like magic. They are not great because the system is great. They are great because they compensate for the system.

So let me be fair. Some desks really do create magic. Not because they follow the process harder. Because they know when the process is getting in the way. They use judgement. They can hear the difference between "my laptop won't start" and "I'm about to lose a day and I'm already behind." They spot patterns. They keep the user calm. That is the magic we should be learning from.

// 06 — frameworks vs judgement

Use ITIL as vocabulary, not religion

I want to be careful here, because I can already feel some shoulders tightening. ITIL has done a lot of good. Shared language. Basic discipline. Professionalised support. But if ITIL becomes your steering wheel, you will build an organisation full of process robots.

Use ITIL sparingly, not as a religion. Use process as scaffolding, not a substitute for judgement. Because the moment process becomes identity, comfort bureaucracy takes over. You are not designing for humans. You are designing for audits.

And if humans are messy, stressed, inconsistent, and sometimes irrational, then the next move is obvious. Stop designing for perfect users. Design for messy humans.

// 07 — the disciplines that matter

Behavioural science. Human-centred design. Service blueprinting. Flow modelling.

So if you want support that works in the next decade, the disciplines that matter are not "more process." They are the ones that take human reality seriously.

Behavioural science · human-centred design · service blueprinting · flow modelling
// the design lenses · behavioural science · human-centred design · service blueprinting · flow modelling

Behavioural science, because stress changes behaviour. Human-centred design, because support is an experience long before it is a workflow. Service blueprinting, because experience dies in the hand-offs. Flow modelling, because restoring work is not the same as closing tickets.

So let me give you the thesis cleanly. If a service desk has to be great to keep the organisation running, it is evidence the service itself is not. Think of it like a building. If a building needs an exceptional maintenance team to stop it falling down every day, you can absolutely praise the maintenance team. You should praise them. But the leadership question is not "how do we make maintenance faster?" It is — why does the building need them every day?

Great at judgement and care, yes. Great at compensating for avoidable failure, no.
// 08 — what to measure instead

The Uber map and the difference between time-to-close and time-to-certainty

That is design debt. And the fastest way we hide that debt is with metrics. Here is a behavioural paradox Rory would love. You can make support faster and make it feel worse. Because humans do not experience service as "time to close." They experience it as "time to certainty."

People are not only bothered by how long something takes. They are bothered by not knowing. Uncertainty is the pain.

Here is a great example — Uber. Specifically the Uber map. That little moving car on a screen does not make the taxi arrive faster. But it makes the wait feel dramatically better. Because it converts "I have no idea what is happening" into "I can see what is happening." It turns dread into certainty.

Now look at most support experiences. We do the opposite. We make people wait in the dark. We give them vague updates. "We are looking into it." "We are investigating." "We will revert in due course." Which is corporate for "you have no control and no visibility."

So if you want one of the most high-leverage improvements you can make in support, it is not a new workflow. It is visibility. Not dashboards for us. Visibility for them. What is happening. What happens next. When you will hear from us. How confident we are. What the safe workaround is if this goes wrong. That is not comms polish. That is behavioural design. And once you see it, you cannot unsee it.

Metrics are not experienced. Experience is not a metric.
// what to measure instead · metrics are not experienced · experience is not a metric

A service can be technically fast and emotionally slow. A service can be technically slow and emotionally brilliant. Because what people remember is not your mean time to restore. They remember whether you left them alone with uncertainty.

Two things can be true at the same time. Your SLAs improve, and your users trust you less. That is why metrics are seductive. They create the feeling of control inside the organisation, while the person outside still feels exposed.

Do you know what is the most dangerous thing about service desk metrics? They work. If you reward time to close, you will get time to close. Metrics get gamed not because people are malicious, but because incentives shape behaviour. So you get closure. Not confidence.

Let's be real. As automation absorbs the easy tickets, what is left gets harder. The remaining work is edge cases, escalations, trust repair. So if you train the organisation to optimise for speed, you are optimising for the wrong job.

I am not saying speed does not matter. If you are on fire, you do not want a philosophy lecture. You want a response. But the user experience of support is not the stopwatch. It is the uncertainty. The silence between updates. The effort of repeating yourself to another team. The moment you realise you are now managing your own incident because you do not trust the system to. A fast experience can still feel awful. A slightly slower experience can feel brilliant — if it reduces uncertainty and restores confidence. That is the difference between throughput and trust.

Metrics can tell you what happened. They cannot tell you what it felt like to live through it. So if speed is not the destination, what is? Remove dread. Make the front door feel reassuring. Use the desk as a sensor for design debt, not a warehouse for tickets.

// 09 — the three moves

Design out demand. Automate what remains. Elevate the humans.

Three moves.

One — design out demand. Take your top ten repeat categories. Stop asking "how do we answer this faster?" Ask "why does this exist?" If you hate a ticket category, do not build a faster queue for it. Kill it at source.

Two — automate what remains. Let agents do the admin. Capture intent in plain English. Pull context. Run diagnostics. Trigger backend actions. Keep the user informed with real next steps.

Three — elevate the humans. Humans do judgement, empathy, exception handling, and trust. They should not be form fillers or queue watchers. Because every minute a skilled analyst spends filling fields is a minute you are burning your best people to feed your own machinery.

Design out demand · automate what remains · elevate the humans
// the three moves · design out demand · automate what remains · elevate the humans

Support does not disappear. It changes shape. The desk becomes a safety net, not a factory.

// 10 — the control room

The desk becomes a sensor, not a warehouse

Remember that control room image. Let me make that real. In the old world, the desk is judged on how fast it processes demand. In the control room world, the desk is judged on how fast it stops demand being created.

So what are the humans doing? One person is watching live intent patterns. Not ticket categories — intent. "Can't access payroll" spikes. "Teams audio issues" spikes. They are looking for changes in the system that correlate with changes in human behaviour.

Another person is doing what I call failure mode reviews. They are reading yesterday's escalations and asking, "what did the AI misunderstand, and why?" Then they tune prompts, fix integrations, tighten guardrails.

Someone else is running what looks like a design stand-up. Top repeat contacts become a backlog. Each one has an owner. Not an owner of the ticket — an owner of the friction.

And here is the important bit. The desk is not just answering questions. It is turning support into service design at operational pace. That is why I keep saying sensor, not warehouse. The warehouse stores problems. The sensor changes the system so the problems stop happening.

AI handles the routine. Humans oversee quality. Humans review the logs, spot failure modes, and tune the system before it produces tomorrow's backlog. Humans step in when trust is on the line.

The same payroll moment, redesigned

Picture the same payroll moment. "I can't run payroll." No categories. No form. No translation. The system pulls context. Runs diagnostics. Takes safe actions. If it needs a human, it escalates with a summary that starts with impact, not category. And the person gets what they actually need. Reduced uncertainty. A clear next step. A safe fallback. That is the difference between a process and a service.

Agentic AI does the admin. Humans do judgement, reassurance, and design. And that is the real upgrade. The humans become the people who operate and improve the system. Part support. Part technologist. Part designer. Every repeat contact becomes a design backlog item. Every high-effort journey becomes a blueprint to fix, not another knowledge article to ignore.

This is how we stop building services that need heroes. We move from coping to designing. So yes — measure the machine. But do not confuse measuring the machine with designing the experience. Because feelings are not metrics. They are the product.

// the close

The service desk that does not need to exist

If the desk is your best experience, the service is unfinished. A sensor, not a warehouse. Because brilliance in the desk is often evidence of failure in the service.

The real magic is not managing failure beautifully. It is designing failure out. Not by removing support. By removing dread. That is the work. That is the leadership.

A service desk that does not need to exist — not because support disappeared, but because confidence replaced dread.

Start next week. Pick the biggest repeat contact you hate the most, and kill it at source. That is how you find the magic in IT.

← back to writing
// want this argument live, on your stage?

This is the keynote in long form. The room version is sharper.

Book Mark to Speak