Wednesday, March 17, 2010

Service Request Basics

I had a conversation the other day with a partner who was trying to figure out how to get started with his ticketing system. He just happens to use Autotask, so he called me. It could just as well be ConnectWise or Tigerpaw.

I can't say we necessarily do this "The Right Way" but we have a system that works for us. If you want a bunch more perspective with a bunch of examples and details, you'll need to read Erick Simpson's NOC Book.

We use the ticketing system to work our process. So, really, this part hasn't changed at all between ConnectWise and Autotask, we just click on different things in a different order.

What's Not in the Ticketing System

Perhaps the most important part of our ticketing process is that We don't have a help desk. What does that mean? It means there's no one on our staff whose job is to sit around waiting to be interrupted and do whatever the next phone caller wants. We've never had that. We might some day. But today our process looks like this:

- Phone rings simultaneously on three non-technical desktops. If none of these three answers the phone it rolls to the tech dept.

- Only one person is allowed to answer the phone in the tech dept each day. If that person is not available for some reason (working on something else, on the phone, out to lunch), then the call rolls to voice mail.

- If any of these people catch the call and it's a client with a problem, they determine whether the problem is old (existing Service Request) or new. If new, whoever answered the phone creates an SR. If old, call is transferred cold to the tech dept or specific tech.

There are only two goals for answering the phone. First, clients want to talk to a human even if they won't get help right away. We've educated them on efficiency and "the system" but they are people who want to talk to people. So even though it's faster to enter an SR online, they want the human contact. The second goal for answering the phone is to create an SR. Period. Not work it. Create it.

I've used this analogy before: The Service Request is a bucket into which a client can put money. If there's no bucket, there can't be any money. Therefore, creating the SR is more important to our business than almost anything else. It's the only way a technician can log time. It's the only way a technician can get paid. It's the only way a client's problem can be solved. It's everything. Creating this ticket is just about the most important thing that happens in our company. Sales is first.

For some reason, many people get stuck right here. They can't figure out how to get this part done - how to make sure an SR is created first. I don't know how to help you except to say just do it. Create a rule. Make a sign. Berate people. Ask every employee on every issue "Is there a service request?"

This simple rule will make or save you thousands of dollars. Every month. Really, really, really. Just do it.

What's In the Ticketing System

Once a ticket (SR) exists, the rest of the process can come into play.

Whether an SR is created by the office manager or a client, the same things happen . . .

- The ticket is created in the Client Access Queue

- The ticket has a "normal" priority, which for us is 3 - Medium

- The ticket has a status of "new"

- The ticket is assigned to the default (managed service) contract. In other words it is assumed to be "covered" unless there's a reason it shouldn't be.

- A time estimate is entered. This allows us to speculate about how much work we still have in the system.

Each of these elements is important to the overall success of the system. In addition, if you can collect the Issue Type and Sub-Type, that can be very handy.

The Flow . . .

So now the ticket exists, it is in a status of New, it is in the Client Access Queue.

One technician each day (same one who answers phones) has the job of monitoring the new tickets. Nothing can stay new for very long. New tickets send pages to cell phones and poke people in the butt. This is done for a reason: We can't miss a new ticket. It might be critical and not just normal. But no matter how normal it is, we can't miss it!

Anyway, so the ticket exists and is now in the tech dept. The tech catching call/SRs then looks at the ticket and verifies or makes the following changes . . .

- Acknowledge the Ticket. This includes an email to the client as well as checking data entry and making sure the ticket is properly prepared to work it's way through the system. Change status to acknowledged.

- Is the Priority correct? I discuss priorities in my Service Agreements Book and in my Managed Services in a Month so I won't go into detail here.

Suffice it to say that the right priority makes a difference.

- Move the SR to the correct Queue. The SR will probably move to the Tech I Queue so it can be worked by technicians.

- Verify the work to be done. This includes verifying the work type and sub-type, which will help greatly to determine whether the priority, time estimate, and contract (billability) are correct.

- Make sure the ticket title/short description is descriptive. The ticket title should be about 5-7 words on what needs to be done. "Jay's printer" is a bad title. "Jay can't print on HP3600" is a better title.

- Verify time estimate

- Verify contract / billability

If additional information is needed, the technician may contact the client and ask some questions or get clarification on something that was entered into the ticket. Again, he's probably not working the ticket at this time.

When all these items are complete, the ticket status is moved to "Schedule This."

In our business, that's the sign that a ticket is ready to be worked. We have a sense of priority, we actually know what we're doing, we know it's in the right bucket with regard to covered vs. billable. Now we can make money!

Despite the fact that I give a lot of detail here, this entire process is extremely fast. Probably no more than five minutes for whoever created the ticket and five minutes for the technician. Don't be overwhelmed by the details.

If you're just starting out, take a screen shot of your New Ticket entry form and highlight in yellow the key fields:

- Title
- Status
- Priority
- Queue
- Time Estimate
- Issue Type/sub-type
- Contract / billability

Working the Ticket

This is a whole different topic, but I'll give you the view from 30,000 feet. We work all tickets from highest priority to lowest priority, and from oldest to newest. That means that at any given time a technician can look in the queue and pick out any ticket that has a status of "schedule this" and then simply grab the highest priority ticket.

There are almost never "priority one" tickets. These are true emergencies. So let's look at P2 or "high" priority. If there are three P2 tickets, you'll work the oldest one. Period. It's that simple. When you've moved that as far as you can you'll refresh the list and take the next-oldest P2. And so forth.

So you see why we don't have a help desk? A help desk is an inefficient, interrupt-driven process. It is a disorganized operation intended to make you feel like you're giving good service when you're really doing your clients a disservice because you're working on low-priority tickets instead of high-priority tickets.

In my opinion, all work in your life and your business should be based on priorities. You want to be super successful? Always work on the highest priority thing you have. Period. Throw away your calendars and schedules. If everyone in your company is always focused on the highest priority items you will be amazingly productive.

The only downside to this model is that you will have long periods in which your technicians will have nothing to do. Our company frequently has periods with fewer than a dozen service requests in the entire system. So we've got three full time techs and a couple of part timers with nothing to do except play with new software and polish their monitors. There are lots of reasons for this, but working everything in priority order is a major piece of it.

Oh, and one final note on help desk . . .

We never have client complaints about this. Maybe they think we DO have a help desk. Maybe we're so darned efficient that we always get back to them in a timely manner. Maybe we've set expectations properly. I don't know. But it just works.

My two cents.


Join Karl for a Zero Downtime Migration Seminar

New Orleans, March 17th
- - Join us today!

Miami, FL, April 17th


  1. Technicians downtime is costly and lowers profit margins unless they are productive in some other way such as going through training, maintaining your own systems, working in your lab testing new hardware/software/concepts that can be implement with clients, etc. Without these things to do, maybe one less tech is needed?

  2. We are over staffed at the moment. But we are also on the verge of signing three new clients. It is a pleasure to be able to ramp up the talent before it becomes critically needed.


Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!