A lot of IT support can be done without physically being in the same place as the user.
I’ve spent plenty of time working remotely, and for a lot of issues that’s exactly what you want. You can look at logs, check device information, investigate Microsoft 365 services, work through Intune or Entra ID and speak to the user without ever leaving your desk.
But working on-site is different.
I’ve regularly been trusted to act as the lead engineer during customer visits, sometimes as the only engineer on-site. Over time, I’ve found that being physically in the environment gives you a different perspective on the work.
You’re not just looking at the ticket anymore.
You’re seeing the environment that the ticket came from.
You see things that aren’t in the ticket#
A ticket is usually a very small description of a much bigger situation.
It might tell me that a user can’t access something, that a device isn’t working or that an application has a problem.
When I’m on-site, I can see what is actually happening around that issue.
I can see where the device is being used, how the user is interacting with it and whether there is anything else going on nearby that might be relevant.
Sometimes it’s something obvious, like a physical issue that wouldn’t be visible remotely. Other times it’s much less obvious. You might notice that several people are having similar problems, or that something about the environment doesn’t quite match what the original ticket suggested.
Those details aren’t always available when you’re working remotely.
People explain problems differently when they’re standing next to you#
I’ve found this particularly useful.
A user might put “Outlook isn’t working” into a ticket, which doesn’t give you much to go on.
When you’re actually sitting beside them, you can ask them to show you what they’re doing.
That’s often when the problem becomes clearer.
You can see the exact point where something goes wrong. You can ask what they were expecting to happen. You can find out whether it has always worked that way or whether something has changed.
It also gives the user a chance to explain the problem in their own words rather than trying to translate it into technical language for a ticket.
That conversation can sometimes tell you more than the original ticket ever could.
Being the engineer on-site changes the responsibility#
When I’m the sole engineer on-site, I’m not simply there to work through a predefined list of tickets.
There might be planned work for the visit, but there will usually be other things that come up as well.
A user might need help with something unexpected. A device might have a problem. Something might need escalating. A piece of work might take longer than expected.
You have to make decisions about what needs attention and what can wait.
That doesn’t mean making every decision yourself. In fact, knowing when something needs to go to another team is just as important.
What I try to do is take responsibility for the issue while I’m there, even if I’m not the person who ultimately fixes it.
If I can’t resolve something on-site, I want the investigation to be useful and the handover to give the next team enough information to continue.
You have to be comfortable working things out#
Being the only engineer on-site also means you don’t always have someone sitting next to you who can immediately give you the answer.
That’s actually something I’ve come to enjoy.
It means I have to think through the problem myself.
What do I know?
What don’t I know?
What can I check?
Is this something I can resolve here?
Does it need another team?
What information will they need if I escalate it?
That doesn’t mean I expect myself to know everything. I don’t.
IT is too broad for that.
Being able to recognise when you don’t know something, investigate it properly and then find the right person or resource is much more useful than pretending you already have the answer.
Site visits also expose the difference between a process and the real world#
This is probably one of the things I’ve found most interesting about being on-site.
A process can look completely reasonable when you read it on paper.
Then you actually have to use it with a real person, in a real environment, with the constraints that happen to exist that day.
That’s when you start noticing things.
Maybe a step isn’t clear. Maybe the documentation is out of date. Maybe there is something happening in the environment that the process doesn’t account for. Maybe the process itself works fine, but the information needed to complete it is difficult to find.
I’ve come across enough of this in my work to become much more interested in documentation and process improvement.
It doesn’t automatically mean the process is bad.
Sometimes it just needs to be made clearer or brought back in line with what is actually happening.
Supporting wider technical and project teams#
Some of the on-site work I’ve been involved in has also meant supporting teams outside of the immediate service desk function.
For example, I’ve supported project teams during customer deployments and other pieces of planned technical work by providing an on-site presence. That can involve readiness checks, helping users, dealing with issues as they appear, carrying out triage and making sure anything that needs further investigation gets back to the right team.
I think there is real value in having someone on-site during this sort of work.
The project team might be responsible for delivering the technical change, but the person on the ground is often the one dealing with the practical reality of what happens when that change meets the users and the environment.
Sometimes everything goes to plan. Sometimes it doesn’t.
When something unexpected comes up, being there means I can investigate it, resolve what I can and provide the project team with useful information about what is actually happening rather than simply passing on a problem.
I’ve found that this kind of work gives me a good appreciation of how different parts of IT need to work together. The service desk, project teams, technical teams and the customer all have their own responsibilities, but ultimately they’re working towards the same outcome.
Sometimes the quickest way to understand a problem is to see it#
I’ve had plenty of situations where investigating something remotely has been enough.
But I’ve also had situations where being there makes the difference.
You can see the setup.
You can talk to the person.
You can reproduce the issue yourself.
You can notice things that wouldn’t necessarily make it into a ticket.
That’s particularly useful when you’re dealing with problems that are difficult to describe.
A user might not know which technical detail is important, and that’s completely understandable. They’re trying to get their work done, not diagnose the issue for me.
Part of my job is working out which details matter.
Being on-site gives me a lot more of those details to work with.
It has changed how I think about support#
I think this is probably the biggest thing I’ve taken from customer site work.
When you’re working remotely, it can be easy to become focused on the ticket and the technology.
Being on-site reminds you that there is always a person and a working environment behind it.
The laptop isn’t just a laptop.
The application isn’t just an application.
If something isn’t working, someone is usually trying to do something with it.
That doesn’t mean you should ignore the technical side. You still need to investigate properly and find the right solution.
But understanding the impact makes the work more meaningful.
It has also made me more interested in the service around the technology#
This connects quite naturally with the service-management learning I’ve been doing.
I’m increasingly interested in what happens around the technical problem.
Why did the issue happen?
Is the process clear?
Does the documentation help?
Was the right information available?
Could something be improved?
Does the person using the service actually get the outcome they need?
I don’t think every site visit needs to turn into a process review. Most of the time, you fix the problem and get on with the day.
But when you start noticing the same gaps or patterns, those observations are useful.
That’s where I think on-site support gives you a perspective that you don’t always get from a service desk queue.
What I’ve learned from being on-site#
Being on-site hasn’t necessarily made me a better engineer because I’ve learned a load of new commands.
It’s helped me become better at understanding the bigger picture.
I have to communicate with users, make decisions, manage competing priorities, investigate problems and know when to involve someone else.
I’ve also learned that taking ownership doesn’t necessarily mean personally fixing everything.
Sometimes ownership means getting the right information, involving the right team and making sure the issue doesn’t simply disappear into another queue.
That’s probably the biggest lesson I’ve taken from being the engineer on-site.
Remote support is incredibly useful, and a huge amount of IT can be done perfectly well from behind a screen.
But sometimes you need to see the environment, talk to the person and experience the service from their side.
That’s when a ticket starts to become something a bit more real.