The Customer Manifesto

The terms of an IT relationship are classically dictated by the vendor – yet our IT systems are critical to our business. It’s time to revolutionise the relationship – The Customer Manifesto shows you how…

We have given our technology vendors power over our organisations. Look what happens when a mission-critical system goes down – the business has a heart attack. The ERP system goes down – our production line stops. The billing system fails – we can’t charge our customers. The database crashes – we don’t even know who our customers are.

This imbalance of power exists throughout the vendor / customer relationship. We see it in projects, as we wait for our vendors to tell us when our new systems can come on line. In people, as we recruit technical people on their skills rather than their fit with our business. In money, as we are locked into pricing arrangements that would make Scrooge green with envy.

We are becoming vendor victims. And as we rely more and more on IT, it’s going to get worse – unless we do something about it.

What can we do? Begin by recognising that most IT vendor relationships only become established after the sale – when the vendor supports the systems they have sold. Yet who sets the terms of the support relationship? All too often, it’s the vendor.

We’re not talking here about service level agreements or contracts – although these things are critical. The key word here is relationship. It’s about setting expectations for behaviour, and not accepting anything less. It’s about expecting our vendors to be professional – but explaining to them what that means.

Seven rules govern effective mission-critical support relationships. We have identified these rules through close observation of support relationships from both customer and vendor sides. Customers escalate because the vendor violates one or more of these rules.

Any mission-critical customer should reasonably expect their technology vendor to:

1. Support the customer
2. Deliver consistently
3. Guide the customer
4. Troubleshoot incisively
5. Be fast
6. Prove it
7. Get ahead of the curve

Together, the seven rules comprise a customer manifesto – a blueprint for the customer to take control of the relationship and restore the balance of power. How?

1. Support the customer.

In the mission-critical world, the vendor supports your business, not just your systems. When a system goes down, you need the vendor to do whatever is needed – not just to get your systems back, but help get the business back up and running.

For example, a warehouse server in a distribution company was crashing intermittently. Each crash cost the company tens of thousands of pounds of lost business. Their hardware vendor proved that the problem was neither the hardware nor the application. Despite this, the vendor continued to support the customer on the problem – and helped prove the true cause of the problem: sabotage.

Have the vendor support your business. Good questions to ask your vendor:

• At what point will they pull the plug when supporting an incident? (Is this acceptable?)
• If an incident cuts across several technologies, will they manage the incident for you, no matter which vendor is eventually responsible?
• Can they practice / rehearse managing a major incident with you – and change their processes as a result?

It may be their systems, but it’s your business. Remind them.

2. Deliver consistently.

If I have a heart attack, my survival should not depend on whether I am treated by Dr. Smith rather than Dr. Jones. I expect every doctor to be able to treat me consistently and well. When our organisation has a heart attack, should we expect anything less from our vendor? In particular, what specific, clear and effective processes do they have in place to get our business back up and working, no matter who is dealing with it?

One systems supplier, for example, sets up a “War Room” whenever a mission-critical customer has a crash. Each person in the Room has a specific role and they work systematically in these roles to diagnose the problem and restore service. Regardless of who is taking what role, the War Room works the same way – by the numbers.

Raise the standard. Ask:

• What standards does your vendor have for incident management?
• Do they know the standards you expect them to meet?
• What processes do they have that ensure that their support success does not depend simply on one or two individuals?

It is your business. You should set the standards.

3. Guide the customer.

On TV, when the police want to raise the anxiety levels of a suspect in an interrogation, they ask a question, get an answer, say nothing and leave the room. As the silence builds, the suspect worries about a number of things, but mainly “What else? What next?” When the police return, the suspect is climbing the walls with worry and desperate to confess.

It is astonishing how many vendors adopt a similar “question/silence” routine. They ask questions about a serious crash and then go off-line to “work on the problem”. You don’t know why they asked what they did, what they are doing with the answers, or what they will do next. No wonder you escalate!

Some vendors, however, guide their customers very well. One software vendor uses a consistent troubleshooting process to structure diagnosis of mission-critical crashes, which they share with the customer. This means that on every customer contact, they explain what information they need, why they need it, what they will do with it and where they are going next.

Reduce anxiety. Improve the ways your vendors guide you during major incidents. Ask them:

