Support is judged on how it feels, and your dashboard cannot see it

For about a year I kept a support dashboard on a screen next to my desk. Median first response under six minutes. Same-day resolution in the nineties. Reopen rate low enough that I put it in a board update.

Then someone I genuinely like told me, over a coffee she insisted on buying because she felt bad about asking me something, that contacting IT felt like taking a numbered ticket at the DMV.

Not slow, and not wrong. Just like being processed.

I went back to the dashboard looking for something that contradicted her, and there was nothing there to find. Every number I collected described the machinery. None of them described what it was like to stand in front of it.

The numbers were measuring my side of the desk.

The refresh that worked

A systems manager who runs IT alone for a 35-person healthcare consultancy ran a laptop refresh most of us would put on a résumé. Machines drop-shipped. Self-configuring on first boot. Nothing to install, no imaging, no lost afternoon. Zero touch that was actually zero touch.

People were anxious anyway.

Not about the deployment mechanics, which they never saw. They were afraid of losing logins they had accumulated over years, afraid their files wouldn't come across, afraid of a client call going sideways on day one with a machine they didn't know yet. Excellent engineering removed all of the work and none of the fear, because the fear was never about the work.

Here is the part that should bother you. Afterward, nobody mentioned that the technology had worked. What everyone talked about was being in a room together, helping each other, and not feeling alone with it.

Sometimes how support feels matters more than how it works.

If you build things for a living, that sentence lands badly, because it sounds like the craft was beside the point. The craft is what buys you the room. Good engineering creates the space where somebody has the time to sit with a colleague instead of imaging a laptop. It just doesn't do the sitting for you.

A word with no respect built into it

The same manager makes an argument about vocabulary that I filed under "precious" the first time I encountered it and have since completely reversed on.

The argument is that if you call someone a user often enough, you start treating them like one. He offers the dictionary as evidence. A user is a person who uses something, or a person who uses illegal drugs. There is no respect built into the word anywhere. It is a category label for whatever is at the far end of the system.

I resisted this for years, on the grounds that "user" is compact, unambiguous, and printed in every vendor document I have ever read. Then during an outage I wrote a status page, read it back, and counted the word eleven times in four paragraphs. I had described a few hundred colleagues as a load metric. Now I use "colleague" or a person's name in anything a non-IT human will read, and I keep "user" for schema fields, where nobody's feelings are involved.

Vocabulary follows structure, and our structure is made of statuses. As he puts it: we've got queues, dashboards, ticket numbers, everything sorted by status, never by a person.

Which is how a team ends up shipping the message I have personally written four versions of: "We have received your request and will respond when we are able." That sentence conveys exactly one fact, which is that you are in a queue.

"Hey, I saw this come through and I'll take care of it." Same information. Same queue, same wait, same everything. A completely different experience of being a person who needed help.

Respect is a hundred smaller ones

His line, and it's the best summary of the whole practice: respect is not one big gesture. It is a hundred smaller ones.

Acknowledge the feeling, then fix the thing. "Send me a screenshot" does the job. "That sounds frustrating, send me a screenshot and we'll look through it together" does the job and tells the person they are not being handled. Four extra seconds of typing.

Guide rather than take over. Remote in, fix it silently, leave, and you have closed a ticket and taught nobody anything. "Show me what you tried" does two things at once: you get context you didn't have, and the person hears that their effort counted for something instead of being routed around.

Say you don't know. "I'm not sure, let me look into it" beats a confident guess that turns out wrong. Then actually follow up. People notice when you do, and they really notice when you don't.

Acknowledge fast even with nothing to offer. "Got it, I'm on it" is not a solution and doesn't pretend to be. It ends the silence, and the silence is the part people can't stand.

Never let someone feel caught out. Somebody tells you what they tried and it was a terrible idea. "What you tried makes sense. Here's a way that'll probably go smoother next time." That is the entire intervention.

Explain what happened. Fix it without a word of explanation and the person is exactly as confident tomorrow as they were yesterday, which means they will file the identical ticket again in March.

One person who came up through support at a large consumer electronics operation described two house rules I keep coming back to. Never tell a customer "I don't know," say "I'll find out." And phone agents were issued mirrors so they could see their own faces while they talked, because your expression carries in your voice whether or not anyone can see it.

Then there is restating the problem back, which is probably the highest-yield habit available to a support team and costs nothing. Someone in this practice put the reason better than I can: your users, customers, clients don't always tell you what the problem is, they tell you everything else around it. Mirroring the problem back surfaces the miscommunication in minute one rather than minute twenty, and it makes people feel heard, and sometimes what someone needs most is a person to talk to and the ticket is just the pretext.

