How to provide top-notch IT service that your customers will love

Download our free white paper: ITSM ‘Back To Basics’ Might Not Be What You Expect and learn the basics every IT organization needs for success.

Basics for IT service success

The tools to better understand what your customers want now
How to establish reasonable and realistic expectations, so customers know what you will deliver.
Continuously improving everything you do, moving toward a culture of continual improvement.

Receive a free copy of our white paper

IT Service  
Back to Basics” Might Not Be What You Expect  
By Stuart Rance  
ITSM and security consultant  
We all think we know what we mean when we talk about “getting back to basics” in IT service  
management (ITSM), but when my friends at SysAid asked me to write about the topic I made  
a rather surprising discovery. My immediate reaction was that of course I would need to explain  
the common ITSM processes, incident management and change management for example. But  
once I began to really think about it, I found myself writing about something different. I realized  
that I have seen many organizations with great technical and process expertise fail to deliver  
great customer value. This told me that to find the basics, the things every IT organization must  
do well, I needed to look elsewhere.  
If you want to provide your customer with an IT service that they love, then you need to do  
five things:  
Understand what your customers want now  
Set reasonable and realistic expectations  
Meet the expectations you have set and be seen to meet them  
Plan how you will exceed expectations in the future  
Anticipate what your customers may want next  
Read on to find out if you agree with me.  
Say What You’ll Do,  
Then Do What You Said  
Many years ago I worked for a large international company. One day I was using my Unix  
workstation and my mouse stopped working, so I dialed the phone number for what everyone  
in the company called the helpless desk and told them my mouse was broken. “No problem,”  
said the help desk agent, “We’ll put a new mouse in the post to you. When it arrives, swap it  
for your faulty mouse, and send the broken one back to us in the same box.” This sounded  
like a reasonable solution to me, but I needed to work that afternoon, so I turned to my  
colleague at the next desk, who always had lots of spare hardware lying around, and asked,  
“Can I borrow a mouse for a couple of days, please Dave?” Dave lent me a spare mouse, and  
I connected it to my workstation, putting the faulty mouse into my desk drawer.  
Later that day I had to go and visit a customer, and on returning to my desk I found a note that  
said “Engineer called and swapped your mouse.” Sure enough they had taken Dave’s spare  
mouse and left me a shiny new one. The faulty mouse was still in my desk drawer.  
I still remember this event many years later, because it taught me something really important  
about ITSM. Delivering same-day service with an on-site engineer was less valuable to me,  
as a customer, than putting the mouse in the post (even though it probably cost more for IT)  
because it wasn’t what I had expected. All I wanted from IT was that they tell me what they  
were going to do, and then do it. I didn’t need a really expensive, best-in-class, service. I  
needed to know what was going to happen, and then for IT to deliver what it had promised.  
There was a reason that people in that company used the term the helpless desk; it wasn’t  
because the people who worked there lacked skills, or didn’t care about their customers,  
rather it was because the help desk staff consistently failed to meet their customers’  
An IT organization that reliably delivers what its customers expect (and need) is doing a good  
job, whereas one that regularly fails to meet customer expectations needs to understand  
what’s going wrong and do something about it.  
Before I started working in IT service management I was a level 3 support engineer, resolving  
incidents and problems on highly complex hardware, software, and systems. I moved from  
technology to ITSM when I discovered quite how often the highly reliable technology I was  
supporting simply failed to meet the needs of the IT departments who were my customers.  
These IT departments used the systems I supported to deliver services to their customers,  
and eventually I came to recognize a pattern. Some IT departments were always delighted  
with the systems, even though they would occasionally fail, but others were always  
A little investigation led me to the realization that the happy customers were the ones  
managing their incidents and problems, planning their changes and releases, and negotiating  
service levels with their customers. The unhappy IT departments, it appeared, were always  
playing catch-up. They always seemed to be surprised by events, were never prepared to deal  
with incidents and problems, their changes and releases kept going wrong, and they never  
met their customers’ expectations.  
So that brings us back to basics. How do you ensure that your customers have realistic  
expectations? What do you do to ensure that you reliably meet them? Why is it important to  
report on your achievements and what form should that reporting take?  
I think that great ITSM starts with effective service level management (SLM). So my first “back  
to basics” recommendation is this:  
Review how you do SLM to make sure it’s focused on the right things.  
If you get this right, then your customers will have reasonable and realistic expectations,  
you will reliably meet these expectations, and your customers will know that you met their  
expectations. So your next task is to deliver something even better.  
Exceeding Expectations  
In my view, the most effective approach an IT organization can take to ensure that it delivers  
beyond what its customers expect is to know exactly what it is delivering, when, how, and  
to whom; to know where its strengths are and how it intends to build on them; to recognize  
its weaknesses and to know what it can to do to improve on them. So my second “back to  
basics” recommendation is this:  
Invest in continual service improvement (CSI) –  
keep measuring and improving everything you do.  
Anticipating Future  
Like my first recommendation, my third recommendation is about understanding your  
customers’ needs. There isn’t any point in pouring resources into maintaining a complex  
database that no one uses, or providing a shiny new tool that customers will not be trained to  
use. On the other hand, if you can anticipate what your customers will find most useful in a  
rapidly evolving marketplace, they will thank you for it. So my third recommendation is this:  
Focus on service portfolio management (SPM) –  
make sure you’re delivering what your customers really need.  
Again, some readers may be surprised to see that I haven’t included common ITSM processes  
like incident management and change management in my back to basics approach. There  
are two reasons for this. Firstly, I think it’s much more important to focus on your relationships  
with your customers. If you get the structures you put in place as part of SLM, CSI, and SPM  
right, you can pretty much guarantee that your relationships will be positive and that everything  
else will be under control. Secondly, this paper will be distributed in a box with other articles  
that offer advice on how to get started with these critical ITSM processes, and I don’t want to  
duplicate that advice here!  
Meeting Expectations  
with Service Level  
Management (SLM)  
There are two different approaches that I have seen IT organizations take to SLM. One of  
these is very effective and the other always leads to dissatisfied customers; so let’s start by  
looking at what SLM can be, if you do it well. The diagram below shows that SLM has two  
cycles of activity, joined together by a service level agreement (SLA).  
Cycle 1 – Understand, Negotiate, Agree  
Understand: Talk to your customers, understand how they use each IT service, and  
what service levels they would like in an ideal world. Discuss the impact of incidents and  
problems on their business, and how quickly they need you to respond to requests for  
change. Do they need this service to be agile and responsive, with many changes to fit  
changing business needs, or do they need it to be stable with low rates of change and  
extremely high reliability? Does the data need to be highly secure to protect confidentiality,  
or do they need minimal controls to enable flexible working? Do they need an expensive,  
fast continuity arrangement, or will something more basic be good enough? Ideally, you  
should write down what the customer wants in their own language. Don’t force them to  
use IT terms. If they say, “I want to be sure that IT failures don’t have a significant impact  
on business processes,” then that is what you should write down; don’t change it to “they  
want 99.99% availability.”  
Negotiate: Once you have understood what the customer would like, you can discuss  
this with your IT colleagues. Work out what you can deliver easily, and what will be  
more difficult. Some customer desires might be unachievable, and others might require  
additional funding. Once you have understood your constraints you can negotiate  
with both the customer and your IT colleagues to document service level targets that  
are relevant and achievable. It is important that the targets are sufficient to satisfy the  
customer, and that they can be reliably met by the IT organization. Your targets should  
be SMART: specific, measureable, achievable, relevant, and time-based, but this is not  
enough. They need to be formulated in such a way that each target is clearly aligned with  
something the customer wants, expressed in clear language that the customer uses and  
can relate to – even if that language is not technical or numerical. So if, for example, in  
your preliminary discussions with the customer about their wants you have written down  
“IT failures don’t have a significant impact on critical business processes,” then you might  
at the target setting stage agree on targets of: “Maximum of 6 total service outages in any  
year” and “After a total service outage, service will always be restored within one hour”.  
Agree: Write down the agreed targets in an SLA, and get the customer to review them.  
Don’t lose sight of the original customer requirements. They should appear in your SLA,  
with the numerical targets written below them, so that it is clear to everyone what it is that  
the customer really expects you to deliver, and what numerical target(s) you have agreed  
to measure as a way of indicating that you have in fact achieved the real requirement.  
When everybody is happy with the targets, you can publish the SLA. Publishing the SLA  
should not be an end point though. As the diagram shows, this agree step leads straight  
back to understand. It’s essential to continually communicate with your customers: keep  
updating and refining your understanding of their needs; make sure you understand how  
their business is evolving and changing; and then negotiate SLA changes that reflect  
these changing needs.  
Cycle 2 – Monitor, Report, Improve  
Monitor: Every metric that you put in the SLA must be measureable, and you need to  
collect and record the data on a regular basis. If you can’t measure something that you  
have agreed on, then you should either get the tools you need so that you can measure  
it, or remove the metric from the SLA. You can use monitoring to trigger events that  
allow you to take action before service levels are breached; the best measurement is  
one that you make in time to correct an issue before it has impacted a customer. One of  
my customers, for example, has an agreement that there will be a maximum of 4 hours  
downtime per quarter for critical services. They generate an alert when any of these  
services goes over 2 hours’ downtime in a quarter, and this triggers action to prevent an  
SLA breach. For example, they might put in a change freeze, or assign a senior technical  
person to monitor the service on a regular basis, or change the priority for incidents to  
ensure they are escalated sooner.  
Report: Regular reporting of achievements against your SLA gives you an opportunity  
to build relationships with your customers. You can use the reporting phase to find out  
whether their experience of the service matches your understanding, and to help set their  
expectations for future service levels. These reports should be delivered frequently enough  
to help you develop the relationships you need – if you don’t report often enough your  
reports will not help you to build the positive working relationship you are after. Monthly  
reporting works well for many of my customers, but you should agree on the reporting  
frequency with your customers depending on their needs. Your reports must provide data  
about how well you met your measureable targets, and what the trends are – but this is  
nowhere near enough. You also need to discuss what the customer wanted, not just what  
you agreed to measure. For example, you could say something like:  
“We agreed that IT failures wouldn’t have a significant impact on your critical business  
processes, and that we would measure this by showing that we had fewer than six total  
outages in any year, and that service would always be restored within an hour. Last  
month we had an outage and service was restored in 56 minutes. Are you happy with  
this? Do you agree that this didn’t have a significant impact on the business?”  
A discussion framed like this ensures that you are reporting the IT service in terms the  
customer understands, not simply forcing the customer to accept your IT view of the  
world. They may respond by agreeing that the service has been acceptable, or they might  
say that this 56 minute outage actually had a major impact and they need to renegotiate  
the metrics – but that’s the point, this is how you get a better understanding of the  
customer, and build a relationship.  
Your reports should not just show the values, and whether or not you met the targets,  
they should also show trends, and should include information about what you are doing  
to improve. If you have missed a target, take the opportunity to explain what happened  
(without making feeble excuses) and say what you are going to do about it. This is much  
better than reporting a missed target without giving any indication of why it was missed,  
or what you are going to do about it, which will inevitably have a negative effect on your  
Improve: If you have failed to meet an agreed target, or if the trends suggest that you  
may miss a target in the future, then you should develop an improvement plan, and these  
improvement plans should be shared with your customers and discussed in your regular  
service review meetings. Even if you are consistently meeting all of your metrics and the  
trends are stable, you should still make plans to improve the level of service where this is  
practical and affordable.  
You need to keep repeating this monitor, report, improve cycle. Typically, the cycle will  
be driven by the frequency of agreed reports, but monitoring should happen all the time,  
and the rate at which you make improvements may require some of them to be managed  
outside the normal SLA reporting framework.  
Service Level Management Abuse Alert  
I mentioned at the beginning of the section on SLM that there is a way to approach SLM that  
leads to dissatisfied customers. I see this approach so often that I think it’s worth an “abuse  
alert”. If you recognize any of the following – sadly, not untypical – features, you will find it  
particularly helpful to review your SLM so that you can get back to basics.  
Poor SLM presents customers with SLAs that have been written by the IT department,  
with no customer input and no attempt to align the targets with customer needs.  
Poor SLA targets are written in IT terms, often quoting percentage availability that means  
absolutely nothing to a business person.  
Poor SLAs include lots of internal IT metrics, which have to do with how the internal IT  
processes and systems work, rather than metrics that measure outcomes the customers  
Very poor SLAs include penalties for not achieving targets; these almost always lead to  
really destructive behavior, with the IT department learning how to manipulate the metrics,  
rather than focusing on helping customers to achieve their goals.  
The worst SLAs consist of extremely long documents, with lots of legal terms, and result  
in painful meetings where the detailed wording of the SLA is argued over. These lead to  
poor relationships and dissatisfied customers, exactly the opposite of what SLM was  
meant to achieve.  
Remember, the point of SLM is to help you:  
Set reasonable and realistic customer expectations  
Reliably meet customer expectations  
Be seen by the customer to meet their expectations  
If you’re achieving all three of these, then congratulations, keep up the good work. If you’re  
not, then consider getting back to basics, and focus on how to get SLM right for your  
Exceeding Expectations  
with Continual Service  
Improvement (CSI)  
My second “back to basics” recommendation is to develop CSI. If you can get CSI working  
in your organization, then you can use this to drive improvements in every other area, while  
keeping the focus where it needs to be – on maximizing customer value and continually  
improving customer experience.  
Some people think that CSI is a process, with fixed activities that you have to carry out, or  
that it is a function, with a CSI manager, and a CSI team who are responsible for continual  
improvement. Other people think that CSI is a stage in the service lifecycle. They have read the  
ITIL® publications or attended ITIL training and took the presentation of the service lifecycle  
very literally. This lifecycle describes service strategy, service design, service transition, service  
operation, and continual service improvement, so people take away the message that CSI is  
something you do after the service is in operation. They miss out on all sorts of improvement  
opportunities across the whole lifecycle.  
I don’t find any of these views of CSI helpful. For me, CSI is a combination of attitudes,  
behavior, and culture. It is the understanding that you can never stand still; the alternative to  
improvement is stagnation, and gradually losing relevance. Your competitors are constantly  
upping their game and if you don’t keep pace, then your customers will gradually become less  
satisfied with your services.  
An organization that adopts CSI is constantly looking for ways to improve:  
The services they deliver to their customers (see next section on SPM)  
The service levels they achieve for each of these services (see previous section on SLM)  
The tools and technology that support the services  
The processes that underpin delivery of the services  
The skills and competence of the people who manage the services  
CSI won’t make all these things perfect, but if everyone in the organization understands the  
importance of CSI, and keeps looking for opportunities to improve, then you will be able to  
identify and prioritize the improvements needed to keep you competitive.  
I find a CSI register a very helpful tool for managing improvement opportunities. This is just  
a log of all the improvement opportunities you have identified, with a bit of information about  
how much each will cost, what value it will have, how urgent it is, etc. It is used to prioritize  
the improvement opportunities, so you can select the ones that you want to invest in. In a  
large organization there could be many CSI registers, one for each process, or one for each  
business unit. Even in a small organization you could have a personal CSI register for tracking  
your own improvement opportunities, as well as one for the team.  
Some improvements can be very low cost, or even zero cost. I was discussing CSI with some  
colleagues on Twitter last year and we coined the term Zero Cost Improvement (ZCI). This is  
a great idea to introduce to any organization. There are always ways that you can improve,  
which cost absolutely nothing. These improvements have an infinite return on investment, and  
you can’t get better than that!  
Anticipating Expectations  
with Service Portfolio  
Management (SPM)  
My final “back to basics” recommendation is to make sure you have good SPM. This is to  
ensure that the services you offer your customers are the ones they actually need, and that IT  
is driven by business priorities.  
Some years ago I came across the term zombie services. A zombie service is one that nobody  
has any use for, but the IT department continues to deliver because there is no mechanism to  
measure and understand the value of services to the business, and to retire services that are  
no longer needed. Nearly every IT department I have worked with over a very long career has  
had one or more of these zombie services.  
The other side of this issue is that a really great IT department sits down with their customers  
and discusses how they can help the business to innovate. They think about how all the data  
they have could be combined in different ways to create business value. They combine their  
knowledge of emerging technology with their understanding of the industry they work in to  
create insights about possible opportunities. As a result of these discussions, they invest in  
creating new services that make their customers more competitive.  
Most people working in IT don’t have significant influence over the service portfolio, but we all  
have an opportunity to identify services that are under-utilized, or to share our ideas of new  
things that IT could be doing. If you are responsible for the services your IT organization offers,  
then here are some ideas of things you could be doing:  
Make sure that you have documented the things you do as services, focusing on your  
customers’ needs. If all of your services are just applications, or technology components,  
then you need to rethink how you deliver value to customers – unless of course you are  
providing infrastructure services as a service to other IT service providers.  
Maintain a service portfolio, which describes all of your services in terms of cost and value.  
Share this with your customers so they can see where the money is going, and so they  
can influence decisions about which services need more investment, which should be  
maintained as they are, and which should be retired.  
Include ideas for possible future new services in the portfolio, so that you and your  
customers can see the whole story when planning future budgets.  
Encourage IT staff to contribute ideas to the service portfolio. IT departments are  
usually full of clever people who really do understand how IT can make a contribution.  
If you encourage people to make suggestions of how IT can create more value for your  
customers, then you may be surprised at how many great ideas you get. Many of these  
can be added to the portfolio for discussion with the business.  
If you want to deliver great IT services to your customers, then the key things you have to do are:  
Set reasonable expectations, so customers know what you will deliver.  
Reliably meet customers’ expectations.  
Make sure your customers know what you have delivered, and that you have met their  
Keep improving everything you do, moving towards a culture of continual improvement  
where people see CSI as part of how they work.  
Document current and possible future services in terms of cost and value and regularly  
discuss these with customers, so that your IT organization can be seen as part of the  
organization’s value creation, rather than as a cost.  
As you start working on these things, you will identify opportunities to make improvements in  
many different aspects of how your IT organization works. Many of these will require you to make  
improvements to processes such as incident management and change management, but don’t  
make the mistake of thinking that these essential processes are the “basics” of ITSM. Focus on  
customers and value first, and use the processes to help you get there.  
In addition to Stuart’s “back to basics” advice, SysAid is here to help you  
deliver great IT services to your customers. Want to learn more?