Great (or at least Good Enough) Expectations

On my way into work several weeks ago, I saw the ominous orange DOT sign stating: "Road Closed Starting April 28". This happens to be on a critical part of my daily commute, and I work in the boonies. I wasn't at all sure what my detour options would be. While it was helpful to get some advance notice that I needed to find an alternate route, there was a critical piece of information missing: How long will the road be closed? One day? One week? One month? The duration of the road closure would make a big difference in the effort I put into finding an alternate option. DOT change management appeared to be lacking much customer focus.

I'd contend that this is the way most IT shops handle incidents, and frequently problems as well. We've matured our incident management so that all issues are logged, categorized, diagnosed, basic repair steps taken, and the incident properly prioritized and dispatched to the appropriate work queue. We may have even started auto-emailing the requesting customer so they have a reference for their request.

These steps are all great. They help us in IT understand the issue and how to prioritize it against the other things on which we work. It helps us restore, as quickly as possible, the customer's ability to work. Ah, there's the rub. "As quickly as possible". ASAP. Sev 1. Blah blah blah.

When I'm experiencing a service interruption, whether it be with cable TV or road construction, the one phrase I hate to hear is "as soon as possible". As in, "We're working to restore your service as soon as possible". As consumers of services, don't we assume all interruptions are resolved as soon as possible? That's the baseline assumption. It doesn't, however, help me plan my alternate commute route. Or whether I should head to the local bar & grill to watch the Twins game. Or whether I should start working on another task instead of waiting for Desktop Support to show up and fix my problem.

Bad news is better than no news. That's the mantra my team hears from me at least weekly. From your customer's perspective, "ASAP" is the equivalent of "when I get around to it". The customer has to know what to expect.  Here are a few tips for setting communication and resolution expectations. Feel free to add your own.

1. Publish throughout the organization how you determine incident priorities. This doesn't need to be complex. If anything, aim for simplicity. You want it to be read and understood by a lot of people, most of whom don't care about IT processes. Even a little. A starter sample can be found here: ITTicketPrioritization_Sample. This is an example only, and your criteria for determining priority will be different than mine. The point is something simple.


2. When publishing the determination of priorities, it is also critical to include what the customer can expect. Once again, my sample document shows a simple way to do this. It can become a lot more fancy, just make sure it is easy to understand. Feel free to include other elements of expectations. Some ideas include:
   
   
   
   • Expected response time
   
   
   • Expected effort until resolution
   
   
   • Expected resolution goal
   
   
   • Communication expectations, such as the maximum expected time between updates


3. Resist all temptation to include expectations that cannot be measured. If you don't have the means to accurately measure time to respond to email, don't include it in your expectations. Saying "our goal is to respond to every email in 30 minutes or less" when you can't measure that, is no better than saying ASAP. It has no meaning.


4. Use your ticketing system to send out an email to the requester automatically whenever a new incident is logged. The only exception is when the issue is closed at first contact (Then they'll just receive the ticket-closed notification). The email should contain the ticket number and title/short description, the priority of the ticket, and the expected next response and resolution times based on the priority, based on the expectations you already published. You may have different ways to identify expected response and resolution times. The critical part is to set the expectation immediately.


5. The initial message should include how the requester can have the ticket priority "bumped" if needed. I know its scary to give the user this much power, but this is about communication and transparency. You'll be amazed to see how many tickets don't get bumped via user request. The point is to give the requester control.


6. As the ticket is worked through "the system", the goal is transparency and engagement. Give the requester every opportunity to see their ticket status and provide input. Our ticket system is pretty limited in its ability to automate status update communication, but it can email an update as requested. I'd like to see an ITSM tool that allowed users to self-select how much updating and what types of updates they want to receive.


7. Meeting the defined expectations is important. Just as important, however, is updating the requester when the expectations will not be met. This is the "Bad news is better than no news" stage. Do not let automation replace human contact here. This is a whole new paradigm for many support techs; however, they simply MUST make the shift to ensure that user communication is prioritized.

These are just a few ideas. The point is in setting expectations, and finding as many ways as you can to communicate those expectations, especially while a ticket is being worked. After all, when was the last time you praised the efforts of road construction planners? Don't setup your IT team to get the same bad rap.