24 September

No matter where we work, why is it that we always complain about our IT helpdesk, or the service we get from our IT software vendors? I’ve worked in the industry for two decades and it seems we’re never happy. I’ve also worked with the IT Services teams. From their point of view, they’re often frustrated by bitchy customers who don’t know what they want, and really have no basic clue about how systems work. Despite their patience and calm demeanor while on the phone, as soon as the call is over you’ll sometimes hear your friendly Customer Support Representative crying howls of anguish (or much worse). I’ve occasionally had to send a few outside for a few minutes just to calm down.

Okay - let’s face it, computers and IT systems are inherently frustrating things. When things go wrong they can go majorly wrong, without any clear or obvious reason. And, from a user’s point of view, it’s sometimes hard to figure out just what the system designer was thinking … or if maybe they were on some mind-altering substance.

As a provider of IT services or software, what are the basic rules to apply?

1. Clear Communications

This rule is the most important - have clear communications with your customers. Find out what you can about the problem (so you can diagnose) and the customer impact (so that you know how critical it is to get an answer or rapid workaround).

• Listen to your customers patiently before you dive in and try and give them answers (even if you’re 99.9% sure you know what the issue is). Sometimes, the opportunity to explain their problem and frustration is almost as important as getting the resolution. And, if you don’t actually listen to your customer’s descriptions, there’s a risk of jumping to the wrong conclusion and missing the real problem entirely.

• Show empathy with your customers … although don’t overdo it, or you run the risk of appearing condescending.

• Communications also need to go the other way. If problems have been identified which are likely to have a (significant) effect on other customers - let those customers know! Most IT Services teams will have standard notification templates for this. You’ll need to use some judgement, as its unlikely that customers want to be spammed about minor issues - or something with a very short duration.

• When significant issues do occur (and even if you’re not yet sure about the cause) send out the communications anyway. Customers at least want to know that you’re onto the issue and you’re doing everything in your power to resolve it. If you can’t promise an ETA for return to normal service, at least give them an ETA for the tasks now in progress - and for the next service update.

• Tailor your response to the customer. For most customers, talk in plain English and use the appropriate business terms. Other customers may be power users, or more technical, so will expect more detail - and a demonstration that the support team working on their case actually understand the problem and know what they’re talking about. Of course, tailoring the message necessitates you knowing your customers and understanding their needs.

Another often overlooked point is that it’s important to still have communications with your customers or stakeholders even when there aren’t major production issues to discuss. If you have key stakeholders, consider booking a regular fortnightly or monthly meeting with them. This provides a forum for discussion of upcoming activities, new releases - or upcoming business activities on the customer side which may need extra support coverage, backup or planning so as to reduce the business risk. Importantly, this regular communication fosters a good relationship, and better understanding of the issues and impacts on both sides. This can be invaluable when things do go wrong.

PS: For those regular meetings (if your customers are nearby) - agreeing to meet in a coffee shop close to the customer premises can help the atmosphere. People tend to be more relaxed and happier when they have a fancy coffee or juice in front of them (especially if it’s your turn to pay). This helps ensure a civil and lower stress atmosphere, and reduces the risk of shouting matches if things have gotten out of hand in the past.

2. Clearly Define Your Support Services, and Service Levels

The next golden rule is to appropriately set your customers’ expectations. Clearly define what your service does (and, in some cases, doesn’t) include. Unless you do this, your customers are likely to invent their own service definitions - which will be tougher to live up to.

A 100% reliable system is near impossible. Where this service level occurs, it’s only as a result of very careful planning and (expensive) failover systems. Unless these mechanisms in place and proven, don’t promise this level of service. Instead, come up with a Service Level Agreement that’s actually achievable.

• Specify the system availability (say 99% of business hours)
• When systems aren’t available, specify an escalation process and a communications plan.
• For reported problems, specify an initial response time and a frequency for communications updates.
• You can’t guarantee a resolution time (it depends on the problem) - although you might be able to set a target timeframe that applies for most problems. Only do this if you think its genuinely achievable. For example, if your resolution times depend on external factors, or actions from customers uploading files for diagnosis, then it’s best not to make the promise … simply stick to the stated initial response time and frequency of updates (and highlight in your SLA that your overall resolution times depend on external factors or customer actions).

It’s also important to define the problems that you’ll take responsibility for (and those that you won’t). Have this built into your support contract and easily accessible on your site.

For example: If you’re a vendor supporting a software product, you might choose to provide support for the identification and resolution of configuration issues and bugs, but not cover basic usage or training issues. However, if your users log issues that are unsupported, don’t leave them stranded. At least have a prepared answer to point your customers in the right direction - instructing them about the process or contacts they need to take things further.

3. Demonstrate Achievement of your SLA Promise

Perception is everything - and a little positive reinforcement goes a long way. The service desk should log all reported issues, and generate statistics showing your level of SLA compliance.

