How Good Service Design Makes for Good Service Level and Expectation Management

In my last article, I discussed why communicating completion targets is perhaps not a good idea and presented some tips for improving how aging tickets are managed.

What I didn’t cover, though, is that because, on average, about 75% of support needs are completed straight-off at first response, and because most of these needs are met before the first response target breaches, good expectations can be set for most support needs.

The problem is, by default, a ticket’s completion target is also communicated. For any level of ticket priority, the completion timeframe is typically configured as being a much longer period. For most tickets, this is misleading misinformation. For ticket types in which completion usually happens straight-off, the completion target must instead be identical to the response target.

As far as I’m aware, the need for this isn’t in our best practice frameworks, and I’ve not joined even one organization that had it in place.

To set it up, one of the most essential requirements for any IT organization must be established: your service catalog and ticket categorization criteria must be well designed and managed. With it, your service portal can be, and must be, easy to use, so that requesters always choose the right service option, and likewise, your service desk will be able to do the same with few mistakes when raising a ticket from a phone call.

Then, mapped to your good service categorization, two additional levels of ticket priority are needed. One is for urgent but low impact needs; the other is for less urgent, single user (low impact) needs that will be completed at the initial response. For both, the response and completion targets are configured as being identical.

If you work to a service level agreement (SLA) that includes performance around ticket response and completion, configuring prioritization in this way will allow you to form an SLA that is far better aligned to the realities of support. Without it, performance measurement lacks relevance because the resolution SLA is gauged largely against completely inappropriate completion targets, targets that anyone would expect to always be met because they're so generous.

Then, an SLA can become even more accurate and reflective of the true nature of support by having service level targets apply only to standard types of support ticket. Separating out “case” management – that is, the work in unravelling unexpected, non-standard support needs that cannot easily be completed – and handling cases separately removes from an SLA the work of an IT department that cannot reasonably be expected for completion within the period that has been contractually agreed. Those who have read Rob England’s recently updated book on this popular subject will already be familiar with it and its importance for good support service management.

The only remaining thing that’s needed to form a wholly accurate SLA that’s reflective of IT support realities in the way that support needs to operate is to accurately exclude on-hold periods. And the only way to achieve this is through consistent, continuous status management.

In an ITSM tool, lifecycle statuses are mapped to whether a ticket at a status is placed on hold or has its on-hold state removed to restart the SLA timer. A way of working that is based on rigorous status management to control when and for how long tickets are placed on hold is just a small adjustment for most IT organizations because IT support teams usually use custom ticket statuses to some degree already.

The need for good status management is also missing from our best practice frameworks. This must change, not only to help bring validity to the resolution SLA but also because it enables improved prioritization to one degree or another.

Many ITSM tools help to fill the gap by providing configuration for status alignment to the on-hold state, but to gain any significant benefit from it and status management more broadly, it is unavoidably necessary to have a full set of carefully thought-out statuses being continuously used in line with your standard operating procedure for support, where whatever the situation a service ticket might find itself in, there is always an appropriate status to select that reflects what must happen next.

This is another aspect that might be missing from your setup because the benefits from doing it well do not appear to have previously been brought forward for the ITSM community to consider. Most IT organizations do add some custom statuses sporadically over time though, because we intrinsically recognize that they help us make sense of support workload.

When used to form a support process of good design, rigorous status management is a breakthrough capability. I have even used the term “silver bullet” before, which is daring because many people quite sensibly do not believe they can exist. Status management does fix the resolution SLA though. It can completely streamline IT support to give experience management practices the boost they need, and it can even introduce accurate expectations management for every service ticket regardless of age, including those that might be designated as a “case” for handling outside of an SLA. If that’s not a “fix-all,” I don’t know what is.