Friday, August 26, 2011

SOP Friday: How Do Service Requests Get Into Your System?

The last several SOP Fridays have been about your ticketing system or PSA (professional services automation) system. This week we'll talk about how things get "into" your system. Next week we'll talk about massaging the job board.
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! When I speak, I make the point that 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.

- Overview -

In the days of break/fix, things generally got into your system 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 need to figure out how they translate into ticket in the system. It is critical that every request or task get into your PSA system. Please review the blog post Working In Real Time.

I 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 add 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

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


Notice that this chart includes the process we discussed in the post on Service Ticket Updates

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.

For 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 email to support@yourcompany.com (We use EmailtoAT by MSPintegrations).

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 the most important requirement to getting support. Second, the PSA system will page someone. Either the service manager, the service coordinator, or the person responsible for monitoring the board. Someone will actually get a page, 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.

As you've seen over the last several posts, there's a flow to managing tickets. You caress them you. 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.

Next time we'll talk about massaging the service board to maximize effectiveness.


Your Comments Welcome.

- - - - -

About this Series

SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.

Find out more about the series, and view the complete "table of contents" for SOP Friday at http://www.smallbizthoughts.com/events/SOPFriday.html.

- - - - -

Next week's topic: Massaging the Service Board

:-)

Check Out the #1 ranked Managed Services book at Amazon:

Managed Services in A Mont: Build a Successful IT Service Business in 30 Days!
by Karl W. Palachuk

2nd Edition - Newly Revised and Updated with NINE new chapters

Paperback - Ebook - Audio Book

Order Managed Services in a Month NOW for only $24.95.

Order Today!

6 comments:

  1. Do you have a service that answers calls if no one picks up? How do they relay this info to you? If we miss a call the client gets a voice mail that all techs are busy. Our voice mail sends the mp3 into our ticketing system.

    Is the person answering your phones in a "dispatch" position?

    BTW, SOP Fridays is an excellent series!

    ReplyDelete
  2. Thanks for the questions, Kurt.

    Our phone flow is to admin, then the tech on call for the day, then his cell phone. If no one answers, the voicemail gives instructions to enter a ticket or leave voicemail.

    We don't have voicemail send mp3, although we could.

    We DO use email2at from MSP Integrations (http://email2at.com/). That way all emails to the support mailbox are scanned for client info and automatically create tickets with the correct info.

    Most of the time, the person answering our phone is the office manager. She creates tickets but does not do dispatch. When a ticket is created, the tech on call for the day receives a page (SMS Text) with ticket info. He handles dispatch.

    Thanks for reading!

    ReplyDelete
  3. Curious to know more about your 'tech on call' process... have often wondered about this but hearing about someone else's use legitimizes the idea (makes me realize that I'm not crazy for wanting to do it after all... lol).

    ReplyDelete
  4. Thanks, Schyler.

    Stay tuned.

    :-)

    ReplyDelete
  5. How do your clients feel about the "ticket first" process when a major outage occurs example: the file server for the entire office is dead.

    ReplyDelete
  6. Emergency situations are no exception. One of my favorite phrases is Slow Down, Get More Done. In this case, that means that you take two minutes to create a ticket - and populate it with the useful information. When did the outage start? Who called it in? Is the server making noise? Is the UPS making noise? etc.

    The service ticket will be used to coordinate and document everything related to this incident. So it has to exist before work is done.

    If you have managed services, you must have a ticket in order to track time and determine profitability.

    If you don't have managed service, you must have a bucket that clients can put money in to pay you. That bucket is called a service ticket.

    In any case, you need to track what was done to help the client, and the order in which things were done. For that you need a ticket. You should also have a TSR Log (see http://blog.smallbizthoughts.com/2011/07/sop-friday-troubleshooting-and-repair.html).

    If you use the system 90% of the time, you have 90% of a system.

    That's my opinion.

    ReplyDelete

Feedback Welcome

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

Disagreements welcome!