1. This helps your internal management team and,
2. (Assuming its not too embarrassing), share this information with your customers. In an ideal world, customers should be able to generate their own individualised reports showing a full list of the issues they’ve logged, with summarised SLA statistics.

Publicising your SLA standards lets customers know what to expect. Demonstrating compliance shows that you mean what you say, and builds customer confidence in your ability to deliver.

Note: Statistics can be skewed by the behaviour of those who do the recording - as is well known to anyone who’s run a performance incentive programme. Therefore, regularly review your case histories to make sure stats aren’t being skewed by behaviours such as closing old cases then re-opening them under new case numbers. Customers quickly cotton onto these tricks. It just increases their level of cynicism - so don’t do it.

4. Understand Your Products(s), Your Customers, and the Nature of Your Support Calls

One of the companies that I recently consulted for had a range of complex engineering design and simulation products. These were used for the design of mines and mining processes - including management of the haulage fleets using those super-sized mining trucks. These were (are) fantastic products - but problem is that the questions we got on the helpdesk were also super-complex.

• The software installation and configuration questions were simple enough - BUT
• Other usage-related questions and diagnosis of potential bugs required someone with an engineering degree and 5-10 years of mining experience.

Catering for these situations was the problem. When our customers called, their expectation was that they were talking with someone as knowledgeable and experienced in mining problems and processes as they were - or even more so. However, staffing our helpdesk with high-end mining engineers was unproductive (and expensive) given that the vast majority of calls still dealt with minor installation and technical issues.

Therefore, the trick is to structure your support team and internal escalations accordingly. Staffing our Level 1 helpdesk with trained IT Support staff was best for the majority of the calls - although we needed to ensure that these staff had sufficient training in the products and mining processes/terminology to know (1) what the products were being used for, and what our users were talking about, and (2) what questions to ask about the product and how to re-create users’ actions in order to try replicating the problem.

A Level 2 escalation was then established allowing complex problems to be forwarded onto trained mining engineers. This meant that engineers only got the problems that really needed their attention and expertise. They could then spent their time focusing on users’ models and scripts, and running scenarios to investigate users’ reported problems. Because they understood the engineering principles involved, they were able to identify situations where the software was applying the wrong rules or running activities out of order - or where the problem had been created by users using incorrect/incomplete data or models. They were then able to engage with users to help them correct their models, provide interim workarounds, and specify permanent bug-fixes/enhancements needing to be implemented by the development team.

Level 1 and Level 2 both had customer contact - and tools for remote connections to customer desktops to observe, replicate, analyze and resolve issues. Our Level 3 support consisted of the development team who understood more about specific software issues, memory management, performance tuning, and operating system requirements - but who very rarely ever had direct customer contact.

Therefore - the overall support structure was geared to the nature of the problems coming in, and our customer needs:

• Sometimes they need to talk with a helpdesk analyst to deal with (relatively) simple issues, and
• Sometimes they need to be escalated to a formal engineer who understands the specialist subject area in which the customer is operating.

The trick is being able to determine which of these two scenarios apply, and to treat the call accordingly. There’s also the issue that escalated calls are more complex and more time consuming (and hence, the engineers aren’t as readily available as we’d like). Therefore, even on the complex engineering calls we try to do as much as we can using the Level 1 team. This includes having them ask the right diagnosis questions, collect any required artifacts such as users’ file and models, computer specifications etc - and then trying basic steps to replicate the issue. This means that when the case gets bumped to Level 2, the engineers already have the info that they need and can hopefully turn the call around quicker.

The downside to this approach is that the engineers are recognized by customers for their expertise. Therefore, even for minor problems, our customers had a desire or expectation of being escalated directly to those engineers. We’d also get calls from users wanting basic usage advice, wanting their scripts debugged, or opinions on design options for the models and engineering solutions they were developing. This is where the definition of service (see point 2) comes into effect - with a polite reminder to customers that this is outside the support scope, and a redirect to appropriate training or consulting services.

Note: In situations where you have a specialist escalation, you need to ensure the skills of those specialists. Although it’s tempting to staff that specialist desk with (relatively) cheap fresh-faced graduates, it’s important to have one or two grizzled and experienced engineers also on hand - and a training programme to quickly bring the new graduates up to speed. This helps guarantee the integrity of your team and the quality of their advice.

Structures and processes should be appropriately tailored to your organisation and customer needs. For example, in another team specialising in support for internal Business Intelligence and reporting applications we had a generic helpdesk (since our users called a single helpdesk for all IT-related issues or requests), with subsequent escalation to our internal BI Support team if these issues/requests related to our systems.

• WIthin our team we had individual specialists who understood the nature of specific datasets or data feeds (although we purposefully cross-skilled these team members to ensure ongoing coverage even when key people were away).

