Assign and complete: How to run a triage channel

Solving problems quickly and efficiently is a laudable goal for any company. And triage—a systems-based approach for handling incoming requests—can serve as a model to manage everyone’s time against internal resources.

Put simply, triage is when you assess a situation, figure out the urgency required to act, and then move the task to the right person. Though it is often associated with the medical field, many software engineering teams have adopted it to both help squash their nastiest bugs and solve the thorniest problems bubbling up from the customer service team. As companies increasingly rely on technology, this approach can also fit for almost any situation where managers of resource-constrained departments have to decide the order in which to tackle issues.

At Slack, we have more than three dozen channels devoted to triage. Most deal with software problems, but they also include reports to our internal helpdesk and issues aimed at our internal workplace team. We use a naming convention to make them easy to find, using the #triage- prefix in the title for every one of them.

Every triage channel needs a system

Once you have at least one triage channel in place, create procedures and workflows that can be communicated to your staff, so they know where to post issues and how to go about reporting problems. If you end up with many of them, use a logical naming system that is differentiated enough so it’s obvious which issues go to which channel, e.g. #triage-salesforce, #triage-it, or #triage-platform.

Don’t forget to pin important guidelines to every triage channel, so newcomers can get up to speed quickly on how you do things.

When and how to redirect incoming requests

The diagram above illustrates our general approach to watching over a triage channel and handling the requests made there. We define the problem, figure out how bad it is, and then attempt to fix it quickly if possible. If it’s a thorny issue, it gets escalated to a team reviewing software bugs. In general, most of the incoming requests are answered and solved within a few hours, with the remainder ending up in a bug tracking system.

Semantic emoji make triage channels easy to scan

Inside Slack, we use a system of three emoji to rate the severity of a request and a couple of additional emoji to convey request status. We pin a document explaining them or wedge them into the channel purpose, like the one below.

The urgency emoji are straightforward.

• 🔴 Most urgent: This request needs an immediate response; used most often for “showstopper” bugs or problems.
• 🔵 Not as urgent: This needs a response within a day or further clarification or direction from reviewers.
• ⚪ Question or clarification: Guidance is needed to take the next steps.

The status emoji are easy to scan as well.

• 👀 Eyes emoji: Someone has claimed the request (you can mouse over the reaction emoji to see the person’s name) and is working on it.
• ✅ The check mark emoji: Someone has completed the work and the issue is solved.

You can see this in action in our workspace channel, where staff report problems in our buildings.

With a quick glance, anyone looking at the triage channel can see which requests are marked as highest priority, who is working on them (you mouse over the reactions to see who clicked them), and which issues are already resolved.

Custom app building to operationalize triage

If you’ve got a resourceful IT staff that can build custom tools for your team, there are a couple ways to improve on this system in Slack with custom code. You can streamline submissions to triage channels by creating a form using dialogs.

At Slack, we’ve also built our own internal triage-bot that watches triage channels for any message with a color dot emoji and then tracks which are missing reactions and which have eyes but lack the “done” check mark reaction. It routinely summarizes how many requests are still unsolved and gives periodic reminders to tend to the unsolved problems.

Triage is a well-worn path to determining and solving the most pressing issues, while also preventing things from falling through the cracks. With a little planning and setup, it’s easy to implement this in a team that has a lot of incoming issues and needs ways to budget their time and energy. It certainly works well for software development, but it can be expanded to almost any process of requests and approvals.