How we scale support

When support demand increases, the goal shouldn't be to immediately hire more people. This can become a temporary fix, leading to an ever-growing need for more hires as support volume rises.

The focus should be on making each hire as efficient as possible. This means listening to customers and building a product that meets their needs, reducing the necessity for them to reach out in the first place.

We think about support as a try/catch block.

try {
  product()
  documentation()
  knowledgeBase()
  codeExamples()
}
catch() {
  support()
}

There are all these things you do inside the try block, like documentation, knowledge base, and code examples. However, if the user still can't help themselves, it moves to the catch block.

Great support is thinking about how to improve the try block so it doesn't go to the catch block as often.

Making the product better

In a perfect world, the product should answer any customer question.

• How do I change my billing email? It should be easy to do this in the product.
• How can I remove a team member? It should be easy to do this in the product.
• How can I delete my account permanently? It should be easy to do this in the product.

But we don't live in a perfect world. Sometimes, the product only fulfills some of a user's needs or leaves them with more questions. We categorize support tickets to improve Resend and meet those needs in the future. By giving insights from support back to engineering and product, we reduce future support and enhance the customer experience.

To do this, we categorize a ticket when closing it. We use three main categories to surface support trends to the team:

• Reliability: As a user, I can’t trust Resend to solve my problem. Reliability is when Resend generates an error or a feature doesn't work as expected.
• Usability: As a user, I don’t understand how to use Resend. Usability is when Resend behaves as designed, but a user doesn't understand how a feature works.
• Functional: As a user, I can’t solve my problem with Resend. Functional is when Resend doesn’t have the functionality a user needs.

Along with the categorization, we label the product area from which a support ticket comes. Classifying tickets helps us surface ticket causes that might not appear in error logging, rise to incident-level issues, or occur during feature betas.

To improve the product, we can report on these data points to the team, including how many tickets are in each category. For instance, we may discover that 80% of usability tickets come from a specific product area.

Engineering can use the insight during feature planning to guide the creation of new features. When a developer implements bug fixes in a part of the product, it can help them decide what to prioritize.

Create documentation dynamically

One of our favorite ways to resolve each ticket is by asking ourselves, “How could I prevent the next customer from asking this same question?”

Each support ticket should be actionable, whether that means creating a feature request, writing/updating a handbook article, or updating the product.

A tip that helped us achieve this is to block ourselves from moving on to the next ticket, until we write a knowledge base article and put it live.

This way, we now have a link to share not only with the customer who asked the question but also with future customers who might have the same question.

Support our support team

Customer Support is the face of your organization. Whenever someone has a question, complaint, or frustration, they're the first line of contact they have with your brand.

When customer support flags a concern, we take it with high priority.

This could mean adding tooling to make processes more efficient, or escalating a feature request because 3 people have been asking for it in the past week.

Remember, customer support pain = customer pain.

Track and log ticket frequency

This one is as simple as it reads.

The more often a feature request or bug comes up, the higher it should be prioritized. Logging frequency helps identify which features are the most asked and requested, which makes it easier to bring into current sprints.

We really like the way that Plain and Linear integrate with each other. It's extremely easy to link a support ticket with a Linear bug ticket or feature request.