How do service requests get into your system?

Karl Palachuk

In the old days of break/fix computer support, "jobs" got into your "system" by any way a client could get your attention. This was generally fine, but a lot of jobs didn't get your attention until they were emergencies. So you spent a lot of time putting out fires.

With modern tools, we have more (and better) ways for requests to get into your system and you HAVE a system! Your system should be designed so that nothing gets lost, dropped, or forgotten. The most important piece of that process is getting every request or task INTO your system.

In the old days, jobs would generally come through to you by one of these methods:

  • Phone call
  • Client interaction (conversation or shoulder tap)
  • Client email
  • Technician discovers an issue

We still have all those things, of course, but you now need to figure out how they translate into tickets in your system. It is critical that every request or task gets into your PSA system.

ticketI know it can be overwhelming to have hundreds or thousands of tickets and tasks in your system. But this is really good news. It means you know the limits of the workload in front of you. You know how high it is and how wide it is. You know how many hours you expect to get "caught up" on the work. It is good!

In addition to the old, break/fix methods, we'll have a few simple additions:

  • Client enters a ticket into the portal
  • Client emails a ticket into the system
  • Ticket is generated by the RMM (remote monitoring and management) tool
  • Ticket is generated by your staff
  • Ticket is generated by your back office support team

Create a Flow Chart

Below is a simple flow chart that includes some of the methods discussed here. You can easily create your own in Visio (or even PowerPoint).

chart

Once everyone in your business understands the flow of incoming tickets, then they can be more efficient. And they will understand why you need to push clients to create their own tickets.

When you talk to a client about an issue, the words to use are: "Do you want to enter a service ticket, or shall I?" In other words, offer to do it, but make it clear that it's really their job. You should also be clear that you can't do any work except on a service ticket.

Whether it's billable or covered by a managed service agreement, a ticket is the place where you keep note, track employee time, track the status of the issue, and document when the work is complete. It is the center of what you do on the service delivery side. So ya gotta have a ticket.

callFor some reason, clients want to pick up the phone and instantly talk to the highest level technician, interrupt whatever that tech is doing, and have their problem solved. That's not the way the world works. That's interrupt-driven break/fix. We sell managed services.

Train your staff to enter tickets in the system. All work must be done from a service ticket. Ideally, the person who answers the phone won't be a technician, so all they can do is enter tickets.

One of the key selling points of a PSA system is that you'll be able to generate reports to tell you how much time you actually spend on each client and each issue. In order to do that, you need a ticket for everything and you need to log time correctly.

Train your clients to use the client service portal or send emails to [email protected] All PSA systems either accept tickets by email or work with third-party applications that convert email to service tickets.

Clients need to know that entering a ticket in the system is the fastest way to get support. First, it creates a ticket, which is the most important requirement to getting support. Second, the PSA system will text or alert someone – either the service manager, the service coordinator, or the person responsible for monitoring the board. Someone will actually get a text message, an email, or both.

Calling, however, can only result in the conversation: "Do you want to enter a service ticket, or shall I?" It is one step prior to creating a ticket.

Implementation Notes

This Standard Operating Procedure is really 50% documentation and 50% implementation. First, you need to document all the ways that tickets get into your system. Then you need to figure out the flow that moves them from the introduction stage to the actual service department. In the diagram example, it is only after the "Coordinator Process" that work can actually be done on a ticket.

After you define your process, you need to train your staff and make sure they all understand that this is how things will flow. Next, you need to train your clients and assure them that the ticketing system is the fastest way to solve their problems.

Finally, you need to enforce this. Don't let technicians work without a ticket. Don't let clients call up and interrupt you.

There's a flow to managing tickets. You caress them. You massage them. You group them together and manage them. You push them gently through the system. Always moving forward. Always moving in the right direction. The system works because it is a system. It's not a disorganized collection of activity motivated by the last request you received.

Three Take-Aways from this blog:

  1. Document every possible way for tickets to get into your system. Which of these do you prefer?
  2. Create a preferred process. Then train employees and train clients.
  3. Make sure you create a diagram of this flow and use it to train new technicians. Maybe even post it on the wall.

(Used with permission of Karl W. Palachuk, SmallBizThoughts.com)