The Ultimate Guide to Improving Ticketing System Note Writing for MSPs! 

Running an MSP without a ticket system note-taking strategy is a bad idea, and leads to problems for your customer, as well as your technicians. 

Here at Support Adventure, we provide remote staff for MSPs and heavily rely on ticket notes. Most of our technicians work remotely, and the MSP they work for is rarely located in the same country where the engineer works. 

If you want to level up the automation of your help desk operations, you cannot do it without a ticket note strategy.

We’re going to share with you our top tips from our free ticket note guide, which you can get here. 

Now, let’s get started. 

Ticketing System notes play a key role in preventing complaints for your MSP

Ultimately, your MSP is in the business of providing exceptional service to clients. The ticketing system notes that your staff writes must reflect that. Having a well organized ticket handling policy helps clients see that you’re:

1. Doing a good job with resolving tickets within the time they expect them to be finished by. 
2. Fulfilling their requirements for resolving issues. 

Consistency in these two areas will prevent you from receiving angry calls from disappointed clients. 

Tickets must include all relevant information so that:

• Technicians can best assist users.
• Management can be informed about what has transpired with an issue.
• It is clear what steps have been taken to resolve an issue.
• A technician’s performance can be tracked.

Detailed logs help minimize the need for a discussion about how a case was handled. 

MSPs must document EVERYTHING in ticketing system notes!

Ticketing system notes must be as detailed as possible to help those reading them understand what actions your technician took to fix an issue. 

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. 

From a technical perspective, MSPs save a lot of hassle with detailed ticketing system notes

The great thing about ticketing system notes is that they fill other people in and get them up to speed about what has transpired with an issue. This is why MSPs must document as much information as possible that will help others understand what a technician worked on, why, and how they figured out how to do what they did. 

And again, specific pieces of information like passwords, IP addresses and more help other technicians to reproduce a fix for the future. 

Ticket notes also save time if your MSP encourages staff members to go on holiday. Keeping detailed ticketing system notes and documentation of everything is imperative for the enjoying of one’s holiday. When ticket notes are meticulously documented, no one has to ring up the person on vacation to ask them for information. It’s all in system. And the person on holiday can actually step away from their laptop to enjoy the views and sites of their destination. 

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. 

The Value of Specificity

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. 

Ticketing system notes when escalation is required

Ticket notes 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: 
3. The issue as it stands (25 words or less):
4. Things I have tried to resolve with this ticket:
5. Why I cannot resolve this ticket:
6. Possible Next Steps:
7. 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!

Always remember the big picture of ticketing system notes…

Including one of the four statuses as the last line of your ticketing system notes helps create clear understanding about a ticket’s progress or resolution. This also helps establish what needs to happen in order for pending tickets to continue on their road to completion. Knowing when next steps can be taken, and by whom, ensures that tickets don’t become neglected. 

The worst thing for a dispatcher or manager is when they look at a ticket and cannot figure out what is going on. Having one of the four statuses automatically creates notes that paint a picture of what is going on, and helps create automation so you can focus on scaling your MSP.