Macros: yes or no? [PLEASE CHOOSE ONE]
AGENT: DELETE THIS PART BEFORE SENDING
A constant topic of conversation in every support team I’ve encountered is what level of macros to use in email support. (Maybe you call them templates, or canned messages, but what I mean here is prewritten responses to common questions.) One one side are the automators: we field so many of the same questions, they reason, that we should just write up one good response and use it every time the question comes up. This makes sense, as far as it goes. The more issues you can respond to without having to craft a custom response for each, the more time is left over for actually novel and time-consuming troubleshooting. Not so fast, responds their opponent. Just because we get lots of similar questions doesn’t mean they should all just be dismissed with the same pre-canned response. There’s nuance here. And they’re right too! So the argument continues, never to be entirely settled.
But even if there’s no clear winner to the argument, you still need to make a determination for your own support team: should you be using macros or templates to respond to customers? If so, how much effort do you put into assembling these macros in the name of saving time down the road? This is something that every leader needs to decide for her team, and like so many other team decisions and procedures, it’s a choice that needs to be revisited regularly. Here are some things to keep in mind when deciding how to employ macros in your own team’s processes.
Macros are inevitable
Here’s the thing—even if you ban macros across your team, people are still going to be using them in spirit. Maybe they’ll have their own library of messages that they’ll copy and paste from, or maybe they’ll see a great response from a colleague and save it for their own use later. If you don’t have a standardized set of messages for common questions and problems, you’ll just end up with a bunch of unofficial ones that your team is using behind your back. It’s human nature to want to avoid duplicating effort, and writing the same message from scratch ten times a week is going to push even the most diligent support engineer into copy/pasting their own work after a few days. It’s better to get out ahead of this impulse, and work with your team to craft good macros for a response library that everyone can employ.
Make it a team effort
On that note: don’t try to write up everything on your own. The engineers on your team, as we just mentioned, probably have their own macro libraries already. Sit down with the whole team, discuss which kinds of messages they’re sending constantly, and come to agreement on which ones should have official macros. Then open the floor: who’s already got a good response for this? Take a look at what your team is already using, choose one, and revise and improve it together with the team. Getting everyone’s input will help ensure that the resulting macros are ones that folks will actually use, rather than beautifully written messages that are never once sent to a real customer.
Leave room for customization
Most ticketing systems have a concept of placeholders or variables to be used in macros: take advantage of that to automatically fill in the customer’s name, and the engineer’s name. Lots of macros will also benefit from having a section to be filled in at sending time, to add at least some customization to an otherwise prewritten message. For example, a macro for closing out a solved issue might look something like:
Hi <customer>,
I’m glad to hear this is resolved! I’m going to close out this issue now, but please don’t hesitate to reach out again if <SYMPTOMS OF THIS SUPPORT ISSUE> recur, or if you have any other questions.
Thanks,
<engineer>
A word of warning: make sure that the section to be filled in is distinctive enough that it’s hard to miss, if you write this kind of customizable macro. There’s nothing more embarrassing than sending out a message to a customer and belatedly realizing that you left placeholders in the final message. One technique I’ve used successfully is to add another placeholder up at the top of messages like this, saying something like DELETE THIS AFTER YOU FILL IN THE BLANKS BELOW or something similar. This makes it a lot harder for an inattentive or stressed-out engineer to miss!
Remain flexible
Once you’ve got an established shared set of macros for the team, the temptation may be there to enforce their use, for the sake of completeness or maybe just conformity. Resist that impulse—macros can be great timesavers, but they’re not always the right choice. Some folks may prefer their own wording, and as long as it conveys the right information, you should let them write their own messages if they want to.
On a related note, don’t fall into the trap of trying to write a macro for every possible situation. While there are going to be some things your engineers deal with over and over again, most support teams tend to have a very long tail of topics they end up covering with customers, one-off bugs that nobody has seen before, and feature requests that have never been seen before or since. Trying to write macros to cover all of these categories is patently impossible, so don’t even try. If you can cover 10% of your team’s daily written output with a few well-written macros, that’s probably enough work on the macro front.
Know their place
Macros are great for some support interactions: responding to frequently asked questions or regularly encountered problems, quick ‘looking at this’ messages, and the like. What they’re not great for is sensitive interactions, novel issues, or anything else outside the routine. Don’t kid yourself that you can avoid hard conversations with a sufficiently large library of macros! Having those conversations, and conveying unwelcome interaction, are part of the job and deserve a support engineer’s dedicated time. If a customer is upset, ditch the macros for the remainder of your time with that issue. An already-upset customer is only going to get more annoyed if they realize you’re sending them templated messages and not even giving them the courtesy of your full attention.
Review your macros regularly
Since you’re already regularly reviewing your top ticket categories and meeting with your team to discuss the issues they’re seeing, those are both great times to look over the macros you’ve already got and think about which ones need to be updated or removed, and if any new macros should be put together. If a particular frequently asked question isn’t all that frequent any more, it may be time to retire its associated macro. If a product update has led to dozens of questions over the last few weeks about how a new feature works, take some time with your team to discuss a standard response to that question. Like all the other policies and procedures your team relies on, macros shouldn’t be set in stone. They’re a tool, and should be regularly reviewed so they continue to be useful.
Like any other support tool, macros have their place in a well-functioning support team but aren’t a cure-all. Figure out what macros your team can produce to cover some of your most common communications needs, and then use the time and energy saved on more complicated support issues, bug reproductions, and other team projects.
Thanks for reading Andy's Support Notes 💻💥📝!