What we talk about when we talk about support

Usually, your support people toil separately from the people actually responsible for the design that ships. Yet the final design is usually responsible for the volume of support inquiries you get in – and the stress that your support team feels.

It stands to reason that the silo between support and production should be broken down. The outcomes are manifold:

• You reduce support load, which means you end up with less stressed support staff, yelling about the same things over and over.
• You get happier customers, who are more likely to recommend your products to others.
• You spend less when you have to get items RMA’d, or when you have to re-ship to customers.

Yet I see few people (outside support, at least) talk about this, much less actually do it. Perhaps they believe that support people lack the strategic know-how to really drive the business. Perhaps they don’t have a process in place for ensuring support people can talk to the rest of the team. Perhaps the support team is just too busy with their hair on fire to actually think of reaching out.

No matter the reason, support siloing happens, and it sucks. If you run design research to drive conversion in your store, your support channels can provide a perfect opportunity to surface oft-recurring issues, mine support inquiries to shape the product’s message, and drive outsize beneficial outcomes for the whole business.

First, define a publicly viewable channel for support inquiries

Think of your business’s support channel as the flip side of post-purchase surveys. Everyone goes into a transaction with good intentions and high hopes. Support is how your business triages things on the unfortunate chance that they go wrong.

New tickets should be funneled into a channel on your Slack team, with corresponding links for your team to address the inquiry.

If you’re tasked with researching and planning new design decisions, you should subscribe to your company’s new support tickets as well, and make a point to check in on it every week. (Mondays are a good time, since you’re usually planning out the week’s to-do then.)

Then, establish a recurring 1:1 with your support director

Talk with the person who bottom-lines support in your business, and establish a recurring half-hour checkin with them, at least fortnightly.

The goal of this meeting should be for the support director to surface the biggest and most frequent issues that they faced since your last meeting, and for you to come up with strategies to potentially head this off in the final design.

For example, a client of ours encountered some objections from customers that they were not sourcing ethical or sustainable materials for their products. This wasn’t true; they had sustainable processes for their whole supply chain. But the store probably did an insufficient job of explaining the provenance of their materials.

So, we worked out a series of changes that would address these concerns, and made a point of highlighting it in our social media and mailing list.

We wouldn’t have known that this problem even existed without talking to support.

Remember in this meeting that you should listen, not solve – at least, not right away. Try not to commit to specific design decisions in the heat of the moment; they usually require time and headspace to solve definitively.

Set those expectations with your support manager before the meeting begins, and indicate that you’ll spend time thinking through a solution with the rest of the team.

This meeting is also a good time to present any prior situations that you might have addressed since your previous meeting, so your support team can get a sense of what’s changed, how, and why.

Next, start sharing and synthesizing

From your meetings and your weekly check-ins with new support inquiries, you have a lot of potential problems that need to be solved.

Major issues should probably be escalated to top brass, and bugs should probably be shared with the development team. It may be that you’re the only point of contact, representing anyone who can get a bug fixed. And a bug may look like a design or usability issue to your support staff.

You should be working with any issues that revolve around setting customer expectations (especially around shipping and delivery), crafting a resonant pitch, and fixing usability issues in browsing, filtering, sorting, customizing, adding to cart, and checking out.

You should then prioritize their necessity (along with the rest of your testable ideas!), and try to synthesize them into concrete, testable solutions.

Support isn’t scary

Why do people avoid doing this? Is it fear? Perhaps people don’t like putting themselves on the front lines, having to deal with upset customers.

Yet your customers are often the most informed when it comes to identifying what’s wrong with your store. It’s tremendously beneficial to pay attention to them, because you ignore them at your peril.

← Back to the Blog Check Out Draft’s Store →