The notes and time entries in your ticketing system are perhaps the most important documentation that exists within your MSP business. They are the key to solving problems, defending your billing, justifying payroll and much more. This means, you need to define some standard procedures for entering service notes (time entries) to make sure you get them right every time.
In a sense, your ticketing system/CRM is a massive asynchronous communications system. If you work in real time (see my previous blog Are you accurately keeping track of your time?), the service board will always reflect the exact state of your service delivery. You'll be able to watch tickets open, close and all the statuses in between.
Here are the key things a technician needs to do with each time entry (case note):
The first thing the tech needs to do is to verify that the key fields on the ticket are still accurate. Is it the right description, in the right queue, with the correct status, etc.?
These are notes that would be visible to the client either on an invoice or in a report. The client may never read these. Sometimes I think no client ever reads these. Then I get a client complaining because she didn't get a report last month. So she expects one, even if she doesn't read it.
The point is: A client might see these notes.
Whether or not the client sees the notes, the service manager will. So they should be good. Talk about what you did and focus on the fix, not the road that got you there. The notes should be as minimal as possible, but enough to justify the billing.
But sometimes it's useful to have direct communications between the tech in the field and the service manager. Appropriate notes might be: "This printer grabs a new IP address all the time. We should either hard code it or figure out what's going on with DHCP." Inappropriate: "Client is stupid. We've shown her how to do this four or five times."
Treat internal notes like Facebook. Assume it's private right now. But also assume that one day everything you type here will be indexed and widely available. So keep it professional and constructive.
Your company should have a policy about the time increments you use (e.g., 15 minutes) and time entries should be consistent with that.
There's a key item we like to see on every ticket that is not closed: "What is the next step?" or WITNS. There are lots of reasons why tickets do not close. It is 5pm and you'll be back in the morning; you're waiting on parts; you've passed the issue to sales; you're waiting on a vendor; you've done what you can do and you need to escalate; etc.
When a ticket does not close for whatever reason, the tech should give some guidance to the next person who will open that ticket. Do we need to schedule a memory test? Does the sales manager need to talk to the client? Are we waiting on parts?
A great example involves going through a New PC checklist. If a tech finished half the job and goes to lunch, where can I pick up that job and finish with as little re-work as possible? WITNS tells me that information.
Every time entry – whether the case is closed or not – should end with the phrase “Documented Work.” This means three things within your company: First, it means the tech put these notes into the system before leaving the client's office. Second, it means the technician is working in real time. Third, it means that all relevant information has been entered into the appropriate documentation. This might be paper documentation onsite, documentation online (such as a SharePoint site), in the CRM, or simply in the case notes.
I have no idea what it means to the client. But it sounds good.
If you've never taken time entries (case notes) seriously before, you should. They are a critical element of communication. They require a certain level of precision. And they are a good way to make sure that the service manager is tuned in to what's going on at the client's office.
Imagine the telephone conversation when the service manager has no knowledge of a service request, but he can bring up the case notes and understand exactly what went on. That allows him to have a productive conversation with the client and sound like he DOES know what's going on with the network.
As always, you don't need to do things exactly this way. But you should do them very consistently and systematically within your service department.
Summing up this blog in three points:
(Used with permission of Karl W. Palachuk, SmallBizThoughts.com)
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.