What is the best documentation template for MSPs?

Running an MSP without the best documentation templates is severely going to hurt your business as you add on more employees and scale. We have consulted dozens of MSPs about how to improve their systems and structure their helpdesk, and we know that the best documentation for MSPs will include the following.

• Ticketing system note procedures
• Thorough escalation procedures
• Specific details for notes and workflow rules
• Systematization of tasks
• Clear expectations, and specifically how to produce those expectations 

So let us walk you through the tenants of strong documentation if you want to grow the right way. 

Also, feel free to download our FREE TICKET NOTE GUIDE!

MSP documentation must include everything–we mean EVERYTHING! 

MSP documentation must be as detailed as possible to help staff reading it  understand EXACTLY the actions to take in their role. 

For example, when it comes to documentation for the ticketing system, it must be abundantly clear to technicians that no stone can be left unturned with their notes.  

Extra specific pieces of information, such as passwords and IP addresses, help in this regard. We do not recommend writing passwords in ticketing system notes. Link to them in a highly secure system, like IT Glue, where they are stored.

Here are some examples of the meticulous information that needs to be included in your ticket notes:

• Called the client.
• No answer. Left a message on the VM.
• Client missed a scheduled call.
• Emailed the client and did not receive a response.
• Client emailed my personal email. Here’s a copy-and-paste of what they wrote.
• Told the client we will work on the issue and call them back.
• Received authorization from an authorized user to perform a permission change.
• Logged on to a client’s machine remotely.
• Performed maintenance on a machine from the RMM in the background.
• Researched applied this fix from this link: http://www.awesometicketwriter.com/awesomefix
•  Called the client back. Confirmed the issue was fixed.
• TICKET RESOLVED.

As you can see, it’s easy to fulfill the requirements by simply writing the steps that are taken in the course of working on a ticket. Every little action that has been performed needs to be noted on the ticket. This will all help to minimize a back-and-forth discussion about how a ticket was resolved.

For example, if a client complains about your service, you can refer to your ticket notes to avoid a situation where it’s your word against theirs. If a ticket was well-written, you can use it to show how your technician tried to remedy the situation. Ticketing system  notes are great for transparency and accountability. 

MSP documentation must set clear expectations for time tracking 

Time tracking is another area well MSP documentation falls short for technicians. 

A rough guideline of what is expected from our technicians is the following: four lines of ticket notes for every 15 minutes spent. That is the level of resolution of ticket notes that you’re looking for.

 A 23 minute task can be inputted as 30 minutes. This way, there is no micromanagement and no stress for the workers. 

Tracking this way takes less time, as you don’t need to calculate the exact amount of minutes a task has taken. Timesheets get to look neat and tidy at the end of the day, and you can easily highlight tickets where the rounding has not been done properly.

So let’s say one of your technicians is working on a password reset. They can write four brief notes per 15 minutes like the the following:

●      Line 1: User called in. I answered the phone.

●      Line 2: User requested password reset for the account.

●      Line 3: Logged into panel. l reset password.

●      Line 4: Confirmed user was able to log into the system after I reset the password.

That is an example of a 15-minute password reset ticket. They can add a fifth line stating that the ticket was resolved. They don’t have to stick with just four. But we believe it’s a reasonable expectation to have technicians doing at least four things every 15 minutes.

MSP technicians should even track things you probably didn’t think about

Your MSP’s technicians should track all the time that they spend working on a ticket and related documentation, even the less obvious stuff. This includes: 

1. All the time they spend researching a ticket before they call a client.
2. All the time they spend on the phone with a client. 
3. All the time they spend waiting for something to be completed. 
4. All the time they spend updating documentation and ticket notes, as well as time spent writing the ticket notes after a ticket is complete.

This should all be tracked. You should define these expectations in writing so that technicians are clear on how to do their job well. Otherwise you will have to be the nagging mother telling a child to brush their teeth. It’s harder to enforce expectations if you as a manager are inconsistent, resulting in bad customer service for your clients. Don’t be a negligent boss. Don’t let that happen.  

If a technician is on a holiday, and they do receive a call, they can always ask their colleague, “Did you check the ticket?”  

If the colleague says ‘no,’ the tech on vacation can  remind them to always check the ticket notes so that it becomes a habit. 

But if the tech on vacation actually failed to note what they did on a ticket, this creates dysfunction within the company for taking time off for vacation. 

Let’s say that the technician solved an issue last week and wrote in the ticket notes “Called the user. Issue resolved.” 

That doesn’t explain how the issue was solved and what steps were taken to fix it. If the problem arises again, and another tech wants to replicate the fix performed by the tech on holiday, they won’t know how. 

The latter will unfortunately have to take calls while sitting on the beach or in a relaxing hotel when they were trying to relax. This is the cautionary tale of bad ticketing system notes. 

The moral of the story is to write all the details, however mundane they might seem. Here are some policies we suggest for very specific documentation. 

Cite sources for resolved tickets 

Technicians must reference all the knowledge-based articles from Microsoft, forum posts, and elsewhere that helped them fix a ticket. 