A tier-four support engineer described being the only woman on her engineering support team, where customers doubted her diagnoses even when she had them right in the first two minutes. So she built a longer style out of necessity: walk the customer through how the system actually works and let them discover the problem themselves. She reframed it later as generally better practice rather than a workaround for being disbelieved. I think that's correct, and I also think it's a little damning that the technique forced on her by bias turns out to be the one that leaves customers more capable than the blunt right answer does.

Explaining things without condescending

Analogies come up constantly among people who are good at this, and the good ones are weirdly specific.

Restarting a computer explained as sleep, clearing out the mental clutter that piled up during the day. RAM and CPU explained as a kitchen: counter space is your RAM, the chef is the processor, the pantry is the hard drive. Too many browser tabs explained as too many books in your backpack, or as running out of fingers to hold your place.

The meta-technique matters more than any individual analogy. Ask the person what they are an expert in, then build the comparison out of their domain instead of yours. A pharmacist and a litigator each have a working model of constrained resources already installed, and borrowing theirs is an act of respect. Reaching for the kitchen every time is a script.

Two mental models get offered for the moment you feel your patience going. Treat the person as if they were a family member. Or picture yourself as the confused customer phoning a mechanic about a car you know nothing about, trying to describe a noise.

What an apology at the start of a message tells you

"Sorry to bug you." "This is probably a dumb question." "I know you're busy."

Read enough of those and stop hearing politeness. Someone opening with an apology has internalized the idea that needing help makes them a burden, and if your team confirms that suspicion even slightly, they will delay next time. Which means you hear about the problem later, from further away, when it has grown.

The behavior downstream is predictable. That same consultancy found staff had been downloading whatever free tool they needed and hoping it was fine, because asking felt expensive.

A few things visibly reverse the charge.

Phishing reporting got normalized down to "trust your gut, flag it." Every flagged message gets reviewed, quarantined if it's bad, released if it's fine, with no real downside to over-reporting. The cultural result is my favorite detail in the whole story: suspicious emails now get posted publicly so people can laugh at them together, rather than being clicked on privately.

Onboarding and refresh walkthroughs were run in small groups on purpose rather than one-to-one, so nobody felt singled out for not knowing something, with a survey afterward and individual follow-ups for anyone who looked like they were struggling silently inside the group.

The ticket itself got re-explained as being for the requester's benefit. It tracks patterns, it makes the same problem faster next time, it is a record with your name on it rather than paperwork you owe IT. Once they understand the process is there to help them, it stops feeling like a barrier.

And trust turns out to be contagious sideways. Colleagues in that shared channel increasingly answer each other before IT sees the question at all, and publicly thanking the peer who answered reinforces it more reliably than any policy. When a request lands outside your remit, saying what is possible and connecting the person to the right team builds more goodwill than "I can't help," even though you fixed nothing.

Swaps you can make this week

No project. No budget line. Just wording.

• "We have received your request" becomes "Saw this, I've got it."
• "Send me a screenshot" becomes "That sounds annoying, send me a screenshot and we'll go through it together."
• "I don't know" becomes "I'll find out, give me until this afternoon."
• "You shouldn't have done that" becomes "What you tried makes sense, here's what'll go smoother next time."
• "Fixed" becomes "Fixed, and here's what was actually happening, so you'll recognize it."
• "That's not my team" becomes "Here's what I can do, and here's who owns the rest, copying them now."
• Before you diagnose: "Let me say this back to you so I'm sure I've got it."
• After you close: one message, two days later, asking if it held.

Ban the word "user" from anything a colleague will read. Keep it in the database.

The part that doesn't transfer

Be honest about scale, because the most human support operation in any of this was one person answering roughly 35 people quickly and personally, and he said himself that this is a small-company advantage and not everyone can do it at that speed. He's right. A team of six covering 4,000 people cannot reply to everything in four minutes, and pretending otherwise is how you get a burned-out help desk with lovely tone.

The techniques port. The response time doesn't. Structured intake, peer answering, and proactive automation are what buy you back the minutes that make the tone possible, which is why the engineering still matters.

There's an argument I keep hearing from people thinking about AI in support that lands on the same place from the opposite direction. As polished output gets cheap and instant, the things that still separate good support from adequate support are the explicitly human ones: empathy, actual curiosity about a person's context, and judgment about what "good" means for this specific person on this specific afternoon. A model can produce a flawless resolution note. It cannot yet care whether you were about to present to a client.

My old dashboard is still running somewhere. All the tiles are probably still green.

The thing my colleague was telling me over that coffee is that green was never the question. People do not remember the resolution time on their ticket. They remember whether they felt like a nuisance while they waited.