technician on phone with customer using a support guide to improve resolution time

Building Guides to Improve Resolution Time

“Our internet is down!” is a common refrain from just about any customers that you might manage the technology for. When your goal is to improve resolution time, this is probably a low hanging fruit. The bigger challenge is when you have technicians with different backgrounds and skillsets. When your business is starting up or in growth, you might not have entire teams dedicated to one discipline. You need to try and normalize the approach by everyone.

Inconsistent Approach = Frustrated Clients

We had a very small team starting out. One was a network wizard; another was ok at LAN networking but not super at anything outside the firewall. The other was a hardware break-fix person only. Networking was not well-learned.

When someone would call with a network issue, we would of course try to get the best person on the phone for the job. Sometimes they were unavailable, and another team member had to dig in. It might take a bit longer but typically the issue was resolved. There were occasions that it had to be escalated, and the fix might have come quickly. The complaints then started to mount that our hardware person was incompetent and should not be there. Customers wouldn’t even talk to them for things they really did well.

The belief was since networking was a “computer thing” and the hardware person wasn’t the best at it, they must not be good enough. This was not the case at all, and we needed something to help morale and improve resolution time.

Increased Training & Shadowing

We decided to pair the lesser-skilled individual with the network guru on a few jobs. We spent some time whiteboarding real-world scenarios. After a ticket was completed, we went to the whiteboard and diagrammed out the network. We showed what key points were tested to diagnose the issue and how the troubleshooting helped lead to a resolution.

We’d also found the person some online training. There are actually a few free resources out there to allow your staff to get some training. These were mostly labs, so the environments weren’t as unique as some clients so while we got some decent theory in, the practice was lower value.

This was helpful, but since we were small, time and cost were an issue. Complaints lessened, but we still had a problem we’d only halfway addressed. Morale didn’t get improved either, so there was some dissatisfaction all around. We needed something a little more quickly actionable and could scale.

Building a Guide

I am a big fan of documentation of process. If you can document a process, you can delegate the work. From the first point of hiring someone, my business coach advised me to document everything I do. Note the time, and the steps to accomplish the tasks. When it comes time to hire, you will have a set of expectations and procedures to enable the employee to excel.

This was going to be the plan, and it needed to be a team effort. We all had different approaches to network troubleshooting, so we shared our combined thoughts. This was a valuable experience. We could find some tips to adopt or change to improve resolution time.


The first thing we added was the triage part, as we needed to understand from the customer how severe the issue was. Was it the internet or just the local network? What services were not working? Was there anyone else having the same issue?


The next included some more specific steps of diagnosis like pinging different resources to see if they were accessible. We included many steps to help isolate the issue even further. Using our remote tools and other tests, we could narrow the issue down more quickly.

Unique Factors

The last part of the process might have specifics unique to clients. They might have unique devices in the environment which impact network operation. Any notes specific to those were included.


From all the data collected and a working theory on the cause, the technician had steps to follow. If it required an on-site visit, there was a path to escalate that to the network person if need be. If it was workstation hardware someone was identified for that. Lastly, and most important, advice on what to tell the client about what is happening. Then share what our next steps are.

Improved Resolution Time

The first few calls implementing this new procedure were not entirely smooth. We found a few wrinkles with the steps and order of operations, but those did not take long to fix. We would get back tother and discuss what happened and adjusted.

It was not long before the requests for specific technicians stopped. The hum of everything working as it should and clients being satisfied with results was music to my ears! The extra bonus to all this hard work is we now had a procedure that we could hand to a new hire. They get the benefit of our combined knowledge on networking diagnosis, and guidance on unique client needs.

This article on Network Diagnostics Improve Resolution Time is something that really helped my business out a lot in the early days as an MSP Startup. I think the practice of creating customer support guides is critical to helping clients consistently and successfully. If you need some help creating a guide for your business, I’m more than happy to help you!

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.