A couple of years ago, I met up with Stephen O'Brien at a coffee shop in Boston's Back Bay. He had recently left Intercom, a real-time messaging platform for businesses, and was looking for engineers to help him build an app to "fix email". I chose to pass on the opportunity to join. A few months down the road, the website for Consider went live.
Consider adds collaborative features on top of basic email. It's meant to be used by teams working on business problems. A few standout features are:
- Send emails into "groups" which let everyone in that group access the threads without CC-ing fifteen people;
- Persistent history so you can see the entire thread of public conversations even if you joined the company yesterday;
- Emoji reactions to let your let teammates know how you feel about parts of a message even when you don't have time to type it out;
- Message notifications, digests, suppression features, and;
- Online statuses and presence markers to let you see when team members are looking at the same message that you are.
Wait a second... I have definitely read this feature list somewhere else.
Email and instant messaging... what's the difference anymore?
If you read that list of features above and were thinking "I think Slack does that too", then you and I are on the same page. Text-based communication is evolving fast.
In fact, team messaging tools for business have already solved many of the organizational problems that email can't shake. It's been said that email is "broken", but email was invented decades ago with certain assumptions in mind. One clue is that email has the word "mail" in the name; electronic mail made written communication so easy that it reduced postal services to being the method for sending hard copies and physical goods. The path that email followed to become the backbone of intra-office communication had more to do with the history of how related technologies evolved rather than the suggestion that email was a perfect fit.
The 1990's and 2000's were messy. We were using email to talk with coworkers; we were using email to talk with customers and prospects; we were using email to prioritize work; we were using email to conduct support chat; we were sifting through mountains of spam. Email was ubiquitous because there wasn't anything, besides a phone number, that everyone was guaranteed to have.
Private instant messaging tools for business helped us admit that email was trying to do too much. Conducting conversation in a platform which has more in common with texting than stationery did away with nightmares like inbox filters, junk messages, accidental sends, typos, and awful formatting. Tools like HipChat and Slack could fearlessly add features like emoji reactions, media support, automation, groups, and platform-specific formatting options since Slack users can only talk to other Slack users.
Email, now not as necessary for chatting with your team, became a portal to the outside world. Since a sales rep won't find their prospect in the team Slack user registry, they have to grab an email address from Salesforce instead.
The major difference between email and messaging tools is that messaging is a closed system and email is an open one. Just like how I can call my dad using my AT&T-powered iPhone while he receives the call on a Verizon-powered Samsung Galaxy, a small business owner using Microsoft Outlook 365 can conduct a conversation over email to their design consultant who uses G Suite without any compatibility issues or needing to request access. The protocols for email are a time-tested and well-understood way to transfer information between people with nothing except business interests in common.
But as can be seen with Consider, once the conversation starts, the lines between email and instant messaging blur. One-on-one conversations become group conversations. Participants share media and documents. Conversations start to float off-topic or get split into multiple threads. These features and others exist in instant messaging tools for business but haven't yet found their way into business email.
If email clients and instant messaging clients are becoming so similar, perhaps it's time for someone to merge them together.
"Send it to my Slack address"
What if a closed-system chat tool like Slack decided to open up? I don't mean in the way that you can create shared channels with Slack users outside of your team, I mean in a way that lets non-Slack users send you messages that appear in as a thread in your Slack client. Let's explore what might happen if Slack takes the shot.
Today's email clients support HTML rendering for highly-visual landing page-style-experiences. This is especially important for marketing. Slack will have to decide if it will fully support rich text, if it will continue to strip down messages into basic components, or if it will outright reject poorly-formatted incoming messages and issue a warning to the sender.
Simultaneous conversations, same participants
Since email threads are grouped by subject line and not by sender, two people can carry on multiple conversations at the same time about different topics by switching between email threads. "Topics" in Slack are either loosely-defined by the channel name or just implied by being a participant in a conversation. Slack will need to decide if compatibility with subject lines is important to them, or even a requirement.
When you write an email, you can add paragraphs of text, images, attachments, and links all together in one message. Everything is neatly "packaged" together with one subject line and one timestamp upon pressing Send. You can do this with chat tools as well, but the emphasis on short, separate messages makes the process cumbersome (and some platforms have limited support). When you're having a conversation in Slack to someone who is not using Slack, how will those messages look in the non-Slack client? This is a challenge.
The moment that addresses are visible to the outside world, it's guaranteed that someone will try to exploit the channel. In the same way that robo-callers rip through phone numbers and infected servers crawl domain names, users will be regularly sorting incoming messages from unknown senders into the appropriate bins. In the worst case scenario, Slack would become a storage unit for unread messages, just like your Gmail inbox. Slack would have to decide where it wants to make the tradeoff; more compatibility and accessibility means more spam while more verification and conformity means less people carrying on conversation.
Slack supports emoji reactions, link previews, status indicators, and threads. While some other clients might have full support for the same features (e.g. Consider), many clients will not. Slack would need to create standards for progressive enhancement of messages which maintain compatibility with older clients in a way that doesn't strip messages of important information. For example, if a client doesn't support emoji reactions, the reaction should be represented in a fallback format instead of being removed from the message.
BCC-ing your team is an easy (read: sneaky) way to keep people informed of conversation without broadcasting that the conversation now has 5x as many viewers. Replying to or forwarding a message to only your teammates without the sender included is a quick way to have a private side discussion about the email content before replying. It's natural to create closed circles of conversation, and Slack would need to find a way to respect that behavior when internal and external conversations merge (see Intercom's Notes feature for an interesting solution).
Lots of shallow connections
Tools like Superhuman are helping people deal with the realities of connecting with hundreds of strangers every week. The nature of outwardly-facing communication jobs like sales is that there is too much volume to be on top of everything. Slack would need to implement most of these features, but also consider where they fit in an internal context (because we've all forgotten to follow up with our teammates once in a while).
Modifying a message after send
Slack lets you edit or delete a message after it's sent. This is possible because every message sent in Slack lives in the same Slack-owned database. Email is more immutable because once the data leaves your server it's received by a different server which has full control over the message content. Slack would have to figure out if the edit/delete feature is worth enforcing and, if so, would have to develop a way to "request" that a sent message be updated.
The case for a new standard
Email protocols like SMTP and IMAP have roots in 70's and 80's computer science. It was exciting just to see computers communicating with one another. Open standards made it possible for businesses to build their own email clients without forcing two people to download the same software in order to connect.
Instant messaging, on the other hand, was never meant for the greater good. History's major chat clients like AIM, MSN, GChat, iMessage, Skype, and Slack have been unapologetically isolationist. Despite the enormous reach (and enormous effort) of platforms like Facebook and WeChat, communication tools for business have mostly lived in a separate environment from their social counterparts. That's not to say Facebook hasn't helped set the bar for building excellent instant messaging experiences; they just require that you have those experiences only between Facebook users.
New email protocols are being built all the time (e.g, JMAP), but the network effects created by widespread use of older protocols like SMTP has made change incredibly difficult. Measurable upside, reduced risk, and compatibility with older email protocols may be enough to move the needle. Perhaps the same strategy will be enough for instant messaging to open their doors.
It's worth mentioning that instant messaging "protocols" are more-or-less just API calls. For example, since every Slack message is sent directly to a Slack server, there's no reason to add extra layers like DKIM. Modern messaging platforms are already using modern messaging technologies in order to remain secure and reliable. The hardest part, it seems, would be getting competitive business leaders to join forces for the sake of mutual profit.
I think it's time that industry leaders put their heads together to solve the logistical problems which keep business email and instant messaging apart. Business systems everywhere are showing the symptoms of attaching related but incompatible technologies together with duct-tape. End users feel the pain every time messages are ignored, context is lost, or when different employees reply to a customer's inquiry at the same time.
Imagine a world where support chat, signed contracts, newsletters, and a question from your boss are standardized, organized, and accessible in Slack the moment that they come in. Notifications would be toggle-able by source. Integrations with CRMs and kanban boards would be super powerful. Everyone would be able to get or stay up-to-date. Analytics about conversation volume and conversion would be a piece of cake. Conversations will be able to fluidly evolve from brief inquiries to multi-person, multi-department discussions.
I hope that some neutral group, like the IETF, takes the plunge into this challenge with the support of productivity tools giants like Microsoft, Google, and Apple.
While we're patiently waiting for email and chat experiences to merge, perhaps someone can figure out where video fits into all of this.