5 Reasons Why Support Engineers Don’t give Strategic Customers the Royal Treatment

Continuing our 5 Reasons series, this month we talk about why support engineers don’t seem to be able to deliver a white-gloves level of service to strategic customers. This can lead to poor prioritization decisions, a lopsided balance of effort between the cases of strategic and non-strategic customers, and a lack of proactive escalations on strategic customers’ issues, leading to serious  commercial repercussions.

True, some support engineers favor an egalitarian approach to support, and we’ll discuss how to handle that (relatively rare) belief–but most of them would just love to do the right thing, if they only knew what it is and when they should do it. Read the 5 reasons why the gap exists and what you can do for each of them.

1. They don’t know who the strategic customers are

Sad, but true: it’s often impossible to tell from the case-tracking system what tier a customer is in, and even when it is possible, it can be difficult and time-consuming to actually find the information! Over time, by osmosis, support engineers may learn who the strategic customers are, but newer engineers, along with those who don’t care much about the commercial side simply don’t know.

The cure is simple: make it obvious who the strategic customers are. The criteria are not that important for the support engineers to understand, although I always recommend complete transparency for those interested, but do all you can so support engineers are never in a position to be scolded for not knowing that they were working with a strategic customer, or one that’s at-risk. Keep the classification simple: if there are too many levels and shades of special customers, no one is special anymore.

Lesson: Clearly label strategic, special, or at-risk customers

2. It’s not clear what they should do differently with strategic customers

Imagine that you’re a support engineer who knows that the case belongs to a strategic customer. What now? Am I supposed to forget the other cases in my queue and just work that one? Are there different rules on what is in scope or not? Will the Engineering team treat bugs or feature requests differently? Is there a different threshold for escalating the case to my manager? I need answers!

Take the time to map out exactly what needs to be done differently with a strategic customers. Automate all you can. For instance, it’s easy to set a faster response time for strategic customers, or automated routing to senior support engineers. That will work well behind the scenes, with no burden on the support engineers themselves. And avoid complicated “special cases” instructions. They waste so much time to read them, they can be confusing, and they easily become obsolete to boot.

Lesson: Specify exactly how you want support engineers to handle strategic customers

3. They are just too busy

Even rule-following engineers only have so many hours in their day. If delivering the bend-over-backwards service you defined in step 2 means that they essentially have to drop all their other cases and customers, they just won’t do it. You have two options to handle this challenge: compartmentalizing and automating.

Compartmentalizing simply means separating the strategic customers from the others and making sure they have access to many support engineers who have the time to deliver the level of service you want. Think airline cabins, where business-class passengers are pampered and economy passengers are treated more like cattle.

Automating means taking care of all the issues that can be taken care of through self-service or an assist to the support engineers. Automating is good for everyone: strategic customers, non-strategic customers, and the support engineers. In the airline industry, even business-class passengers love self-check in, luggage tracking on the app, and being able to reserve meals in advance (that last one is beloved by the flight attendants, too.

Lesson: Consider a separate team just for strategic customers’ support

4. The incentive structure doesn’t reward giving extra TLC to some customers

Support engineers, especially when overworked, are very much driven by metrics. If they have a quota of cases to close, or some KCS work to do, why would they spend extra time indulging a strategic customer when they could instead zip through their other cases, and gather good CSAT surveys to boot? Take an honest look at the metrics you are using: are you unwittingly rewarding team members for speed over quality? This is especially problematic if cherry-picking is allowed as some support engineers will avoid strategic customers altogether, along with all known “difficult” customers.

If you can’t quite arrange incentives to reward instances of white-glove service, the solution may again be to compartmentalize, giving different incentives to the “premium support” team members that do allow them to spend more time on each case.

Lesson: Align incentives to the level of service  you want to deliver

5. They don’t believe that some customers are more special than others

I kept this reason for the end because it’s a little more delicate to tackle–and not as widespread as the others. Some support engineers have a powerful sense of equity that pushes them to treat everyone equally and makes them leery of providing extra privileges to certain types of customers. They feel very strongly about it, and will let it be known.

If you have a dedicated team to support strategic customers, this concern mostly fades away (although, even within the group of strategic customers some will be more strategic than others!). Regardless, I’ve found that a good open discussion about commercial implications is very helpful. Support engineers tend to have strong analytical minds and they do grasp the need to maintain a good stream of revenue.

Lesson: Be prepared to have candid conversations about revenue and profits

How are you set up to handle strategic customers? Please share what’s working, or not.