Writing a great support email: style
Stilus virum arguit
This is the fourth 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, and this week we’re talking about style.
Though content, structure, and tone are the essential elements of written communication, they are not the only ones. In this post I originally intended to do a grab bag of smaller related items before closing the topic of support emails, but it turns out I had a lot to say about writing style.
Style: neither tone, structure, nor content but something else
If I write a support email it’s not going to be quite the same as one you write, even if we’re starting from exactly the same facts and using the same support persona. My own personal style is just that—personal—and is neither natural nor easy for someone else to ape. This was a hard lesson I learned early on in my own support leadership experience.
My first hire in my current role was technically excellent and very quickly picked up our preferred support email process and tone. But no matter how much we worked together, his style was different from mine. He was less interested in the subtleties of word choice, instead spending the bulk of his time focusing on technical correctness. On a superficial level that sometimes manifested in typos or grammatical issues, which we dealt with together. Over time those issues resolved themselves, but something still felt wrong to me when reading his messages. I couldn’t put my finger on it, and the two of us spent fruitless hours working together, writing and rewriting customer emails to my satisfaction.
In retrospect this was foolish. He was very successfully communicating with customers, resolving technical issues quickly, and generally leaving a great impression on folks who wrote in with issues. I was focusing on the wrong thing—instead of ensuring that every support email coming out of our ticketing system read exactly as though it were written by me, I should have been spending my time making sure the content, structure, and tone were great. His personal style was different from mine, and that was totally okay.
I didn’t realize this, though, until onboarding our second support hire. I was about to go down the same road when I got a reality check. This new hire had been doing support a lot longer than I had, and wrote excellent customer communications. But they weren’t like mine! In retrospect it seems silly, but it took that mild shock to my preconceptions to make me realize that I was spending too much time on style and would be a lot better off redirecting my energy to ensuring content choice, tone, and structure were consistent across the team.
After that, I refocused email training on ensuring new hires understood our support persona, were clear on the level of detail we preferred to use in emails, and had the basics of structure down pat to ensure readability. I ended up with a dozen different engineers using a dozen different styles, so it was instantly obvious to me who had written each email, even without looking at the signature. But they were all clear, they were all readable, and they were all successful.
Next time: wrapping up support email month
Thanks for reading Andy's Support Notes 💻💥📝!