What the help desk taught me about automation

The help desk is the only place in an organisation where you see every process fail, from the outside, in the user's own words.

I did not start in continuous improvement. I started answering tickets, rebuilding machines, chasing network faults and administering systems that other people depended on to get through their day. For a long time I thought of that as the part of my career that came before the interesting part.

I was wrong about that. The help desk is the only seat in an organisation where you watch every process fail, from the outside, described in the user's own words rather than the process owner's. That is an unusual vantage point, and most people who design automation have never had it.

You see the same ticket a hundred times

Support work is repetitive in a very specific way. The same class of problem arrives again and again, wearing slightly different clothes. After a while you stop reading each ticket as an individual incident and start seeing the shape behind it.

That shape is almost never a technology failure. It is a process that assumes something which is not reliably true. A file will be in the right folder. A person will remember to update a list. A permission will have been granted when someone joined. The system works exactly as designed, and the design assumed a level of consistency that human beings under time pressure do not supply.

This is the same failure mode that kills automations. A flow that assumes a well-formed input will run beautifully in testing and fall over in week three, for exactly the reason a support ticket would have predicted.

Users do not experience systems

The most useful thing support taught me is that people do not experience your architecture. They experience whether the thing they needed to happen, happened.

Nobody has ever thanked me for a well-structured SharePoint permission model. They have thanked me because the document they needed was there when they looked for it. The model was how I delivered that, but it was never the point, and if I had confused the two I would have built something elegant that nobody could use.

Users do not experience systems. They experience outcomes. Automation teams forget this more often than support teams do.

Documentation is a support decision

In support you learn quickly that undocumented knowledge is a liability with your name on it. If you are the only person who knows how something works, you are not valuable, you are a single point of failure, and you will be interrupted on leave.

I carried that into automation work directly. Every solution I build gets written down properly, in a form somebody else can pick up. Not because a governance framework asks for it, though it does, but because I have been the person on the other end of a system nobody documented, trying to work out what it was supposed to do.

Training is part of the build

Rolling out Microsoft 365 and SharePoint to a user base taught me that the configuration is finished long before the teaching is. You can have the environment correct, permissions clean, structure sensible, and adoption can still fail because nobody showed people what changed and why it was better for them.

Automation has exactly the same problem, with an extra edge: an automation changes someone's job. If the change arrives without explanation, it does not read as help. It reads as something being done to them, and people are very good at quietly routing around systems they did not agree to.

Troubleshooting is a method, not a talent

Support also gave me a diagnostic habit that I still use on automation failures. Establish what changed. Establish what is actually true rather than what is reported. Halve the problem space, then halve it again. Resist the first plausible explanation, because the first plausible explanation is usually the one that fits the symptom rather than the cause.

That discipline transfers directly. When an automation fails intermittently, the temptation is to add a retry and move on. Sometimes a retry is correct. Often it is a way of hiding a race condition or an upstream data problem that will surface again later, in a less convenient place, with more history behind it.

Security and vendors teach the same lesson twice

Two other parts of that work turned out to matter more than I expected. Keeping an estate patched, monitored and audit-ready teaches you that the unglamorous routine is the whole job — you are judged on the incidents that did not happen, which means documentation is the only evidence you ever get. And negotiating with vendors against exact technical specifications teaches you to write requirements precisely, because anything ambiguous will be interpreted in the supplier's favour.

Both of those show up constantly in automation. A vague requirement produces a solution that technically satisfies it. An undocumented control produces an audit finding regardless of how well it actually worked.

What actually transferred

• Assume the input will be malformed, because in support you saw that it always is.
• Design for the failure path first. It runs more often than anyone budgets for.
• Write it down while you still remember why you made the decision.
• Talk to the person doing the work, not only the person who owns the process.
• Measure whether the outcome improved, not whether the system ran.

The move from support into automation felt like a change of career at the time. It was not. It was the same job with a wider remit — I stopped fixing the instance in front of me and started asking why the instance kept arriving.