Slack is the tool our team uses for asynchronous communication as well as real-time collaboration. This article walks you through how to maximize the effectiveness of Slack within our context.
Any time we transition from one type of activity to another, we mention it on Slack. For certain activity switches (such as to or from unassigned tickets), we ping @supportteam to make sure everyone is aware.
The purpose of communicating whether you are on tickets or not is to have other support technicians be aware of whose job it is to keep an eye on unassigned tickets during business hours.
When we get bogged down on a ticket, or need quick help that doesn't yet require escalation, we ping a Senior Support Technician or the Head of Support to do a quick call. We use Slack calls within the main #support channel for this, so that everyone is aware of the time taken, and on the same page.
The goal of these calls is to provide quick help, and to that end, the tech initiating the call needs to have done everything possible to resolve the issue themselves before looping in a Senior Support Technician or the Head of Support.
The other goal of these calls is brief touch points so that the Senior Support Tech or Head of Support can "look over the shoulder" of the support tech to provide feedback and tips.
A good distinction between what constitutes a reason to escalate using a Help Scout note and a reason to escalate with a Slack call is that calls should be reserved for "I don't know how to __" where notes should be for "I don't what (else) to do."
After a call, we write a call summary and post in the #support slack channel. This is to help others understand what happened on the call.
For more on Escalation, see the section on Frictionless Support.
Since slack by its nature is asynchronous, it is easy for important or urgent items to get buried. To help with this, there are a number of things to keep in mind before using Slack at all. First, if this is an item that you want the development team to take action on, the best place to start the conversation is via product feedback. Since GitHub issues are ported to the #development Slack channel, any internal discussion of the issue can take place there, as a thread on the issue.
Similarly, if the issue is related to documentation or this support manual, the best place to ensure that the issue is not overlooked is to create feedback on the GiveWP Feedback Site
For other issues surrounding tasks for support technicians to complete, which would tend to get lost in the pile on Slack, we use the /remind integration in Slack. Good examples of this are escalated tickets to a specific person, or a ticket that requires the attention of a specific person. Type /remind {person} to {do something} {at this specific time} A fully functional /remind note would be /remind @Ben Meredith to handle this escalated ticket (link) tomorrow at 9AM
Similarly to the TODO app, the must read app is for making sure than things don't get lost in the asynchronous nature of Slack. The must-read app is best used for something discovered that everyone needs to be aware of. A good example would be
I figured out the fix for the user access error we've been seeing @supportteam. The fix is __ @must-read
Using the Must-Read app in the side bar, you can quickly get up to speed on all issues that are marked that way.