Customer-Driven Product Development: How Signals Handles Customer Support

As the Signals team works toward an increasingly tighter product-market fit, we've taken a somewhat different approach when it comes to support. Operating at a low .01 tickets per user, we’ve used customer-driven product development in the early stages of Signals. While the fundamentals of this approach aren't radically new, it does speak to how you can create a beautiful product experience, faster, by keeping your entire team plugged in with your customers.

On the Signals team, Uservoice is our current support platform of choice. It serves the purpose of three key features of customer-driven product development.

Uservoice allows us to:

  • Triage tickets easily tickets through custom rules and assignment properties
  • Host all of our help documents in an accessible format
  • Host a feedback forum to allow for more direct and freeform user feedback

Screen_Shot_2014-03-31_at_5.43.04_PM-1

How Signals Handles Support

  1. Everyone answers tickets - Every single engineer on the team is set up with a Uservoice account. Depending on which part of the product each engineer owns, they have specific categories of tickets that are automatically assigned to them. This keeps every engineer deeply connected to the customers that are the heaviest users of their piece of the product.
  2. Screensharing is caring - If a ticket is filled where we can’t quickly figure out what the issue is, we ask the customer for 10-15 minutes of their time in order to look at their screen to either: A) Collect all of the technical information necessary to debug or B) Solve what’s wrong with the customer’s computer.
  3. Write a help document for anything we hear more than a few times - Large-scale support teams with help lines are a thing of the past for touchless-sale tech products. In order to scale our support processes, we need to provide our users with the tools they need to solve their own problems.
  4. Diligently maintain the knowledge base / help article database - While we’re constantly shipping code, we still need to make sure that we're shipping just as much content on the support side. This means keeping on top of images, videos, and the language we use in our help articles. The clearer our help articles are, the fewer support tickets we’ll receive.
  5. File Github tickets immediately - While we don't necessarily need to address them right away in the roadmap, we still need to keep track of all of the bugs in our backlog and link them to the direct ticket that the user submitted. We use a Github label “Product Quality - High Priority” for any bug or issue that is affecting more than a few percentage points of our userbase.

Incentives Make It Easy

Engineers tend to enjoy shipping code more than they do answering support tickets, so adding in a layer of incentives is vital to this process.

And here's where another great feature of Uservoice comes in: The leaderboard, where team members are awarded points for answering tickets in a timely manner and with thoughtful responses. This has created a bit of an internal competition within the engineering team, as team members are constantly dropping the leaderboard in our shared HipChat room to show off their position on the leaderboard.

This leaderboard has even motivated some team members to drop what they’re doing, go into Uservoice, and get back to a user as quickly as they can. Hey, whatever works. If you’re not on Uservoice, you might want to find a way to generate this competitive spirit by pulling stats on who is answering the most tickets and at what speed and share it with the team.

Screen_Shot_2014-03-31_at_5.25.24_PM-1

How to Get Started

Choose a team member who will "own" the higher-level processes around customer support. Ideally this would be somebody in a Product Management role, or even a C-level or founder if your team is still small. Have them spin up a Uservoice account and get a few team members signed up. The idea here is to begin funneling all user feedback and support into one repository and get your engineers at least one step closer to the user.

Matt Bilotti

Written by Matt Bilotti

Subscribe for updates

New Call-to-action