Are Your Engineers Being Hijacked?

As an IT Solution Provider or Managed Service Provider (MSP) - does this scenario feel familiar at all?

You schedule an engineer to visit a client to deal with an important, but not urgent issue. As the engineer is about to leave the office for the client site, a support ticket comes in from a different client. You decide that, as the new support ticket is for a relatively small and quickly fixed matter, and as the second clients site is on-route to your engineers scheduled site visit, he may as well pop in to resolve that on the way.

So your engineer heads off to his two site visits. No big deal, right?

Then, hours later, the client your engineer was originally supposed to visit phones you and asks “Where is my engineer?”.

Apparently, he’s not arrived for his scheduled appointment.

Sorry boss, I’ve been Hijacked!

You call your engineer to find out his whereabouts, and discover he’s still on-site at the client he “popped in” to see. Surely that small support ticket didn’t take this long to resolve?

Well, no - but your engineer explains that while he was there, he got a tap on the shoulder asking if he could quickly take a look at the issue of a scanner not e-mailing documents the way it should. Then, while he was looking at that issue, another client employee asked him if he could turn down the brightness on his monitor. While he was doing that, a Manager asked him if he could move his printer to another office and… it goes on.

Your engineer has been hijacked, and as a result - you have to ask another engineer to drop what he is doing and head off to deal with the originally scheduled and important, and now urgent site visit to placate the client who has been stood up. You may even need to drop what you are doing yourself to go and smooth things over with the client.

Where does the fault lie?

It’s frustrating. But where does the fault lie?

Is it the engineers fault, who knew he was scheduled for another site visit but didn’t want to say no to the client who had lots of other requests?

Is it the client, who should have respected the engineers time and not asked him to deal with non-urgent issues?

Or is it your fault, for not setting the clients expectations, or making sure the engineer understood his responsibilities for the day?

Let’s look at all three points of view.

From the engineers viewpoint, he was put in a difficult situation. Engineers are, by their very nature, programmed to help people. They find it difficult to ignore requests for help. They get a buzz off being seen as the “hero”, fixing issues and enjoying recognition.

From the clients perspective, they’ll never remember to, or wouldn’t want to bother you by logging tickets for low-priority issues like monitor brightness or printer moves. They just figure that they’ll grab an engineer the next time he comes out. If an engineer is on-site, then his focus is on them, right?

From your point of view, you expected the engineer to stick to his schedule - and didn’t feel you needed to spell out that fact.

How to deal with Hijackings!

So how can you avoid this type of scenario going forwards?

How can you ensure that everyone does what they are supposed to do, with the clients getting the service they expect?

Firstly, you need to set the clients expectation. All those niggling low priority issues like monitor brightness and printer moves? You can encourage your client to log them, but they’ll still forget or be reluctant to bother you. Those issues won’t go away though - and your engineer will still get the tap on the shoulder the next time he visits the client. So build time in to mop up those issues. Schedule regular site visits to client sites to “floor walk” - an engineer walking around to chat with people and to ask if he can help. You’d be surprised how many issue he’ll uncover and mop up. You might even uncover some sales opportunities too.

Then you need to help them engineer what to do the next time he gets a tap on the shoulder. Instead of saying “Yes, I can do that!” the engineer should ask if the issue is urgent. If the client says it isn’t, then explain to the shoulder tapper that he’s been scheduled to visit another client so will be struggling for time - but that now that he knows about the issue he’ll be in touch before the end of the day to schedule a return visit (that return visit can also incorporate the floor-walking session we mentioned earlier).

If the issue *is* urgent (or the client pretends that it is in the hope of getting attention) then the engineer should politely say he’ll call the Helpdesk now so a colleague can help with the issue. The engineer rings the Helpdesk, explains the problem, then hands the ‘phone over to the client who takes down the details. If the problem is genuinely urgent, then the Helpdesk can dispatch another engineer. If it’s not, a site visit is scheduled for within the next few days (which will also incorporate the floor-walking session we mentioned earlier).

The results

In either scenario, your engineer has the pressure of saying “No” to the client taken off his shoulders, and the client has their expectations set accordingly.

Once you start performing regular “floor walking” visits to mop up non-urgent issues, you’ll find clients will be ok with hearing the engineer hasn’t got time right now, but will return at a later date. They know that the engineer isn’t fobbing them off.

I know both from experience of being an MSP owner, and of providing help for IT companies that running a Service Desk isn’t easy. It requires juggling lots of challenges, and keeping multiple people happy. But by implementing some strategies that can set both clients and engineers expectations - you can make life a lot easier for all concerned.
 

As the former owner of an award winning IT Managed Service Provider, Richard Tubb works with MSPs to help them increase sales, take on employees and build up relationships with key industry contacts. You don't have to do it alone any more - contact Richard and have a chat about your needs and how he can help you.

Follow Richard Tubb on Google+ and for more news and advice for MSPs subscribe to Tubblog.