• What questions are their people trained to ask when diagnosing problems?
• How will their people explain during an incident what information they need, why they need it, what they will do with it and what they will do next?
• What is their diagnosis roadmap – and can they share it?

You want every step in their diagnosis to be transparent. No surprises.

4. Troubleshoot incisively.

Many mission-critical problems are escalated because the vendor’s knowledge runs out. They might never have seen a problem like ours before, or the problem may be unusually complex. Classically, vendors throw a series of fixes at such problems in the hope that one sticks. Most fixes fail. Worse, they can cause more grief than the original problem.

It is possible to troubleshoot mission-critical problems consistently. A financial services company had a system that crashed intermittently during its end-of-day reconciliation. The crash forced them to employ hundreds of temps each night to complete work by hand so that they could trade legally the next day. This was a major effort that they did not want to repeat. The problem was complex, so the vendor used a diagnostic protocol that they shared with their customer. The protocol guided them to minimise unnecessary system changes and they fixed the problem efficiently.

Guide the customer. Help your vendor to solve the problem. Ask them:

• How do they prevent their people from adopting a scattergun approach – firing off failed fix after failed fix?
• What standard information do they need from you whenever there is a major incident?
• When they capture problem information, can they share that with you immediately, in a structured format? (It might allow you to correct misinformation and improve the chance of quick success.)

Is every incident managed using similar questions in consistent ways? No? Then they still have some way to go.

5. Be fast.

The emergency services save lives against the clock – but they cannot afford to get it wrong. These two conflicting pressures mean that they use consistent processes for most common situations and follow them strictly. Time is too tight, and the stakes too high, to improvise. Following their processes is the fastest way to get the job done.

We need the same discipline from our vendors. When the problem is critical, we can’t afford for them to get it wrong.

For example, there is a hardware vendor that requires mission-critical customer problems that are more than two hours old to be escalated to their most senior engineers. To help these engineers hit the ground running, and to minimise the time they spend going over old ground, the company insists on a standard set of problem information to pass to them. This step has improved their time to close customers’ problems by an average of 52%.

Move your vendors onto the fast track. Ask them:

• What automatic processes kick in when you notify them of a major incident? (Think fire brigades or Formula 1 pit crews.)
• How often do they practice these?
• How often do they review these processes to make them faster?
• What is the best way that you can help them fix your problems faster?

Track the average duration of mission-critical incidents. If it’s not going down, then they’re not answering these questions.

6. Prove it.

With apologies to Oscar Wilde, “To crash once may be misfortune, to crash twice is carelessness.” If our business has been damaged, then we should expect our vendor to prove why it happened – and why it won’t happen again. Many vendors take their foot off the gas once the immediate problem has been solved.

Yet some vendors do it right. After any major incident, one systems supplier gives its customers a standard analysis report that describes not only what the root cause was, but how it has been proven and what they are doing to ensure that it won’t happen again.

Give your vendors the burden of proof. Ask them:

• How do they know they have found the root cause?
• Which assumptions are they making about their purported root cause?
• What other possible causes have they considered?

Track the number of your problems that recur over time. If this number isn’t going down, then those root causes aren’t root causes.

7. Get ahead of the curve.

Many problems are preventable: perhaps we need to do something differently; perhaps we can learn from other people’s problems. We need our vendors to help us avoid problems, possibly even more than we need their help to fix them. It is a pity, therefore, that vendor support organisations tend to offer very little proactive help.

There are some exceptions. One server company, for example, has created a cadre of technical specialists whose sole job is to help prevent their customers’ problems. Their customers have fewer problems, they get fewer escalations.

Prevention is better than cure. Ask them:

• What percentage of their support effort is given over to preventing problems, rather than reacting to incidents? (Is this percentage acceptable to you?)
• When they propose changes, what do they suggest to prevent the problems these changes might cause?
• When they fix their problem, how do they know that this is only system that needs that fix?

Vendor support is notoriously reactive. They need to think ahead. Don’t be afraid to help them do so.

The Seven Rules of Customer Support do not solve all support ills, nor are they easy to make happen. But if we do not engage with vendors to improve their performance, then we have to accept things as they are, downtime, business impact and all.

Many vendors do well against some of these tenets. Few, however, succeed against all seven. This is not good enough. We have entrusted the life of our businesses to our technology vendors. We have accepted their rules for support. No longer. Our businesses are too important for that. It’s time to change the rules.