Slack needs no introduction. Chat in general has found its way into our daily professional life and its probably here to stay. From the asynchronous and conversational nature of communication, democratization of participating in group conversations to organizing conversations per channel. The advantages are numerous. As you might have guessed it does of course come with its own unique challenges.
One of those challenges might be to simply keep track of unhandled questions in a support oriented scenario.
The productivity hacks series are a series of short articles exploring helpful techniques to improve your day-to-day productivity.
A support oriented challenge
Consider following scenario:
A team of engineers owns a number of services used internally within a company. It's not unimaginable this team will end up having to give some form of support to internal users for said services. A common pattern is to create a dedicated Slack channel per service. Such a channel keeps the topic on point and facilitates asking for support to the right people such as the aforementioned engineering team.
Many services, means many channels. If there are many users with a lot of questions then things start to become an unpleasant whack-a-mole game pretty fast. The result is that colleagues reaching out for help are left behind, which isn't a great experience. This impacts your MTTR (Mean Time To Respond). The engineers accidentally overlooking a request are frowned upon.
There are many reasons which amplify this problem. On one side fatigue of having to continuously scan all the necessary channels and to some extend also the bystander effect.
This article doesn't cover preventive steps to curb the amount of user questions in the first place. Depending on the nature of the most frequent support questions, it might be that providing better documentation or offer self-service automation API's will take you a long way.
The problem breaks down into following challenges:
- How to extract user questions from all the other "noise" in the channels?
- How to list all user questions in one overview?
- How to quickly jump from this overview to the actual Slack thread?
- How to exclude the support questions which are handled?
These are 4 questions can be pretty much solved with technology without having to change much about process.
Ketchup is a CLI tool which aims to solve the aforementioned challenges.
Consider following configuration file:
- name: Demo
ketchup you will get an output similar to this:
Clicking on the message in the terminal opens Slack and brings you to that particular message.
This example configuration has the following properties:
- Multiple named searches are possible. Each result in the overview is marked
- The list of
channelsto collect user questions from.
- Exclude messages marked with the
done_markeremoji from showing up in the next ketchup executions.
fieldvalue defines the value in the JSON response coming from the Slack API to display in the overview.
ignore_usersvalue is a list of users to ignore. A use-case might be your own team members.
queryvalue basically corresponds to a term you would query for in the Slack search bar. So this value isn't restricted to
regex_substringcan optionally extract a substring from
field. Useful for non-human structured messages.
regex_filterfurther filters messages returned by the Slack API on the
fieldcontent. This example requires a
?at the end of the message or which is at least followed by a space.
This article demonstrates how to use Ketchup as a tool to improve the
experience of keeping track of pending user questions. Ketchup has a low
footprint and requires no real changes to company processes which might be
hard to implement or slow to change otherwise. Ketchup can be used within a
team behind the scenes whilst the Slack user would only notice the
done_marker being added to their questions.
This solution surely isn't entirely waterproof. The convention used in the aforementioned example on what forms a user request to follow up on, is the mere fact there's a question mark in the message. That's not a water tight approach. However, one could say that ... if you write down a question, it should end with a question mark, a convention which is part of (most of) our languages.
Hopefully you can now catch up with all those user questions. Enjoy!
For comments and feedback feel free to reach out on twitter.