It’s debatable however whether those kinds of details should be on internal and external notes. 

Different MSPs have different policies. Some companies want to be transparent about how they solve issues so that clients know what they are being billed for.  

But most MSPs don’t want to bombard clients with emails of technical jargon and restrict that to internal ticket notes. Do what works for your business.

Include links to sensitive information

Avoid putting the following in ticket notes:

1. Passwords
2. Credentials 
3. Documents
4. Card information

Use IT Glue for any sensitive information. All of the passwords, and whatever else is stored there, will have a link that you can put on the ticket. If someone accessing the ticket has an IT Glue account, they can retrieve it. 

Note any documentation changes

Updating documentation is awesome as long as everyone knows about it. Say a technician wrote on a ticket note that they logged in to a client’s computer and they found that their printer IP was 193.168.1.26, not 192.168.1.23 as previously believed.

That tech must write in their ticket notes that they updated the documentation with the new IP,  because:

1. They should be tracking the time that they are performing this task during the time they’re allocating to that ticket. 
2. It shows that the technician is doing their job. 

This helps to leave no doubt that a technician is completing their tasks. 

Get uber specific

Techs completing tasks is great. But what’s even better is when those techs note how they solved an issue. As you can see in the table below, vague notes aren’t as useful later as specific notes are. 

There could be multiple admin passwords and panels and whatever else. Techs should understand that they must put these specifics in the technical notes, especially because it could help someone else who revisits this issue later. 

Strategy for logging as much helpful information as possible

We encourage our technicians to write 5 lines for every 15 minutes. This is a good rule of thumb to guarantee that all information is logged correctly.  Those five lines could look something like this:

• Called the client.
•  Logged onto their machine via RMM.
• Confirmed with the client what the issue is.
• Reproduced the problem.
• Told the client that we will work on the issue and call them back.

 At first, this might feel like a lot of details. But when you incorporate all of the above guidelines, you will find it easier to think of information to include. 

MSPs must incorporate ticketing system note summaries 

We stress to our MSP clients that all tickets need to end with the “ticket summary line,” as we like to call it. This will make the status of a ticket abundantly clear to anyone who looks at it after a technician last touched it. If that technician goes out to lunch, and someone looks at the ticket to answer a status inquiry by a customer, the ticket summary line makes it easy to follow and comment on. 

Every ticket should end in one of the four outcomes below:  

1. TICKET RESOLVED – No further action is required. The resolution has been confirmed with the client or they have been notified that the ticket is complete.
2. NEXT STEPS _________: – You are aware of the next steps which need to be taken. You have written a description of what you plan to do, and have scheduled a fixed or tentative time for these steps to be taken. You have also communicated this to the client.
3. WAITING FOR  _________: – You require someone else to complete an action before you proceed with the next steps. You have described who you are waiting for and what they must do. You have scheduled a tentative time to follow up on the progress of these actions should you have not heard back.
4. ESCALATION REQUIRED: – You cannot complete the ticket due to a limitation in knowledge. You wish to pass the ticket to someone else on the team who may be in a better position to resolve the issue.

By choosing one of these outcomes, the tech makes it easy for anyone else who views the ticket to understand its status, and what, if anything, needs to be done with it. 

So let’s say a manager or a dispatcher is wondering why a ticket is two weeks old. They’re nervous, but then they look at the ticket notes and see that the summary line reads ‘Waiting for Dell monitor to arrive. It was  out of stock, and the pre-order won’t be fulfilled until the 20th.” The manager or dispatcher is immediately put at ease. 

Documentation for escalation is required

Escalations are probably the most crucial place for the best MSP documentation. Ticket notes especially for escalations really need to be handled with care, for more than one person will work on and edit it.

There are so many nuanced situations that make more than one set of eyes reviewing a ticket tricky, such as: 

• A technician doesn’t have the technical knowledge to resolve a ticket and passes it off to someone who can. 
• A technician can’t finish a ticket because they are traveling the next day and won’t be around.
• A tech is missing the documentation and credentials to enter a system. 
• A tech feels that an issue is more business operations related, and they need a manager to step in. 
• A tech is dealing with a prickly client and they think a manager can handle this better.

Making escalations more difficult is that there are more than one type of escalation. There’s the:

1. Live escalation where a technician gets someone else to look at or listen on an issue and the other tech can submit their input.

2. Transfer or handover escalation  where a tech writes ‘Escalation require’ along with very specific ticket notes that detail: 

1. The issue as it stands (25 words or less):
2. Things I have tried to resolve with this ticket:
3. Why I cannot resolve this ticket:
4. Possible Next Steps:
5. Any other info (e.g. callback times):

Whatever the case may be for the escalation, the technician can then escalate the ticket. If your MSP has a dispatcher, they will assign the ticket to someone else. That person will have all the information they need despite having no direct contact with the original ticket assignee. It’s as if their lunch has been packed for them and they’re all ready go!

Looking for remote technicians? Click to learn more about our MSP staffing services!