Stop Slacking:
integrating Slack into email

June 17, 2018

Slack is an endless meeting with no agenda.


To minimize my data usage and increase my productivity, my partner, Kevin, and I built a reply-via-email service for Slack (a chat app used by many businesses for internal communication).

Stop Slacking sends you an email when you are mentioned or direct messaged on Slack (the important stuff) and then posts your reply to Slack.

Try it out at

The Setting (or How to Work in a Campervan)

During April, Kevin and I lived out of a converted minivan in southern New Zealand. On a given morning I'd pat myself on the back for my life choices and then spend the next hour agonizing over connectivity.

When wi-fi wasn't working well, I moved into range of a cell tower and watched the MBs rack up at $10/GB. I quickly became aware of how much data I was using.

In short, I didn't want to be opening Slack more than I needed to. Email was faster and cost less, not to mention it helps me stay focused.

The Big Product Design Decisions

The design of Stop Slacking started with a few key decisions about medium and functionality. I've outlined these decisions in order of how much different Stop Slacking would have been if we'd made different choices.

1. Stop Slacking is not an official Slack App.

The scope needs to stay small. We just wanted to get something working. The alternative to making an official Slack App is to use their legacy API tokens. A user can access a token for their account on a given workspace and send it to Stop Slacking to create a subscription. Administrators can disallow this functionality and thus control access to their data.

This decision chooses speed over making sure the service works for every workspace.

2. The interface will be email.

Stop Slacking lives only in email. All commands and feedback are sent via email. There's no web interface; it's a text interface like a terminal program.

This satisfies our goal of minimizing data use. Email is a data-light communication channel. We don't have to worry about keeping a web interface light-weight.

Choosing to use a text interface means we need to design for discoverability. All emails from Stop Slacking include footers enumerating options for interacting with Stop Slacking.

3. Replies are posted in Slack as threaded replies.

Slack has two ways to reply to a message. The original method was a general reply, meaning that the reply appeared at the bottom of the channel. Later, Slack added threaded replies. A threaded reply defaults to being truncated beneath the parent message and the entire thread can be opened in a side panel. This is useful when discussions on multiple topics carry on simultaneously in the same channel.

When you reply to a Slack message, do you want it to be a general reply or a threaded reply?

Specifying this choice with each message requires you to type a keyword or character to indicate a general or threaded reply. The error potential goes through the roof for this functionality. Since we're using text, we'd have to correctly identify your command and separate it from your reply and the quoted email that most email clients include. Could we predict all the ways that could go wrong and prevent those errors?

A preference setting might be a solution for people who have a strong preference one way or another but not for people who use both general and threaded replies regularly.

I made the call to keep the product simple with threaded replies only. The reply will always be in-context, even if you are replying hours later.

4. @ mentions and direct messages

Which Slack messages do you want to receive notifications about?

For a busy person, these @ mentions and direct messages cover their most urgent tasks.

On company I work with has such an overflow of Slack messages that the team has learned to @ mention every time they address someone. Urgent has become the norm. (Red flag, anyone?)

Notification source preferences are on the idea list for future features.

Omitted for Brevity

In the future, I'll write more about designing the emails (when and what, variation between quoting and threading in email clients) and implementation (a Clojure app on a server, the underside of Slack APIs, and a handful of AWS consoles - S3, SES, SNS, ACM, Cloudfront).

What do you want to hear about?

What's Next?

I've enjoyed working on a text-only interface. And the landing page was fun to build - especially those high-quality "screenshots".

My task now is to test our design decisions against the real-life needs of other people. How do other people want to use Stop Slacking? What do they need to improve their workflow?

I'd love to hear your comments and questions. Feel free to email me at or join the Stop Slacking mailing list.

Update July 2, 2018: Kevin has posted a stellar article that covers another side to the product design and discusses what's under the hood – the development considerations unique to email, Slack, and low bandwidth.

My "screenshot" of an email reply.