Getting customers to actually contact Support
Do it now or regret it later
I recently had a conversation with a support leader colleague who is inaugurating a new support function at a growing startup. As such, he’s working on building out all of the procedures and tooling from scratch, and our conversation quickly turned to: how do you get customers to actually use all these shiny new tools and support paths? All of the customers are so accustomed to just emailing the founders directly that they see no reason to change. And while it’s great that the founders are still willing and able to interact directly with the customer base, it’s not sustainable long-term. They need to find a way to gently guide customer questions and problems into the channels designed for them, rather than taking hours out of the already-busy founders’ days.
As we spoke, we quickly came to the understanding that all of the ways to make this happen slot pretty cleanly into the traditional categories of positive and negative reinforcement. Encourage the behaviors you want to see, and discourage what you want the customers to stop doing. So if you found yourself in this situation—I certainly did when building a support function from zero—how do you get customers to stop bothering founders, engineering, or their account executive every time they have questions that your shiny new support process is better equipped to handle?
It comes down to one fact: customers (everyone, really) will choose the path of least resistance every time. If they’re used to talking to one particular person, especially if that person is helpful, they’ll keep reaching out to that same person until it becomes too difficult or unrewarding to do so. Therefore, the best way to get customers communicating with the support team in the way you intend, make it as easy as possible for them to do so.
Positive reinforcement
When you’re in this situation, customers already have a solution that works for them: they email (or call) someone they already know, someone they know has the power to solve their problem, and that problem gets solved. The first step to start changing that behavior is to make other methods (e.g. the actual support process you’ve gone to some trouble to build) more attractive.
Fast, accurate responses from approved channels: if customers can get a quick response from emailing the support@ address, or sending a message to a shared Slack channel, or starting a website chat, they’re going to be more willing to use that channel in the future. Conversely, if they get an auto response and no actual answer until the next day, then why on earth would they do it again instead of just emailing (or calling) the founder who sold them the product in the first place? Consistent fast, accurate support is key to getting customers comfortable with using the support process as a first resort.
Bonus functionality: one of the major selling points of building a full support process is that it lets you do, and see, lots of things that just aren’t possible with ad hoc emails. The more benefits to the customer, the more likely they’ll start using the new system. For example, most ticketing systems have a concept of a customer portal, where customers can see the status of all of their open issues. This can be a huge timesaver for customers (and particularly local administrators on the customer side) who would otherwise have to regularly reach out for status updates on all of their open support queries. Slack or other chat-based support modalities have the benefits of immediacy and direct integration with tools (chat systems, web browsers…) the customer is already using. Lean on the convenience and functionality benefits of the support communications methods you want your customers to be using.
Negative reinforcement
Enough of the carrot—let’s talk about the stick. Often it’s not enough to make the approved support path more attractive to customers. At that point it’s necessary to also make the existing methods less attractive to them. I’ll say this at the outset: this can be hard, though more psychologically than logistically. The reason is simple: we all want to help customers. That goes triple for founders. Those first few customers they’re still helping out with support issues are especially precious to them, and all of the following measures are going to be painful. But it has to happen, because founders, engineers, etc. all have much more important things to be spending their time on. They hired you to build and run a support team—these measures are necessary for you to be able to do your job.
The founder has to want to let go. If they (or the engineer, or the account executive, or whatever) doesn’t see the problem with continuing to field support inquiries, you’re not going to get very far. Sit down with them, lay out the facts, and get them onboard with gently transitioning these interactions to your team.
Always redirect to the established support channel: even if non-support people continue to assist with support issues, make sure they are regularly reminding the customer that the support team exists and is the best way to get questions answered. Maybe an email macro with some boilerplate about ‘we’re proud of our excellent support, contact them here:’ would be more comfortable for your founders, or cc’ing support@ in their response to the customer. Keep reminding the customer that there’s a better way, both in direct conversation and via email.
Enforce a slow response from non-support people. This one can be especially difficult, for reasons I already enumerated above. But if your founders can force themselves to just not respond for a few hours, or a day, this can throw the swift, effective support response into greater relief.
If all else fails, get more aggressive. If you can talk them into it, founders or other non-support people receiving support messages can just forward them to the support team with no comment, or stop responding entirely to those messages. It’s the nuclear option, and is probably not going to please the customer, but sometimes desperate measures are necessary.
Other notes
It’s easier to avoid this going forward with new customers: just don’t give them the option to reach out directly to non-support folks. Point them to support@, or the customer portal, or set up a shared Slack channel, and be done with it. That being said…
This can still happen with new customers: more than once I’ve encountered customers continuing to email their account executive (AE), or their sales engineer (SE), or whoever they’re accustomed to communicating with. The same pointers above can be valuable in this situation too, and it can be just as hard at times for an AE to hand over a customer they went to great lengths to build a relationship with. What can help in this situation, and is generally a good idea anyway, is to include a formal support handoff during the new customer onboarding process. On one team I was a part of, the SE and deployment engineer both went through any outstanding support issues live on the call and officially passed them along to the support team, with an opportunity for the support engineer and customer to add any additional questions or commentary in the moment.
When you’re building a new support team, it can be difficult to transition over existing customers who are already perfectly happy with their direct line to a founder. But if you don’t take steps to get them talking to the right team when they have issues, the day will come when they have a major outage or other serious issue, can’t reach their usual contact, and are at a loss for how to proceed. Don’t let that happen!
Thanks for reading Andy's Support Notes 💻💥📝!