Emergency Response Tips for Support Pros
Here in Australia I have a snake bite kit in my glovebox to grab when we’re heading out for a bushwalk, because first aid must be accessible and easy to use. At home, my personal emergencies are mostly at the “fish the fingernail out of the diced onion, slap on a band-aid, and sharpen the knife properly next time, you idiot” level.
Out in the wider world I’m constantly tempted by those “break glass in case of emergency” boxes. A socially acceptable opportunity to dramatically smash something and save the day? Yes please. So far, my services have not been needed, but I have prepared through extensive visualisations. I'm ready.
Support teams need multiple levels of emergency response too. From the queue band-aids all the way up to a company-wide support defibrillator. Is your team prepared for when emergencies arise? Does everybody know what to do when your app catches fire or there’s a flash flood in the queue?
In my experience you tend to create those plans after the first time everything goes catastrophically wrong, but ideally we'd learn from each other and put systems into place before they are needed.
If you don’t have an emergency response plan, or if it’s been a while since you’ve dusted off the support first-aid box to check the contents, here are some useful questions to answer.
Emergency Response Planning
Is the plan up to date?
Mid-emergency is not the moment to discover your response plan relies on a fax machine and backup floppy disks.
How will you identify an emergency situation?
Give your whole team some example emergencies and share categories of issue to watch out for. What might the early signs look like in your specific context?
Where are all the important details kept?
When something is going wrong, you want the response plan to be readily available, not behind a ‘Beware of the Leopard’ sign. Pin the location in your Slack channel or on the intranet homepage. Tattoo it down your arm.
Who decides when to smash the glass?
When it’s a major issue that needs help from outside the team, who should make that call, and how? What if that person isn’t around? You don’t want hesitation for fear of disturbing another team, so decide in advance and make the authority clear.
Who can be drafted in to help?
Are there former support team members now in other internal roles who could respond to your support bat signal? If you practice whole company support you might have a large pool to call on, but even if not there will be others who can step in effectively.
Who will handle communications?
Updating customers before they need to contact support can build trust and reduce incoming volume. You can prepare templates for the most common scenarios, and create tone and style guides to make communicating under pressure less stressful.
You should also consider internal communications with the relevant product and executive teams, and your PR folk, if applicable.
Emergency drills can be annoying, but next time there’s a milder issue why not use it as an opportunity to discuss your emergency plan with your team. Perhaps let a few new people run the response when the stakes are lower.
When there’s a major issue, you’ll be in a stronger position if multiple people could step in to lead your response. This is something I have learned through painful experience. Sharpen your knives before you need to use them.
This Could Have Been an Email
This article first appeared in The Supportive Weekly, Mat's email newsletter for anyone who wants to create better customer experiences. Subscribe now...it's not boring!
Mathew Patterson
After running a support team for years, Mat joined Help Scout, where he helps people deliver better online customer support. Subscribe to The Supportive Newsletter or find him on LinkedIn.
