Our #bug-reports channel was a Wild West, so I tamed it by banning humans

When I joined my current company as an engineering manager, there was one particular Slack channel that appeared in desperate need of TLC: our #bug-reports channel.

It was a channel with lots of activity that was critical to our business — but it had no structure.

Bugs, outages, and other production issues were reported by stakeholders across all departments, often with a dreaded @channel or @here, but with no consistency as to how these reports were constructed or managed.

This was, as far as I could tell, an attempt at ChatOps that was missing the "Ops" part.

Reining it in

I was able to bring more structure to the channel by creating a Slack workflow that collects bug-report information via a simple form, with the following fields:

• Describe the bug. What is broken or inaccessible?

• Scope: How many users are affected?

• Impact: How urgent is the issue?

• Which teams should be notified?

• If you have screenshots or other files that illustrate the problem, please upload them.

When a user submits this form, the information is posted in the channel, and we also notify the specified teams.

The workflow also displays a "Claim for review" button, which the relevant engineering team can click to indicate that the report is being triaged or investigated.

Much of the conversation around the issue then takes place in a dedicated thread, and when the issue is resolved, an engineer will click another button, "Resolve the issue," at which point all data related to the workflow gets populated in a spreadsheet, which we can use to track incident response metrics, such as Time to Acknowledgement and Time to Resolution.

Locking it down

The introduction of the Slack workflow achieved some immediate benefits. It brought structure to the bug reports, it helped us quickly route the reports to the relevant teams, and it gave us valuable data that we could use to assess and improve our response times.

However, getting members of the channel to use the workflow consistently was more difficult than I anticipated. Many users of the channel only visited it occasionally (when they had a problem to report) and were missing the regular reminders about the "right" way to post in the channel.

After multiple months of having to gently remind users to follow the prescribed process, I decided to take a different approach and not give them the option to do otherwise.

I persuaded our Slack admins to adjust the posting permissions so that no humans could post in the channel.

Instead, posting permissions were granted only to two Slack workflows: the "Report a Bug" form, which is the primary way users can interact with the channel, and a general "Announcements" form, which can be used to post any other information relevant to the channel that's not a bug report.

Human users can still reply in threads, but the ability to post a free-form, top-level post was removed.

Fully tamed

The end result was a Slack channel with structure and organization. The orderly flow of information, starting from a well defined form, continuing into the channel itself, and eventually into a format where we could track and analyze the data, was a drastic improvement over where we began.

And, as expected, it has led to faster incident response and higher satisfaction among our stakeholders.

Indeed, this effort has been so successful that we're looking to transform other support channels to use similar restrictions and workflows.

Will this ChatOps approach to incident management scale indefinitely? Maybe not. But for now, we've put in place a solution that's a good fit for our current company size and processes, with plenty of room to scale upward before we need to explore other options.