The fault is never in the ticket

A client reported that a piece of software had stopped working. It hadn't. They had moved offices over a weekend and changed their server infrastructure in the process, and nobody had mentioned it… because from where they sat, nothing about the software had changed.

That's not an unusual case. It's the normal one.

I've done front-line support at an ISP, run a university help desk, and now handle client-facing support for enterprise software. Three very different environments: consumer broadband, a campus of students and academics, and regulated organisations running systems they depend on daily. The technical content has nothing in common. The shape of the problem is identical every time.

The report is a conclusion, not an observation

"The internet is down" is not a description of what happened. It's a diagnosis, made by someone with partial information, and it arrives pre-packaged as fact.

What actually happened is that a page didn't load. Between that observation and "the internet is down" sits a chain of assumptions the reporter made without noticing they were making them. Sometimes the chain is right. Often the router is fine, the line is fine, and one DNS entry is wrong, or the site itself is down, or the laptop is on the guest network.

The first job in any support conversation is getting back down the chain to the observation. Not because people are careless, but because a conclusion is more useful to say than an observation is, so that's what people say. "The internet is down" gets a response. "A page didn't load" sounds like you haven't tried hard enough.

So the useful question is rarely "what's wrong." It's "what did you see."

"Nothing changed on our end" is almost never a lie

This is the sentence you hear immediately before you find the change.

It's tempting to treat it as evasion. It usually isn't. The person on the phone has a definition of "changed" scoped to their own responsibilities, and it's an honest one. In the office-move case, nobody was hiding anything; moving premises was a facilities decision made months earlier, and the person reporting the fault worked in accounts. They were asked whether anything had changed with the software. Nothing had. The answer was accurate.

The person who knows about the change is almost never the person who reports the fault. That's not a communication failure at the client. It's a property of how organisations work, and if you plan for it you stop being surprised by it.

Ask about events, not changes

The practical: don't ask if something changed — you'll most probably get a no.

Ask about events instead. Who is using this? When did it last work? What's different about today compared with Friday? Has anything moved, been replaced, been renewed, been cancelled? Did anyone new start? Did the power go out?

People remember events. They don't remember "changes," because the word implies responsibility, and once someone thinks a question is about blame they start answering defensively rather than accurately. That isn't dishonesty either; it's what anyone does when a question sounds like an accusation.

You get better information by making the question about the world rather than about them.

The same applies to how you handle being right. When it turns out the fault was on their side, saying so plainly and moving on costs you nothing. But making a point of the client's fault or ignorance costs you the next conversations.

Write the checklist so someone else can run it

Often you can't touch the system yourself. Someone else's IT team has to run the diagnostics.

A checklist that gets run properly follows a few rules.

• Every step produces a specific answer.
• The cheapest tests come first, so nothing expensive happens until it has to.
• Say what each step is for.

Most support escalations I've seen fail not because the diagnosis was wrong, but because the request was ambiguous enough that two people ran two different tests and reported the same word.

What it's actually about

None of this is technical. It's building an accurate picture of a system you can't see, from a description supplied by someone who can only see part of it — and doing it without making them defensive, because sometimes they're the only sensor you have.

I learned the first half of this taking cars apart, where the customer complaint was always "it's making a noise" and never where the noise came from.

The environment changed. The rule didn't: don't mistake symptoms for faults.