• These specialists were backed up with ready access to DBAs with specific knowledge about our platforms and databases (they’d all been trained and served an apprenticeship period on our systems - even though some of the resources had been outsourced to an Indian IT company), plus we had other network engineers, and source system experts as required.

• Finally (where possible), we also had good relationships with business teams and had access to Subject Matter Experts (SMEs) within those teams. They could help translate the business issues into something we could understand, provide business impact statements, and other general advice. This was important because when discussing user-reported issues with those SMEs they were able to highlight that the problem was due to users not following proper business processes, entering invalid data or report assumption, or maybe the business processes themselves were wrong and needed to be refined (or just communicated better to the user community).

5. Provide Self-Help, FAQs and/or a KnowledgeBase

When operating a helpdesk, you’ll invariably find yourself getting the same or similar questions repeated time and time again. Writing these down and sharing them with your helpdesk staff helps - but, even better, share those answers with your customers via an FAQ or KnowledgeBase. The idea is to build a resource so that they can find their own answers to common issues and reduce the number of times they call you.

Publishing these self-help answers reduces your workload (so that you can concentrate on the calls that you really need to be answering), plus its available 24x7 meaning that customers often still get answers even when you’re busy or not around. This helps reduce customer frustration and improve satisfaction with your products are services.

Regularly review your FAQ/KnowledgeBase - keeping it up to date, and keep adding material. This creates a useful repository for your customers - and for your support team.

Finally - if you have the capability to do so, link your KnowledgeBase into an online Customer Support portal. This isn’t too hard to build - and can be linked in from off the shelf CRM and Helpdesk systems such as Salesforce.com/ServiceCloud and Force.com. This enables customers to log their support calls online, check progress, provide updates/responses and check support history (such as review details of support calls logged by colleagues if they’re part of the same organisation). Again, this not only reduces workload but it greatly increases convenience to your customers.

6. Use Customer Feedback to Stabilise and Improve Your Systems

Several years ago, I took up support responsibility for an internal application that was clearly on its last legs. The problem was that this system was also too expensive and too complex to replace … in the short term, at least. Our user base was decidedly grumpy - since they’d been ignored and experienced bad service for years. The support team that I inherited was also at a loss for what to do. They’d spent big money adding new features and subsystems - but without much to show for it based on user perceptions.

The next year or so involved getting the system support up to scratch, and improving communications with our business users. Rather than big re-developments (which were impossible in our resource-constrained environment) we set about a strategy of gradual fixes and updates to improve performance and enhance stability. Whenever something broke - which was often - we wouldn’t just fix the immediate problem. Instead, while we were rummaging around in the code and procedures, we’d take a look at the root causes and the component design - tuning and re-engineering these components to make them better. That way we stabilised the system to keep it running a while longer. This bought time for us to work with our customers to build momentum with the business case and funding for an eventual system replacement. This process took us two years because of the expense and scale of change involved (and to score the incriminating photos of senior executives which sealed the deal). Ongoing small changes to improve system stability, and actively working with users to prioritise and focus our efforts was instrumental in this achievement.

Customer feedback is important. Encourage it, and use customer priorities as the key determinant for which fixes and enhancements you’ll apply next.

7. Consider ITIL Processes

If you’ve worked in IT Support, you’ve probably heard of ITIL (Information Technology Infrastructure Library). It’s a conceptual framework for the management of IT services – and alignment with business needs. It grew out of a series of standard practices and recommendations instituted by the UK government Office of Government Commerce after they realised that government agencies and private sector contractor all independently created their own (inconsistent) IT management practices. ITIL is now the dominant framework for managing IT services.

ITIL is fairly general - and its not a detailed “how-to” for delivering a perfect set of IT services, since every organisation and customer base will have their own specific needs. The important thing with ITIL is that it contains the necessary concepts and terminology so that you can examine your own support processes in detail - comparing and contrasting those with those used by other organisations, and refining them accordingly.

You don’t need to follow ITIL religiously. It can be prudent to adapt or streamline these processes, making them a better fit for your business or environment. However, knowledge of the ITIL framework is a huge help when designing these processes and considering possible alternative options.

More information about ITIL is available on the official site at: www.best-management-practice.com.

8. Remember: Your Overall Support Goal is Helping Your Customers to be Successful

The key to success is by ensuring that use of your products or services helps your customers to be successful.
This means:

• Products are easy to use (or services are easy to access).
• Customers successfully use your products/services to achieve their business objectives.
• You deliver value to the customer or their organisation.
• Your customers achieve greater success that those without your products or services (or those using your competition)

You can ensure the retention of existing customers by:

• continuing to deliver on customer needs (and keeping ahead of competitors’ products) and
• ensuring satisfaction with functionality, quality, and value of your products/services.
  

Customer retention provides ongoing business revenue, and limits the opportunities for your competition.

Tags: Support