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 Customer Success Engineers 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()
  codeExamples()
  documentation()
  knowledgeBase()
  aiAgent()
}
catch() {
  support()
}

There are all these things you do inside the try block, like documentation, knowledge base, code examples, and the AI Agent. 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. More of our time goes upstream of the support queue: the system prompt the AI Agent uses, the docs it draws from, and the evals that tell us when it's wrong. A ticket that reaches a human is increasingly a signal that something in the try block needs to change.

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.

Categorize every ticket

We categorize a ticket when closing it. We use six 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.
• Deliverability: As a user, I don’t understand why my emails aren’t reaching inboxes. Deliverability is when inbox providers filter or block emails for reasons outside the Resend app experience.
• Abuse: As a user, I want to send safely without being affected by bad actors. Abuse is when Resend enforces policies to protect good senders from harmful or non-compliant activity.
• Success Outreach: As a user, I want help before I even know I need it. Success Outreach is when Resend proactively reaches out to guide, educate, or unblock customers.

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.

Ship the fix yourself

Engineering uses these insights when planning features and prioritizing bug fixes. Support uses them too. When a fix is small and scoped, we push the PR ourselves instead of handing it off. The person closest to the problem is often the fastest person to ship the change.

This is what the "Engineer" in Customer Success Engineer means in practice. Not every ticket ends in a PR, but Customer Success Engineers can write one when the fix is theirs to make.

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.

Improve the AI Agent

The AI Agent sits inside the try block alongside our documentation, knowledge base, and code examples. For many users, it's the first thing that tries to answer their question.

We own the agent's system prompt, the tools it can call, and the evals that tell us when its answers are good.

Improving it is regular work, not occasional cleanup. Every piece of negative feedback is a chance to ask the same question we ask of a support ticket: how could I prevent the next customer from asking this?

Sometimes the answer is a new doc. Sometimes it's a change to the system prompt, a tool the agent should have had, or a fix in the product underneath.

Evals are how we know the change worked. Before we update the prompt, we add a test case for the situation we're fixing. If that case passes without breaking the others, the change ships.

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.

Frequency also tells us where the docs and the AI Agent need work. When the same question keeps reaching a human, something upstream of the queue needs an update.