Posted by Sarah Lahav
on October 25, 2016 in Help Desk
Working in IT, particularly on the IT help desk, can often be a “glass half empty” rather than a “glass half full” experience – with many of the day’s activities related to things that have gone wrong. So it’s easy to avoid anything else that is remotely negative in nature, but unfortunately if something is wrong – in terms of people, process, or technology
– one has to bite the bullet to provide negative, but hopefully constructive, feedback. Here I provide ten tips for providing such feedback, along with advice on how to ensure that you go about it the right way.
1. Check, Check, and Recheck
Are you 100% sure that the person you’re providing the negative feedback to is deserving of it? Are you sure that the issue isn’t simply because of bad instruction, faulty processes, misunderstanding, or someone else’s mistake? Always ensure that you have all the facts, and never make assumptions. You’ll only create further damage if your feedback is based on inaccuracies and/or is un-deserving.
2. Highlight how improvements can be made
When a person receives negative feedback it’s common for them to go into defensive mode. They can often become upset, and worse still, apathetic – the result of which means they actually get worse, not better. It’s also often the case that an individual simply can’t see a way to be better. Think of how many times you’ve completed what you thought was a simple task, only for one day somebody to point out that there’s a much easier and quicker way? Sometimes you simply can’t see that you’re being inefficient, or that a better way exists.
Don’t criticize someone without showing examples of how they can improve.
3. Don’t Save Negative Feedback Up
If you give too much feedback in one go the individual that you’re dealing with might not be sure of which piece of advice to focus on first. Also, to be called out on a number of things can feel overwhelming and make the individual potentially feel like a failure. If, on the other hand, you’re only providing negative feedback on one task or action, it’s more likely to be viewed as smaller mistake that can be easily rectified. It also makes point number one (check, check, and recheck
) more difficult if you leave feedback to a later date because it makes it harder to pinpoint where and why an issue occurred, and what the associated facts were.
4. Know Your Audience
Different people take feedback and criticism in different ways. Some might get upset, some might get angry, some may choose not to listen, and others may be very welcoming to an opportunity to improve. Thinking in advance about who you’re talking to and how they might react can help you prepare how to best deliver your feedback. Do you need to highlight what they did well first (maybe, but be careful that that’s not the only bit they remember)? Do you need to speak softly in an understanding manner? Do you need to be very direct? Understand your audience and tailor your approach accordingly.
5. Provide Your Feedback Face to Face
Unless you don’t have this opportunity, always opt to provide your feedback in person. The absence of tone in an email can leave you open to the recipient inferring something that isn’t there, especially if they’re already feeling vulnerable or defensive. Telephone is better than email, but it still leaves you unable to display an open and friendly demeanour, make eye contact, or showcase positive body language. If face-to-face really isn’t an option, try a video call so that the person can at least see you when you speak to them.
6. Let Them Talk
Ask them to give their assessment on the situation that you’re referring to. Not only does this help with tip number one (check, check, and recheck
), but it helps you to understand their version of events. You may also find that they carry out tip number two (highlight how improvements can be made)
for you by offering up their own suggestions for improvements based on their own review of the situation. Most people will understand that there has been an issue, and will welcome the opportunity to discuss it with you.
You want to provide criticism in a way that adjusts the negative behaviour, but doesn’t create a problem between you and the individual. You want to ensure that they still feel comfortable with you, and still feel connected to you, their team, and the company. It’s therefore important when acting on tip number six (let them talk
) that you listen carefully to what they have to say. People are unlikely to want to spend the time and effort improving for someone who isn’t interested in their opinions and feelings.
8. Ascertain the Basis of the Problem
Why did the said individual perform the way that they did? What was the root cause of the issue? If you’ve carefully taken point seven (listen
) into consideration then you may have already established why the issue occurred, but if not be sure to discuss this. You can’t fix the issue without fully understanding the problem.
9. Agree on Next Actions
Agree on an action or improvement plan to be followed to ensure that the issue does not reoccur. You need to provide the individual with an opportunity to improve, and you can only do this by agreeing together on a course of action. Set dates for review and let the person know that you’re there to help them should they for any reason struggle to move forward with your feedback or change their behaviour. Don’t just criticize and then close the door.
You may also find it useful to set up a follow-up discussion, simply to allow the person time to digest the information you have given them, accept the criticism, and recover from any injured pride or anger they may have experienced.
10. Be Willing to Accept Criticism Yourself
Accept that you may have some responsibility to take in the issue at hand. Perhaps you didn’t communicate clearly enough to begin with? Perhaps the individual didn’t feel supported, or felt out of their depth and you didn’t realize? Understand that when you provide criticism and you set about with tip six (let them talk
) that you may find yourself to be part of the problem. If so, ensure that the changes you’re required to make are recorded as part of tip nine (agree on next actions
Focus on Improvement
Remember that the goal of feedback is to improve the behavior of the other person to help both them and your overall business. Negative feedback is an opportunity to make someone work better – do it right and you should notice significant improvements.
So, those are my top ten tips on how to deal with providing negative feedback. Is there anything else that you would add?
Posted by Dena Wieder-Freiden
on October 18, 2016 in Service Desk
It isn’t often I get to start an IT service management
(ITSM) blog with a William Shakespeare
quote, but he put it perfectly in Romeo and Juliet
: “What’s in a name? A rose by any other name would smell as sweet.” Sadly, as our Shakespearean heroes discover in their tragic demise, human society does indeed get hung up on the names, labels, and words we use. ITIL®
has been guilty of hijacking words from the English language and assigning them their own special ITIL meanings (you know like “incident” or “problem”), which has caused many people to get confused and miss the significance of the concept being described. Just like in Shakespeare’s play, all that baggage of the Montague and Capulet families damages the simple meaning of a boy and a girl in love.
So…ITSM Users and Customers
Let’s focus now on one important concept that I find gets very confusing because of the terminology. In ITIL, the terms customer
are given significant differences in meaning.
has financial involvement – they pay for the service. This could mean actually paying with real money, but not always. Sometimes it might be the budget holder who is charged, or it might just be signing off on a business case without tangible money being transferred. But in each case, the customer is in a position to see the bigger balance between the cost of the service and the benefits it gives.
is just that – someone using the service. They deal with inputs and outputs, not what it costs or on the value it offers for the money paid out. Users will have opinions based just on what the service does, nothing much beyond that.
The truth is we’re all already familiar with these concepts, as they are part of our everyday lives. Let me show you what I mean with a few examples.
Choosing a Car
So, imagine your car was stolen and the insurance company sends you a check in the sum of your compensation. Off you go to buy a replacement. You walk around the car dealer and a nice, shiny red car with a pretty prancing horse motif catches your eye. “Yes,” you think, “I’ll have that one.” Then they tell you what the Ferrari costs and you go home in a second-hand Ford still able to pay the mortgage and feed the children.
That’s you being a customer, able to balance the pleasures and benefits of having that car against the cost and what you can afford. Customers can make those compromises because they see both sides. The user (maybe your kid who also drives the car) will just be driving the car, and isn’t ever going to be satisfied with what they drive, always wanting more when it isn’t their money.
At the Toy Store
You’ve probably all seen both sides of this example, as an adult and as a child. Off you go to the toy store with your son, daughter, niece, nephew (you get the picture), and you let them look around at all the toys, intending to buy them one as a treat. The children will not be looking at the price tags, rather they’ll be totally focused on what the toy does and how much fun it is, or will be, if they can have it. The adults will have other considerations. First and foremost, they’ll care what each toy costs, both in terms of whether they can afford it and whether it seems to deliver value for the money. They might also have a broader view, by considering educational value as well as entertainment value.
Here the adult is obviously the customer, and the child is the user.
Different Roles, Not Just Different People
In the IT scenario, and our ordinary lives, it’s important to realize that a customer
and a user
are roles – not necessarily different people. You may choose the cheaper option when you’re acting as the customer, and still find yourself annoyed later at the lack of facilities, reliability, or support (or lack thereof) when you’re acting in your role as the user.
That comes out in an ITSM situation when the customer agrees, for example, to a service level agreement (SLA) with support from 8am-8pm on weekdays. Despite that making good economic sense during initial negotiations, the user in you will still feel aggrieved when the system goes down while you’re using it on a Saturday and nobody is available to help you until the next working day.
At home, you might be offered a deal by the power company – for an extra $400 a month they can guarantee stability and continuity of the electricity supply. That seems far too much to your customer view and so you turn it down. Still, six months later when the power fails, the user in you is upset – maybe with the power company, maybe with yourself?
Call Them What You Like, But See the Two Roles
Of course, just because ITIL uses those two words – customer and user – doesn’t mean you need to. But it does matter that you can see the two roles and address them. Customers, of course, must make the decisions about what can be afforded, but users need to be involved if services are to match their abilities, styles, preferences, and culture of work. If not, then the service will not be used to its potential and is unlikely to deliver value for money.
And this doesn’t end once a service goes live – ongoing maintenance and improvement depend on dialogue with both groups. ITIL gives us channels for discussions with both customers and users. Negotiating and reviewing SLAs, within service improvement programs
, change management
, and more is done with customers. And the service desk
is the major interaction with users – besides taking calls when things go wrong, the service desk can also gather users’ concerns and desires, and then feed them into improvement programs.
A good organization will take steps to set up and maintain communication with both types of stakeholders. Is that what you’re doing?
Posted by Sarah Lahav
on October 10, 2016 in Help Desk
The term “service desk” can give rise to a number of conversations, and sometimes arguments. For instance, should you call it a help desk, service desk, or something else
? And for companies with relatively small, and probably very busy, IT support teams, the idea of having someone sitting at a desk waiting to answer the phone
is a people overhead that they just can’t afford.
But don’t let the “desk” in service desk and help desk put you off formalizing and better enabling your IT support people – whether it’s through the adoption of industry best practice for IT service management (ITSM) or the investment in a fit-for-purpose help desk or ITSM tool. Maybe, just maybe, if this technology category was called “IT support tools” it might instantly seem more relevant to your company’s lean and mean IT support operations.
Looking at the Small IT Support Team Status Quo
All companies have some form of IT support but are they performing as well as they could be?
Of course the largest of companies need to have formalized and often highly-populated IT support teams – here there’s so much IT gluing business operations together, that things are bound to occasionally go wrong. So they’ll have a help desk (or service desk), plus other ITSM activities, enabled by fit-for-purpose ITSM technology.
At the other end of the company-size spectrum, IT support staff can’t always be justified. With the very smallest of companies using self-support and peer-support (most likely ably assisted by Google), or specialist third-parties to provide IT support as and when needed.
But what about those companies somewhere in the middle, which are of a size, and IT importance, needing one or more IT support personnel to help keep the IT, and thus the business, operational (and often also to drive it forward with new technology)? These IT support personnel rarely have the time to catch their breath, bouncing from one IT issue to another, and also fitting in non-business-critical IT support tasks as, and when, they can. They work hard, very hard, but could they work “smarter”?
Getting the Most Out of Limited IT Support Resource
Some might say that overworked IT support personnel in very small IT teams need more technical training, which they then might never have time to undertake. Others might say that they just need more IT support colleagues, which could of course be right, but budgetary restrictions prohibit it.
However, taking a step back out of IT support, what have companies traditionally done to improve the efficiency and effectiveness of staff since the late 1980s? The answer – provided staff with fit-for-purpose technology for both personal productivity enhancement (for instance email, laptops, and then smartphones) and business process enablement.
Stepping back in, IT support personnel in small IT teams might already have great personal productivity technology but what about technology for the enablement of their IT support processes? In fact, how many realize that they might have IT support processes? They just do what they think is best to “get the job done” day after day, week after week.
They will of course have access to some enabling technology – which might be for monitoring, network management, or remote support. They might even use their personal productivity technology – such as email and spreadsheets – to support their processes. They just don’t have access to what most larger IT support teams use – fit-for-purpose help desk
or ITSM technology.
How Help Desk and ITSM Technology Helps Smaller IT Support Teams
If you’re part of a small IT support team, there’s no desk involved, right? In fact, the only time you likely sit down for a prolonged period of time is while eating your lunch. But it’s probably not a lunch hour, as you just don’t have time for such an extravagance.
Have I hit a raw nerve yet? I don’t mean to but really, this is the crux of the matter – the introduction of IT support technology might offer capabilities to improve efficiency and effectiveness but the real win for small IT teams is to create more time to get things done! It’s the classic “doing more with less” (or “delivering more with less”) that has been echoing around ITSM conferences for the last decade.
So It’s About Time…
…And yes, you can read that two ways, both of which are appropriate here.
A fit-for-purpose IT support tool, call it whatever you like, will help small IT support teams to use their limited time better, even optimally. The generic, cross-process capabilities such as knowledge management
, workflow, automation, alerts, and even calendaring will help to stop them from “wasting” time on repetitive, often manual activities.
Plus certain tool capabilities will save IT support time directly. For instance, implementing an end-user self-service capability will use knowledge management to support end-user self-help. And self-service automation
, such as password reset, will further remove many of the common, yet simple, IT support tasks from the IT team’s daily to-do list. Mobile access to asset, ticket, or knowledge management information also saves time as IT support people dart from end-user issue to end-user issue.
Plus, there are many other benefits that are not so directly related to saving time. Such as using standard, best-practice processes and templates to optimize IT support activities. Or insight into operational performance and service delivery, with reporting used to demonstrate IT support’s worth, to identify improvement opportunities, or even to build a business case for increasing the size of the IT team.
Of course this final section only scratches the surface of how a help desk or ITSM tool can help smaller IT teams, but hopefully the blog has shown that a physical desk definitely isn’t necessary to benefit from them.
Posted by Stuart Rance
on October 5, 2016 in Service Desk
IT organizations often spend huge amounts of time, money, and other resources on managing incidents, but they spend surprisingly little on problem management work that might reduce the number of incidents in the first place. This is often due to poor understanding of the difference between incidents and problems, and insufficient knowledge or understanding of how to manage problems.
Why Do We Distinguish Between Incidents and Problems?
Many people confuse incidents and problems, so let’s start by making the distinction clear
- An incident is an unplanned interruption to an IT service, or a reduction in quality of a service. Incidents have an impact on users, and on the business, and the purpose of incident management is to restore normal service.
- A problem is the cause of one or more incidents. The purpose of problem management is to manage the problem, eliminating future incidents where possible, and reducing the impact of incidents that can’t be prevented.
So, incident management
helps you get the business working again, problem management helps you prevent future incidents, or at least make them less painful when they do happen.
In the bad old days, when IT was a very technically-focused function, most IT teams didn’t distinguish incidents from problems. If something broke, then somebody would work on it until it was mended. IT technicians paid little attention to the business impact of whatever it was they were working on, and the customer just had to wait until it was fixed. But when we learned to distinguish between incidents and problems, this changed. Organizations could set up incident management to focus on doing whatever is needed to get the business working again, leaving problem management to deal with any underlying technical issues. Take, for example, a printer that isn’t working. There is no need for the customer to wait till the printer is mended. When we practice incident management we can simply help the customer route their printout to a different printer. Obviously, this doesn’t get the printer fixed, but that is probably something that doesn’t really concern the customer. We can of course go on to repair the faulty printer. But this is now a problem management activity, with lower priority as the outcome has very little direct impact on the customer.
How Do You Identify Problems?
Before you can start managing your problems, you need to identify them. Here are some common ways that organizations identify problems:
- Trend analysis of incident records. This activity is sometimes known as “proactive problem management” because its purpose is to help you identify problems that you don’t already know about.
- Major incidents. Every major incident should result in a problem being logged, to ensure you take steps to prevent the same thing from happening again.
- Multiple incidents at the service desk. Service desk agents should notice if there are multiple similar incidents being logged and log a single problem to ensure that these are investigated and the cause addressed.
These are some of the ways that problems can be identified, and you should make sure that you take full advantage of these, but also think about all the different ways that a problem could be identified in your organization. For example, think about your suppliers, software developers, or infrastructure teams, and make sure that you actively capture all of their input and use it to log problems.
How Should You Manage Problems?
Problem management has two objectives:
- To prevent incidents from happening
- To reduce the impact of incidents that cannot be prevented
Many organizations only think about the first of these objectives. They do root cause analysis to understand the problem, and then take steps to rectify whatever was causing it. This may take some time, and while a complete technical solution may prove very effective once it is in place, the business is likely to continue suffering in the meantime.
The best organizations that I work withstart
by thinking about how to reduce the impact of incidents – the second of our two objectives. They ask themselves, “What should we do if this happens again right now?” This might be a difficult question for technical support staff to answer if they don’t fully understand the problem, but it’s much better than just leaving service desk agents to flounder when the same thing does happen again. Organizations with really effective problem management create workarounds for problems as quickly as they can. They make sure there is a well-documented workaround in place as quickly as can be managed, and they also review the workaround every time it’s used to identify possible improvements. And with the latter, they will also go on to improve the workaround as they learn more about the cause.
So one benefit of thinking about reducing the impact of incidents, before you start analyzing their root causes, is that you reduce any business impact much faster.
But there’s a second benefit – sometimes it turns out that a workaround is so effective that there is actually no need to understand the root cause or fix it. Here’s a perfect example:
One of my friends had a gas leak under the concrete floor in his kitchen. He turned off the gas and called out the emergency gas fitter. This gas fitter ran a pipe around the outside of the kitchen so that the gas cooker could be reconnected and arranged for a structural engineer to diagnose the leak properly, so they would know where to dig up the kitchen floor. The structural engineer called a week later and said it would cost a huge amount of money to dig up the concrete and fix the pipe, but fortunately this was unnecessary because the new gas pipe was perfectly safe and did the job.
This example doesn’t involve IT, but I’ve used it anyway because it is a particularly good illustration of the fact that a safe and effective workaround is often enough. Why waste good money fixing an application when you have a workaround to the problem and it no longer has an impact on the business?
Of course, if your workaround is not sufficient then you do need to investigate the root cause of the problem. There are many different techniques you can use for this. My favourite approaches are timeline analysis and Kepner-Tregoe problem solving.
This is such an easy way to investigate a problem that it barely deserves a name. You simply list everything that happened in time order and then look for patterns. What is important is that you get all the data from multiple sources and then sort it by date and time, regardless of where it came from. So your timeline may have entries from system logs, emails, service desk records, and many other sources. This simple approach is surprisingly effective at building a complete picture of what’s been going on.
Kepner-Tregoe Problem Solving
I have to declare an interest here, I used to teach this proprietary approach to problem solving
, but I do think that it is incredibly effective. This is a very structured approach to problem solving, where you define the problem across a number of different dimensions (what, where, when, extent) and you also bound the problem by identifying what is NOT failing. You can then review the distinctions between these to identify possible causes.
Problem management presents a great opportunity to reduce both the number and the impact of IT incidents on your customers. If you are not already doing problem management you should certainly be thinking about introducing it
. And once you do, I think you may find my guide to problem management metrics
worth a read.
If you are already doing problem management, then make sure that you have the balance between devising workarounds and investigating root causes right. You don’t always have to understand the cause to resolve the problem, but you do always need to put a workaround in place as quickly as you can. You may even want to think about how to integrate incident and problem management
, but whatever approach you take you should make sure that you focus on value. Think first and last about what will be best for your customers and users.
Posted by Roy Eldar
on September 27, 2016 in Service Desk
Come the end of a busy week, does your IT service desk ever look a little bit like the set of a western movie
The atmosphere is dry and barren. Random objects are strewn across the office like 21st
-century tumbleweed. With your team members staring blankly into the distance, eyes burned by the constant glare of their monitors, tired and reeking of apathy. It’s been a heavy week, and you’ve been consistently ambushed with incidents. The service desk has spent day after day in the firing line of end users, having to repeatedly circle the wagons under the glare of SLAs and stretching performance targets. And now your team is tired.
Pinned to the notice board is a sign, “Wanted: Motivation.” Best not to mention the wild west reference to dead or alive.
The Good, the Bad, and the…Unmotivated
Looking around at your team you start to wonder when the motivation disappeared and how long it’s been gone, but it’s no good following the hoof prints back down the already well-trodden trodden path. Instead you need to get back on your horse, perhaps after drinking your milk, and rally your riders. And here’s a few suggestions on how to re-motivate your team to face another week, month, or even year of the IT support wild west:
1. Listen up, partner!
Communication is crucial – listen to your team and instigate a collaborative feedback cycle. According to research by weekdone.com
, 39% of workers don’t feel that their input is appreciated.
By asking your team members for their input and involving them in the decision-making process, it will make them much more likely to support day-to-day activities, improvement projects, or your decisions. And remember, once you have gained their feedback, visibly follow up to show them that you’re actively taking their opinion onboard.
2. Have one-on-ones, but hopefully not standoffs
Recognize each member of your team as an individual.
And that your team’s motivation level is directly correlated to your management style. Did you know that 75% of people voluntarily leaving jobs don’t quit their jobs; they quit their bosses
In addition to more one-on-one time, you could also learn what motivates individual staff members through psychometric tests. Try to understand how they like to be managed to optimize their productivity. Then as their manager, create attainable goals and clearly communicate plans to keep staff engaged and in the loop.
In the Workforce Mood Tracker™ Spring 2014 survey
, 73% of respondents credited “recognition” for having a positive impact on their happiness at work. So wherever possible recognize work, and even personal, achievements to make your team feel valued.
3. Shoot ‘em up!
Gamify your service desk metrics to help motivate your team to hit their KPIs. Reporting on IT service desk performance can quickly take the motivation out of your team, especially if they fall below their agreed SLA threshold. Make reporting less daunting and more fun by fostering a little healthy competition and regularly recognizing excellence versus key KPIs. You could choose the quickest resolution time, the highest rating on a feedback form, or the number of tickets closed within a day; and offer up an incentive for the winner such as leaving early, a chocolate bar, or even just their name at the top of a leaderboard. The reward part of “reward and recognition” doesn’t need to be costly.
Hitting targets should be fun. Yes, recognize underperformance, but don’t let it override the great job your team does on a daily basis.
4. Did someone say rodeo?
Inject friendship and fun into your working environment by organizing regular socials.
Gallup research has shown that close friendships at work produce a 50% increase in employee satisfaction
, and having a close friend at work increased the likelihood of engagement by seven times.
So try to support the cultivation of friendships within your team, through social events such as team building excursions, casual team lunches, or networking events. And remember that happy employees are more productive employees! Research from the University of Warwick has confirmed that being happy made employees about 12% more productive
and, you guessed it, more motivated.
5. Banish the barren work-land
Ensure that the work environment is pleasant and inviting. Research
by the International Journal of Science and Research has shown that:
“The quality and quantity of work generated by employees are influenced by the work environment while poor environmental conditions can cause inefficient worker productivity as well as reduce their job satisfaction.”
So assess the environment your service desk agents work in. Hopefully your team isn’t packed into a dingy office, filled with old IT equipment, like in the IT Crowd
. Consider the lighting, temperature, noise, layout, decoration, cleanliness, equipment, furniture, and air quality. Let team members give you input to sensible environmental and ergonomic improvements. Help to create a sense of pride in the work area by allowing your team to embrace their individuality and feel ownership over their personal workspaces. Invite them to make the workplace their own, and if you can find the budget, spend some company money on making it a better workplace.
Time to Round It Up, Cowboy…
Happiness and job satisfaction have been scientifically shown to increase productivity and motivation in the workplace. So try to create the kind of atmosphere that makes your staff come to work every day, not because they HAVE to, but because they WANT to.
- Listen to your staff and instigate a collaborative feedback cycle. Communication is crucial.
- Recognize each member of your team as an individual.
- Gamify your metrics to motivate your team to hit their KPIs.
- Inject friendship and fun into your working environment by organizing regular social events.
- Ensure that the work environment is pleasant and inviting.
Posted by Dena Wieder-Freiden
on September 20, 2016 in Service Desk
tells us that there are three components to business value:
- Business outcomes
- Customer perception
- Customer preferences
Once this has been successfully memorized for the ITIL Foundation Certification
exam, most people then forget it. That’s a shame because it gives an insight into why customers might be less impressed with the services they’re getting than expected. In this blog, I’d like to take a look at how each of these concepts can help us get things right.
IT service providers generally focus on what IT applications and IT infrastructure actually do – their outputs. But to deliver genuine value, we need to think in terms of outcomes – the end result for the customer and the organization as a whole. So, a service provider’s first challenge is to see beyond initial outputs from their IT services and understand the outcomes: how they influence the customer environment. That requires learning about the service in the customer environment, things like:
- What business services does your IT service support?
- Never mind what you meant, how is it actually used? (In fact, is it actually used at all?)
- How many of the features, which you got excited about building, are exciting to the business as well?
We can illustrate this by analogizing it to the difference between using a car and a requirement to travel. The outputs of owning a car are about driving; the outcomes might be the ability to get to work or the shops, or impressing the neighbors with what you can afford. Seeing the difference would help you choose the right car – or perhaps even suggest alternatives like traveling by bus or train.
Think about it. This is a serious and important jump for many in IT. It’s about seeing beyond the initial functionality, but it’s only a part of the challenge to real business-IT integration and customer satisfaction.
Perception and Preference
In order for a service (or that car) to deliver any value, the customer has to be in a position and a mindset to receive it. If not, then the best of all services will not be of any actual use.
Let’s stay with cars a moment. I lent my car to a friend, who returned it remarking on how easy it was to drive. I agreed, commenting specifically on how useful the cruise control is. My friend reacted with: “Cruise Control? Where is that?” This proves my point – if you aren’t aware of something, then it’s impossible to get value from it.
That kind of scenario is repeated in an IT context every day around the world: “Wow, I didn’t know it could do that”, or “where did you learn that?” At home, a few of us know all the features of our TV, DVD player, or cable TV. We have reached a stage in the evolution of technology where the users of that technology rely on intuition rather than training, and so services must work in a way that is obvious without words
. Unless it’s clear what a service can do, it will not get used, and the service provider’s efforts will not be appreciated – nor willingly rewarded.
And even knowing that the service is there at all can be a challenge without an easy-to-use and comprehensive service catalogue that the customers can reach – and feel is worth reaching and exploring.
This is an area that can really undermine the hard work put in by a service provider. Appreciation of value rests on the attitudes of the people you are supplying. And, just about always, people are the least predictable element of any organization or situation. No matter how well you think you know them, they can surprise you. Add to that the fact that IT services are typically supplied by
IT folks to
business folks, and you have a “disconnect” of preferences just waiting to cause troubles.
Once more, let’s use a car analogy: many years back, our family was searching for a new car, so my husband took me to see what he had found at a car dealer, confident he had found us the perfect solution. The car was strong and fast (as we specifically wished it would be), a model we knew, was in good condition and at a good price. So…no question for him, we should buy it. But I had to reject it…because it was white! Of course I didn’t want a white car, no matter how well-matched to our other needs it might be. How could he have not known that when it was already so clear and obvious to me ;)?
That kind of preference can look like bias, unreasonableness, or even bigotry. But even if it is, it is real, and a supplier must cope with it and deliver something that is acceptable.
For an IT service, the customers may have strong feelings about how the interface works, and reject one that doesn’t work “their way”. Or it may come from a source they disapprove of. Without establishing those preferences beforehand, once again IT service providers will be working hard to deliver something that will not be appreciated.
Knowing, Learning, and Matching
So, what I’m trying to say is – to be a successful service provider, it means getting out there and understanding not just what your customers need, but their attitudes, likes, and dislikes. In a large organization maybe you work with your business relationship team, or account managers, to help bridge the perception and preferences gap. Then again, there is no real substitute for getting out, talking, and listening to your customers yourself.
For more on this topic, I highly recommend you read Stuart Rance’s blog “What Value Are You Creating from Your IT Job?”
Posted by Sarah Lahav
on September 13, 2016 in Service Desk
“Customer experience” you say. What the heck is that?
If this sounds like you, don’t worry, you’ve come to the right place. You see we’re big evangelists of the customer experience
and believe that it’s something that every organization should have the opportunity to wrap their head around and to introduce into their business.
Why? Take a look at organizations such as Apple, Disney, Virgin, and Tesla. What’s the one thing that these companies all have in common? Other than being some of the biggest names in the world of customer service (as well as all being valued at over a billion dollars or more), they all understand the importance of the customer experience, and have “gone above and beyond” to ensure that their organizations are finely-tuned customer experience machines.
Yet, What They’re Doing is Nothing New
In fact, the entire idea of customer experience is nothing new. A quick bit of Googling and you will discover that the UK department store John Lewis
has been crafting its customer experience for more than a 100 years.
What is new, however, is that more and more organizations are taking customer experience on as a means to improve their competitive advantage through wowing their customers.
So What Does this Have to Do with ITSM?
In IT, and in IT service management (ITSM) roles in particular, we strive to provide great IT services but many of us have yet to make the leap to providing a great service experience. But who can blame people? It hasn’t been on the IT or ITSM radar until recently. For instance, ITIL
, an ITSM best practice framework, offers advice on how to create and deliver great IT services but it doesn’t outline how to offer a great customer or service experience.
“But why is it on the IT and ITSM radar?” I hear you cry.
The simplest answer is: consumerization. Not the consumerization of IT but the consumerization of service. Just as the consumerization of IT has been about the rising employee expectations of corporate hardware based on what they have in their personal lives, the consumerization of service is the rising employee expectations of corporate service providers based on personal-life experiences of service and support.
So while many IT organizations might be focused on delivering better customer service, employees empowered by their consumer-world experiences are now expecting a better customer experience.
Is Customer Service Miles Apart from Customer Experience?
Service and experience are similar but they are not the same.
is the interaction between the customer and the service. However, it doesn’t just reflect an outcome but also the emotional feelings a customer has towards the service (and service provider) too. And these feelings are based on a number of variables, especially touchpoints such as ordering, paying, and how issues are dealt with. It’s every touchpoint in the customers’ journey, every part of your service, affecting their experience.
A more formal customer experience definition is:
“The process of strategically managing a customer's entire experience with a product or company.”
~ Bernd Schmitt
And to really understand the customer’s entire experience, you need to see the service from their point of view
Step into Your Customers’ Shoes – Look at Their Customer Experience with Customer Journey Mapping
Customer journey mapping (CJM
) tells the story of the customers’ experience, from their first contact to their last, all the way through. It’s a useful exercise to help service providers to identify the touchpoints in a service
and where the customer experience can be improved.
Whether you’re using a customer journey map to look at a specific part of the customer journey, or the journey as a whole, you’ll quickly be able to identify:
- The key interactions that your customers have with your service
- How the interactions make the customers feel
- What the customers really want from you as their service provider, and
- Where the gaps are, that you need to fill to make the customer experience even better
What Does This Look Like in Practice?
Imagine the corporate self-service password reset service as an example. Normally when we think about something as “simple” as this, it’s easy to assume that the route to a successful outcome is equally as simple.
Without first mapping the customer journey out, it would be all too easy to assume that the journey might look like this:
- User logs into the self-service portal
- Searches for the password reset facility
- Resets password and returns to working
However, through the use of CJM we can start to uncover the additional steps that often go unaccounted for; and with it, the gaps or issues that are disrupting the customer experience.
So with the help of CJM we might discover that self-service password reset actually looks something like:
- User can’t log into their machine
- Tries multiple times to log in with no success; is convinced that it’s an IT issue
- First tries calling the service desk but can’t get through and gives up
- Resorts to self-service portal even though they don’t like using it
- Discovers the search facility in the self-service portal
- Types in “password not working”
- The search facility doesn’t show any related results (as the search facility hasn’t been “tuned” for different variations of “password reset”)
- Eventually stumbles on the password reset facility as they definitely don’t want to queue in the service desk’s telephone channel again
- Starts process to reset password
- Asked to check email to set a new password, but can’t access email because they are locked out of their machine and don’t have webmail or access via their mobile phone
- Tries to call service desk again ...
As you can imagine, the experience for the end user is far from a positive one. In fact, from an emotional perspective it’s probably extremely frustrating and another reason for IT’s name (and reputation) to be dragged through the mud. But without the process of CJM, it’s very unlikely that you’ll ever become aware of all the additional steps that your user has to go through to get the resolution they’re searching for.
What’s more, a successful journey map might initially leave you with more questions than answers, as well as the desired outline of where you need to improve. Here’s an example of some of the questions that might be raised re the previous scenario:
- Why did the user try calling the service desk before trying the self-service portal?
- Why couldn’t the user get through to the service desk via the phone?
- Has the user ever been properly educated in using the self-service function?
- How easy is it to discover and use the search function when you don’t use “IT’s language”?
- Was there plenty of up-to-date and relevant documentation to help make the password reset process easier?
- Has anyone from the service desk used the self-service password reset themselves to test for any use-case scenario “bugs”?
It’s this kind of investigation that will force you to start thinking differently about your current service and makes looking for issues and gaps a much easier experience.
In the earlier password reset example, the IT departments is offering a poor customer experience even though it might think it’s offering good customer service through the provision of such automated capabilities.
Connecting the Dots Between Customer Experience and Customer Service
That’s a lot of theory, so how do you apply it practically? Luckily for you, creating a seamless customer journey doesn’t need lots of tools and investment and it can be kicked off with just a group workshop, a flip chart, and a whiteboard. Here’s the steps:
- Gather together your service desk team members and brainstorm each element of your service.
- Create a stakeholder map including their influence.
- Create a customer persona based on one person or a segment of customers.
- Focus on a customer outcome, interviewing and observing customers at different stages of the customer journey.
- List the actions (touchpoints) a customer would take to reach that outcome horizontally, step-by-step, for example “initial contact” or “ticket submission.”
- Then list all of the relevant channels that customers connect with while using your service vertically, such as website, email, face-to-face, or telephone.
- Make sure that you capture the customer touchpoints.
- Each touchpoint needs to then be assigned an owner, whether that be the service desk manager, incident manager, problem manager, or someone else.
- Jot down how the touchpoint impacts the customer experience including the needs, perceptions, emotions felt at each stage, and what a successful customer experience looks like.
- Now repeat the process for your ideal customer journey. This can be used to compare the actual to the ideal, to identify gaps in the customer journey.
- Where gaps in customer experience are uncovered, brainstorm improvements and set priority actions.
You can find more detail via Google where a search will bring back “how to” information such as “How to create a customer journey map
Use CJM for the Service Desk or IT Service Delivery
So while ITIL has moved corporate IT departments from a technology-centric world to a service-centric one, more steps are needed if the departments wish to be more customer-centric.
CJM can be a great input to this, getting all team members “on the same page” and encouraging them to think about how to improve the customer experience not just customer service.
Have you tried customer journey mapping and, if so, how was it for you?
Posted by Sarah Lahav
on September 6, 2016 in ITIL
We all know IT organizations that run into difficulties working with their suppliers. They seem to really struggle, enduring fractious relationships and contracts that don’t meet their needs. On the other hand, some IT organizations enjoy positive relationships with a range of suppliers and seem able to get really good value for money. What is it that helps them achieve this? And what gets in the way?
Some Contracts Are Not Perfect
Some of the IT organizations that I work for rely on their procurement department to manage their suppliers. I’ve worked with a number of IT organizations that have less-than- ideal contracts with their suppliers due to typical scenarios like this:
- IT gives their requirements to procurement.
- Procurement negotiates and agrees on a contract with a supplier.
- The contract is not an exact match to the original requirements, as procurement has made a decision based on cost, and the ability to meet what they consider to be the most important requirements.
- The IT organization is then left to pick up the pieces and manage as best they can.
The contract doesn’t meet the required needs, the supplier isn’t helpful, the customers aren’t happy, and IT gets the blame. But it’s not their fault - and the contract has another five years to run.
Good supplier management can help you to manage situations like these. You may be stuck with a poor contract, but that doesn’t mean that you have to put up with poor service from your supplier.
Everyone Needs Supplier Management
All IT organizations need effective supplier management, because they all need a wide range of suppliers to help them deliver services. Sometimes there are suppliers delivering nearly all of the services, in which case these suppliers have to be managed. But even if your IT department has a supplier doing Supplier Integration and Management (SIAM) so you don’t have to, you still need to manage that supplier!
At the other extreme, you may come from an organization that runs all of its IT in-house, with your own software developers, service desk, infrastructure, and support. But you still have suppliers to manage. Even if you use only open source software, with no license restrictions or costs, you still have to obtain electricity and internet connectivity from suppliers. And very few organizations are big enough to deliver their own level 3 operating system support, even if they have open source operating systems.
So what can you do to manage suppliers well?
Three Levels of Supplier Management
There are three different timescales over which you need to do supplier management, and each of these needs a different approach, and each may be done by different people.
|Strategic Supplier Management
||Decide which suppliers to work with.
Negotiate and agree contracts.
|Tactical Supplier Management
||Review supplier performance regularly (usually monthly).
Manage service levels.
|Operational Supplier Management
||Manage day-to day work activities, for example escalating incidents to the supplier or accepting deliverables from them.
Strategic Supplier Management
This is the activity that is often carried out by a procurement department. It involves deciding which suppliers you want to work with and carrying out any legal, regulatory, or compliance checks to ensure that you will be able to work with them. Then, for each individual contract, it involves documenting the requirements, managing a process to enable suppliers to bid for the work, selecting a preferred bidder, and negotiating and agreeing a contract. There may be annual reviews, but usually the strategic component of supplier management will not have anything more to do until the contract is due for renewal. Getting things right at this level can avoid a whole host of problems further down the line.
Tactical Supplier Management
Most contracts include service levels, which are reviewed at regular meetings. Typically, this will be a monthly review, although the frequency can vary depending on the contract. Where there are many detailed numerical performance measures, which are used to set penalties and rewards, this often results in long and bad-tempered meetings where each side is more concerned with proving their point than with discussing the service…and agreement is hard to achieve. (See What behaviour do your SLA targets encourage
for more discussion of performance measures.)
When tactical supplier management is done well, conflicts are much less likely to happen. For example, one organization that I worked with used a simple spreadsheet to rate all of their major suppliers against the same set of criteria, such as:
- Delivering contractual obligations
- Responding to ad-hoc requests
- Customer experience
Every supplier received a monthly rating on a scale of 1-5 against each of these criteria, and every supplier saw not only their own score, but that of all the other suppliers. As a supplier myself, I found this incredibly helpful. I knew exactly where I stood and what my customer thought of me. I was incentivized to be “top supplier” each month, and when the contract was due for renewal I could tell the sales person that we had been the best supplier for the past 8 months. This was a real win-win because the customer was driving me to deliver what they needed, and I was able to focus on the things they really cared about.
Tactical supplier management is the level for facilitating continual improvement of the service. Work with your suppliers to put in place a Continual Service Improvement (CSI) register for each contract, so that you actually help your supplier to get better at doing the things you need them to do. Don’t use this as a stick to beat them with, but as a tool to help them to help you. If you’re not familiar with CSI then try reading The Help You Need to Adopt Continual Service Improvement.
Operational Supplier Management
Sometimes suppliers let us down because we don’t do enough to help them get it right. It is really important to ensure that every time we interact with the supplier, we give them everything they need to help us. If the supplier is running a service desk, then we must make sure they have a good description of the incident; if they are providing support to a project then we must make sure they have everything they need to deliver; and so on. It’s helpful to think about your interactions with your suppliers in exactly the same way as you think about interactions with your customers - from the perspective of customer experience.
It's All About Relationships
You do need a contract to define what the supplier will deliver, and what you will pay for this, but a contract is never enough.
You should recognize that your supplier is entitled to make a reasonable profit on the contract, and they should acknowledge that you are entitled to a decent level of service. As long as both parties agree on those two points, it’s usually possible to find a way of managing any contract deficiencies. If you have a good relationship, then anything is possible! Maybe you can allow them to miss some less important service levels that are difficult to meet, and in return they can focus on exceeding the contractual targets on the things that really matter to you. Maybe you can use continual service improvement to gradually tune the deliverables to the point that they are exactly what you need. The bottom line is that truly effective supplier management helps your suppliers to help you, rather than just giving them a hard time when they miss their targets.
Managing suppliers involves thinking about three levels of activity: strategic, tactical, and operational. Each of these levels makes a contribution to supplier management, but the most important thing you should do is to build a relationship with your suppliers.
If your current supplier relationships are confrontational, based on disputing penalties and rewards every month, then try stepping back and thinking about how you can help your suppliers to help you. If you get it right, then you will both benefit.
Posted by Roy Eldar
on August 30, 2016 in ITIL
I was thinking about incident management
and categories and it came to me that really, every single day, we find ourselves being categorized and pushed into a specific pigeonhole. In fact, it happens so often and naturally that we’ve come to expect it:
- Like in the frequent surveys after online purchases when we’re asked to choose from a pre-set list of responses, for example “good, average, bad,” or “rate us from 1 through 9”
- When we buy insurance or complete a tax return, we must always choose a work classification. If we don’t fit into one of their pre-set categories, then we just have to pick the nearest fit.
- And, of course, when we log a call, even if we (as end users) aren’t presented with a list to choose from, we know the operator, whether human or automated, is deciding which of their little virtual boxes we best fit into. And if it’s via a self-service portal, we’ll end up choosing our own best-fit pigeonhole.
I mentioned insurance above deliberately since a friend of mine just changed his job role from marketing support to a training role. When the insurance company was advised of this role change, the premium increased by 7%. Now that’s the power of categorization!
Categories Help Us Process Data Meaningfully
While we may not always like it, or might feel that it isn’t human-oriented, this kind of categorization is a vital part of getting data and metrics collected, analyzed, interpreted, and used for improvement. Without categories, the data we collect cannot be easily turned into useful information and knowledge. But with categories our technology can process the data. It becomes more science, less art, and we have far easier reporting, trending, and pattern recognition – all of which should make managing the service delivered better, for suppliers and customers alike.
Why Incident Categories Matter
What that means for us in IT service management (ITSM) is that we need to take this seriously, get it right and keep it right.
The most obvious part of ITSM that needs good categorization is incident management (that’s where I started, at the beginning of this blog) – designing, capturing, and maintaining the incident statuses that will help us in our work. While you might think that an incident category only affects incident management folks, in fact the consequences of this categorization are far reaching. And because of the range of impact, one set of incident categorization isn’t likely to be enough. Instead there is usually a need for two sets: opening and closing categories, plus a great deal more of pre-set categorization along the way from one to the other.
Allow me to illustrate that with a simple example. Say you’re trying to create an invoice using a financial support service, but when you print it the figures don’t line up and the total overlaps the edge of the page. For sure, something is wrong, so you call the service desk. Sometime in the future, the support professional who diagnoses and resolves this mistake will establish what caused it. We can imagine it might be the financial software, a hardware issue in the printer being used, network transmission, a mistake by the user, or something else entirely. But at this point, and certainly from your perspective as the caller, this is a fault with the financial service, and it should be categorized that way. If the service manager is not going to be aware of issues, it will look very unprofessional going to a review meeting without knowing how many calls have been logged relating to that service.
Getting the categorization wrong, or failing to categorize in a way that’s meaningful to service managers, will mean that the right information is not gathered and not having the right information inevitably makes other folks’ jobs that much harder.
Reaping the Benefits of Categorizing
On the other hand, once the investigation is done and an underlying cause found and fixed, it’s important to get a closing categorization that matches to the cause. Here you’re more likely to be looking at hardware, software, and the like – and perhaps also identifying the source, age, location, etc. of the offending item. If this categorization is wrong, then it’s hard to pinpoint faulty items and prevent them from causing future issues, like suspect batches or suppliers (internal and external) going unnoticed for too long.
The data collected during incident management needs to be categorized to allow easy and meaningful processing into information and knowledge. We need enough categories to reflect the range and indicate areas for concern; but not too many categories that we make it difficult to select the right one in the limited time we have when logging calls or updating records. It should be an ongoing challenge and balance between too many and too few, and to keep the categories reflecting our needs – and that changes over time. You can read more about that in this blog
by Stuart Rance.
Could This Be a Lever for Your Improvement?
Do your categories reflect your organization’s needs? Do they offer initial matching to the customers’ and the users’ concerns? When incidents and errors are closed, does your categorization match the needs of problem, knowledge, capacity, availability, and supplier management? And if not, who is responsible for getting it right? And do they have the budget, support and understanding to make it better? If they don’t, then your ITSM performance will not be anywhere as good as it could and should be.
Posted by Dena Wieder-Freiden
on August 23, 2016 in Service Desk
I recently ordered some items from a web site that I’d used before. The checkout price was $30, which I paid with a credit card and then forgot about it and got on with life while waiting for the items to arrive. A few days later I was checking my credit card statement, and there was the transaction, but at $31.85! Of course $1.85 isn’t worth too much effort, but it wasn’t the money, it was the principle. So I went back to the website and submitted a ticket pointing out the error. Within 30 minutes, I had a profuse apology and compensation with $10 worth of freebies - nice!
Truth is, I made lots of purchases lately, but all of the other purchases were below my attention threshold in terms of service. I clicked to place the order, and then I clicked to make the payment. That payment left my account as expected, and the goods came to my door, also just as expected. They were perfectly ordinary, everyday purchases. I might talk to my friends about what I had bought, the good (or not-so-good) price I paid and so on, but I wouldn’t mention the service quality.
When you think about it logically, that is what good service should be – all but invisible, delivering what you expect without fuss or incident. So, why was the one transaction that went wrong the one I ended up most impressed with? Certainly it has a lot more to do with human psychology than service performance, but still very relevant to anyone working in the IT service management
Failure Facilitates Good Service with Fixers as Heroes
As you can imagine, I was thoroughly delighted and impressed by the speedy, polite customer service of the company that accidentally overcharged me. I was happy to get some extra products for free and enjoyed telling my friends what great service this company offers.
But here’s the conflict then. The companies that got it properly right, I didn’t praise and publicize. The one that got it wrong, but corrected it nicely, is the one I felt most pleased with. So is the message here not to be too good? Should we strive for minor glitches and good fix rates, or should we aim at delivering what we’re supposed to?
Of course, for some services, in some situations, you’d feel that ‘getting it right’ without fuss or visibility is essential. Think of open heart surgery or flying a plane. And yet, even then, one of the great recent heroes is the pilot that landed the crippled plane on the Hudson River
. I also recall a conference with three great motivational speakers – all of whom had failed to do what they set out to do but were impressing folks with how they had dealt with the failure.
In fact, if you look at the way many ITSM teams operate, they do still give more emphasis to fixing failure than preventing unplanned occurrences. Ask someone to talk about what ITSM covers and many will still start with the service desk, incidents, and fixing faults. Is this a failure of ITSM culture? Instead of having things fail and then fixing them quickly, shouldn’t they focus on actually delivering without any mistakes, making life as easy as possible for the customers? Too often, correcting failures drives customer appreciation more than just seamlessly providing services or goods without any mistakes.
Should We Step Down from Perfection?
If we’re too perfect, will we be so unappreciated that we find we’re no longer seen as valuable and be punished for our success: de-funded, outsourced or passed over for promotion?
Perhaps one key to solving this conundrum is by education: making customers and staff realize what true success should look like. We all need great fire-fighters available should the fire break out. But we don’t really want to see them in action. What we want is smooth and effortless service. Perhaps I’ll go back and check on all the other suppliers who did deliver and start telling my friends how good they are!
Where do you stand in this conflict? Do you worry more about fixing errors than keeping them away? Do you put effort into making your staff see that their prime job is service delivery, not service repair? Or are you pragmatic enough to let things break a bit, to show how well you can fix things? Maybe you’re even tempted sometimes to break them, engineering a situation to showcase your fault-fixing prowess? No, of course you wouldn’t :).