Finding workflows
Discovering the processes that make sense to turn into Slack workflows
Slack is where you communicate with your team, make decisions, get updates, and build company culture. Increasingly, this is happening not just with your colleagues but with the other apps and services you use every day to get your work done. From to-do lists to spreadsheets to service monitoring, the tools you use are communicating with one another and Slack is at the center of a great deal of that communication.
An important first step is figuring out which workflows are right for bringing into Slack with a custom app. Based on our experience with teams using Slack at organizations of all size, we have some recommendations.
Assembling your team
Now that you’re ready to build an app, the first thing to do is assemble the team that will determine what the app does and how it will be built. Some of these people will be obvious — — the engineers who will write the code and the PM who will oversee the project, for instance. If you already have a workflow in mind — for example letting your team members file a helpdesk ticket from within Slack — be sure to include someone from both the IT team who will receive the tickets as well as a colleague who would be filing tickets.
If you don’t yet have a workflow in mind, just more of a mandate to integrate Slack into more processes, that’s great! You have a unique opportunity to help make your teammates working lives simpler and more productive. This just means you might need to cast a wider net when recruiting team members for this project. Maybe someone from a team that’s heavily invested in Slack already and someone whose team is using Slack just for chat, or colleagues from disparate teams, such as operations and marketing.
Ideally, this team should be big enough to gather a diverse set of opinions but small enough to keep things manageable. Six to ten is probably the ideal size for most projects — any smaller and the project is probably too specific to a department, and much larger makes it challenging to find consensus on what to work on and how to build it.
With the team set up, it can be helpful to establish a few roles. The first is the facilitator, the person who will be guiding the process (maybe this person is you!). The facilitator gathers the team, schedules time to meet, assigns pre-work and roles, takes notes, and generally keeps things moving on track. This is more like a PM-type role, and it’s important for this person to be organized and have goals in mind, but not have a pre-set destination.
Another helpful role is the decision maker, someone who can definitively say “yes” or “no” when the team is locked at an impasse. It’s important for the decider to be open minded about what the team is hoping to accomplish, but also have the authority to be able to have their decisions stick when it comes time to launch the app and bring everyone on board.
With the facilitator and decider picked out, the rest of the team is empowered to bring their expertise and experience to the task of building your app. Some of these folks will be technical and will view the project through this lens what is (and often isn’t!) feasible. Some will be more process oriented and will see things via the people and tasks to be done. That’s okay — this diverse perspective will help you decide what the right thing to build is and how to build it.
Finding your flow
Picking the project to work on can be the trickiest part of building an app. You might have an engineering team that’s already integrated Slack with other services as part of a fuller DevOps pipeline, but that’s inscrutable process to the rest of your organization. There may be other teams that use Slack primarily as a chat application and want to know more about these apps that they’ve heard about, but don’t know where to start or find the process of building an app intimidating.
In general, we try not to be too prescriptive about how to build an app — every organization is different, after all. There is, however, one activity that we have found helpful when working with customers who have expressed an interest in building a great Slack app that helps to identify those critical workflows for your team.
Next, book a room for a sixty to ninety minute meeting, preferably in a room with a white board. Ideally, everyone will be onsite and will be able to assemble in a single room, but videoconferencing can work if necessary, just make sure the A/V setup is in working order.
Invite your attendees at least one week ahead of time so they’ve got plenty of notice. You’ll also be giving them a bit of pre-work and an assignment they’ll need to bring along with them. There’s a template for the invitation below.
About the pre-work assignment: it’s pretty quick, doesn’t require any technical knowledge of the Slack platform or even ever having used Slack before. Everyone on the team should spend a few minutes in their email archive and find one or two automated messages that they’ve received in the past week or so that is critical to their job. It might be a simple notification, an analytics report, a response to an action they’ve taken, or a timed request to complete a task.
Everyone should print out this email (it really will help to actually print it out!) and highlight the bits that are most relevant to their work. It could be a terse bit of text, a call to action link, or a chart or graph. With those highlighted bits in mind, flip the sheet of paper over and diagram an ideal path for this message. It doesn’t need to be beautiful, just boxes and arrows and a few labels are great. Feel free to include information or notifications or data from other systems — for example, maybe receiving this message means you need to log into a separate, unrelated app. The idea is to understand where this message comes from and what steps you need to take to get your work done.
Here’s an example invitation you can use to get the team ready.
To get ready for our meeting, we have one request. This should be pretty simple, please don’t spend more than half an hour on it (though in reality it’ll probably only take 5–10 minutes).
Open your email and find an automated message you’ve received in the past week or so. For this exercise, try to pick something that comes from one of the tools you use in your day-to-day work (so, not marketing emails). It could be a regular update from a sales system, a request to take action on something from HR, or a notification from one of your ops systems. Next, and this might be the hardest part, go ahead and print out that message then highlight the parts of the email that are most relevant to your job. Finally, flip the page over and quickly diagram how this automated message should work best for you — it doesn’t need to be beautiful, boxes and arrows are great. Just outline where the message comes from, other additional data or actions you might want and what the ideal end result would be.
Meeting your needs
When it’s time for the team to get together, everyone should have a process in mind they’d like to discuss based on the pre-work exercise with their email. After everyone gets assembled, the facilitator can give people time to introduce themselves, especially if this is the first time the group has all met.
Next, everyone should introduce the process they chose and be given an opportunity to really explain how it impacts their day and their work. There’s plenty of time at this stage and everyone should feel free to really dig in with some specifics. Why does this email matter? How often does it show up? What’s the next step? When do you consider the task complete? This part will likely take up about a third of the meeting time, so 20–30 minutes depending on the size of the group.
The facilitator should take some brief notes on the whiteboard, just enough so everyone will remember what each process is about.
After everyone has presented their workflow and ideas, it’s time to discuss. The goal here is for everyone in the room to have a highly level understanding of the needs of the people in the room. This is a great opportunity to understand different functions of your team or company! It will also help everyone start to get an idea of which workflows are most useful across their organization, not just a particular pet project.
With a bit of shared understanding in place, it’s now time to decide what to build. This could be as simple as the decider saying “we’re going with this one” or more discussion amongst the group about where to put their resources.
Finish up the meeting with a one-line statement that will define what the team will actually build. It should be specific and with little-to-no jargon. Some examples you might consider are:
“Anyone in the company file a helpdesk ticket right from Slack that the IT team can respond to from a shared triage channel”
“A daily roundup of ongoing sales figures, posted in each region’s sales channel by 10am local time.”
Mission Accomplished
With a little bit of prep work and a single meeting, you’ll have a clear idea of how your custom Slack app will improve on existing processes and reduce context switching between tools. The next step is to start building — check out this guide to help you choose which Slack API is right for your app.
Ready to get started? Check out our documentation — or better yet, join us at Frontiers and get the skills you need to be a Slack developer.
