Writing a great support email: notes and handoffs
He listens well who takes notes
This is the fifth part of a series on writing great support emails. Part 1 covered the content of the email, in Part 2 we talked about structure, Part 3 was about the overall email tone, Part 4 discussed writing style, and this week we’re wrapping up with a few smaller topics centering around collaborating with other support engineers and with the broader organization. I promise I’ll talk about something different next week!
Ticket handoffs and proper notetaking
Beyond making a more pleasant support-customer interaction, clear and complete writing has another tremendous benefit: ticket handoffs, either within your team or to others. I’ll dig into the latter further down, but let’s talk about intra-team handoffs first.
In a perfect world, a customer writes in with an issue and the engineer who initially fields the request will see it through to completion, updating the customer regularly and bringing in assistance as needed while still retaining ownership of the overall process. There’s no need for knowledge transfer, no miscommunications as the customer has to explain themselves yet again to another person, nice and easy.
Of course here in the real world things aren’t always that simple. Even for tickets where the support engineer doesn’t need outside assistance, things happen. The customer writes in with a critical update when the original engineer has dropped off for the day. The engineer has to take a sick or personal day. Maybe the engineer has even left the company. In any case, the ticket needs to be taken up again, so another engineer jumps in and tries to come up to speed.
This is where clear communications, both internal and external, are critical. If the back-and-forth with the customer is unclear, there’s going to be friction. If the original engineer hasn’t taken good internal notes on their ongoing troubleshooting process, then the replacement may have to start from scratch just to get to the same point, wasting precious time.
Moreover, what if you or someone else on your team run into a similar situation weeks or months down the road? It will save a tremendous amount of time on the new issue if the earlier ticket is interwoven with troubleshooting steps, missteps, and the final resolution.
The solution is clear, though implementation is trickier: take good notes, and put them in the ticket. Why is this so hard to do consistently? Here are a few reasons.
- It’s hard to take a step back to record notes when you’re in the thick of troubleshooting. Much easier just to keep going, then rely on your memory to do it later. (Then it doesn’t get done, or you forget some of the details.)
- Private notes can be finicky - click the wrong button and you might accidentally send internal or embarrassing information to a customer.
- Depending on what the investigation uncovers, you might be leery about writing it down at all, especially if it paints you or someone else in your org in a not-so-great light.
Encouraging notetaking
None of these are good reasons not to take good notes, but they can get in the way of it. So given all of these deterrents, how do you ensure that you and the rest of your team are regularly updating the ticket with context so it can be more effectively handed off or referred to later?
Well, I don’t know for sure. This is something my team and I always struggle with, but here are some things that may help.
- Regular ticket review (this is a post on its own!) includes assessing quality of context provided, both internally and with the customer.
- Emphasize to your team the importance of pausing periodically to digest and to write internal notes throughout onboarding.
- When assisting with customer issues or handling tickets yourself, remember that you’re setting an example for the rest of your team and be sure to provide context that is useful not only for handing off the ticket but for helping newer team members recognize how to handle types of tickets they may not yet have encountered.
- Do not complain about the content of internal notes, at least not before people are consistently creating them—it’s better to have them there and imperfect than missing entirely.
- Similarly, while it’s important to double- and triple-check that internal notes are in fact internal, and not accidentally being sent to customers, you need to accept that, despite best efforts, this is going to happen sometimes. Be ready for the occasional lapse and be ready to jump in if necessary to apologize to customers, depending on the sensitivity of what they received. Again, it’s better to risk the occasional lapse than to have your engineers too afraid to use internal notes at all!
Roping in assistance
Not everything that comes across the transom is going to be a support-only issue. You may receive billing questions, requests for security documentation, or suggestions for product improvement, among any number of other product-related issues that aren’t within the support team’s wheelhouse. As such, it’s important to have established processes around involving other teams in your support ticketing process. A full exploration of support team interactions with various other groups across the company is going to have to wait for a future series, but here are a few guidelines specifically relating to bringing in assistance on support issues.
- Work with the leaders of other teams on formal handoff procedures and ensure members of both teams are aware of and trained on the process.
- Handoff processes must be more than just ‘assign the issue in your ticketing system’—there should be a second communication modality like a Slack message or email to provide context and allow the assignee to ask additional clarifying questions.
- Set up a regular forum for troubleshooting friction between teams during these handoffs. I regularly meet with our head of Customer Success to discuss any issues that have come up in the last week, brainstorm solutions, and ensure we’re both aligned on how to address these situations in the future.
- Similarly, a regular cross-team meetup (we do ours biweekly) can provide a forum for talking through handoff issues or other topics of interest to both teams.
- Going back to the previous topic, write lots and lots of notes in the issue itself, and encourage your counterparts on other teams to do the same. The more context is provided, the easier it is to hand off issues back and forth, even if the assigner and assignee aren’t able to speak directly.
Thanks for sticking with me through Support Email Month! I think I could probably stay on this topic indefinitely, as the more I wrote the more I realized there was to talk about, but for now let’s move on to another interesting problem next month: hiring. See you next week!
Thanks for reading Andy's Support Notes 💻💥📝!