What differentiates a business messaging app?

Messaging has become a hot area of late (for a look at the history of messaging over the past few decades, see my earlier post). While the $19B sale of WhatsApp to Facebook might take most of the attention, there’s been no shortage of other movement in the industry, including the sale of Israeli/Cypriot company Viber to Japan’s Rakuten for $900M, the investment of $215M by Alibaba into US company Tango (at a $1.1B valuation), and the rumored IPO plans of both Japanese company LINE (with some estimates putting the valuation at $28B although that seems unlikely) and Korean company Kakao (priced at $2B). One thing all of these companies have in common is their consumer focus. None of these companies develop business messaging platforms. Undoubtedly many teams within companies use these consumer apps, even if not optimized for their needs, to communicate. What features and requirements would make a business team choose a business-focused messaging platform over a free (or at least very inexpensive) consumer one?

Let’s start with a quick look at who the players are in the business messaging space. It turns out that they are legion. Really. Some examples include Autodesk Instant, Convo, Cotap, Flowdock, GroupMe (owned by Microsoft via Skype), HipChat (owned by Atlassian), Inc, Lua, Ninchat, Podio (owned by Citrix), Slack, SVYFT, TeamChat, Teamvibes, Yammer (owned by Microsoft), and Zula. That makes sense since the investment to get traction in the consumer space is much higher than in the business space. If you want to be successful in the consumer space, people need to feel that all their friends are also going to use your service, but in the business space your solution can be adopted by a single decision-maker and deployed to a whole company. Companies like Microsoft (who has moved Yammer into its Office group), Autodesk, Citrix, and Atlassian can leverage their existing large user bases in the business world to build user bases for their messaging products. It’s not an afterthought that Atlassian’s HipChat product works seamlessly with JIRA and Confluence, their bug-tracking and collaboration products, or that Yammer is being integrated into Microsoft’s Office 365.

For all of the mentioned companies, the approaches overlap but are never exactly the same. For the companies with large existing user bases, their approach to customer acquisition is clearly different than the bootstrapped startup looking to get their first customers. In the overlap between their approaches, however, I think we can extract the basic requirements of group messaging and the features that many of these apps either have, or will likely add in the future.

Search

Users should not only be able to search past messages, but be able to search documents that have been shared. Multi-field search is ideal, allowing searches by text, keyword, person, document type, etc. Search also means keeping copies of everything on secure servers, and having good backups (see below). Just like Google changed the way people accessed web sites (why use a directory of sites, or even keep a bookmark, when you can search and find it), if your search is good enough, they can use it to find discussions from the past, and especially documents shared. Companies can have intranets, or dropbox accounts, set up to share documents, but being able to search within your discussions and find documents in context is a very nice ability.

Shared Directory

This is definitely not a feature shared by all services, although it probably should be. Some services allow you to have a company directory with everyone in your company included. Some also allow default group chats to be set up for different departments, so right from the beginning, there are chats started for sales, marketing, engineering, etc. If you want to add people from different departments for a specific short-term project, you can just select them from the directory and add them to a group chat. A shared directory can also be used as a form of security, since you can restrict users to people in that directory. If someone is fired they would be removed from the directory, and thus would not be able to access any of the company chats anymore. Some group chat services use a company e-mail address as an identifier, making it easy to create a company-specific messaging service, even if you don’t upload a directory, since the user would need a company address to confirm their account. This can be used, however, as a second security layer, allowing only people in the directory to register, and still confirming their account via their company e-mail address.

In these days of BYOD, a shared directory is also a nice way to allow simple communications between employees without having to give out personal phone numbers that employees might not want the entire company to have access.

Security

Business applications need to be secure. Consumer applications should be secure, but don’t need to be. Convenience frequently trumps security in consumer products. That is reflected in the security of the applications developed for consumers, and for example, the large number of security problems found over the years in WhatsApp. Even though WhatsApp has been found to have gaping security holes over the years, they still rocketed to hundreds of millions of active users and were sold for $19B. Either WhatsApp had incredible spin doctors fixing their image worldwide, or more likely – consumers don’t really care about security. If business messaging applications were found to be similarly insecure, they would likely be dropped en masse. This means that from end to end, these apps need to encrypt their data, whether on a mobile device, on a desktop, or on the network in between. This isn’t a premium feature for a business, it’s a requirement.

Backups

If you want to be able to search your whole history of messages and documents, and want to insure everything you expect to be there to be there, then you need to know your data is safe.

Interestingly, WhatsApp doesn’t keep any messages on their servers longer than it takes to get them to their intended recipients. Once a message has gone out to everyone, the message is removed from the WhatsApp server and remains only on the devices of the users who are in the chat. This approach keeps WhatsApp’s expenses down, but creates all kinds of problems from a business point of view. What if new users enter a chat and need to access older messages and documents that were shared? If the user loses their phone, what happens to their messages?

If a company is going to offer a web client, then by definition they need all messages to be stored on a server. If they’re on a server, then they should be on at least two servers, in two different locations. There can never be a single point of failure for business data. Of course, if a company is using extra servers to insure backup of their own data (their messages, their documents, etc.) then obviously you can charge them for that service.

Integrations – Part 1, One-Way

Integrations are connections to external services, which bring information into your existing chats. A good example of this is a group chat for an engineering team might add an integrate with their bug tracker, so each time a bug is added or updated, the change is sent as a message to the chat. Members of the group can then indicate if they will be taking on that particular bug. Several group messaging services offer integrations, such as Flowdock, HipChat and Slack. In general, these integration are one way, or in other words, they only let you see information from those services, but don’t let you respond to that information and have that response returned to the external service. While some of these services have specific APIs to access their data, it perhaps easier to think of them as RSS feeds, where new items are pulled out of the feed and inserted into your group chat. In the end, these integrations show up just like other messages (although they may be formatted differently).

Some services that are integrated with the above messaging services include Asana, Bitbucket, Dropbox, GitHub, Google Drive, Heroku, JIRA, MailChimp, Mercurial, New Relic, Pingdom, Stripe, Trello, Twitter, Zendesk, as well as middle-men services like Zapier.

Actionable Messages

When is a message not a message? When it’s a call to action. It’s one thing to send a message asking which logo everyone in a group likes, but it’s another thing to have embedded in that message a way to respond. Sure, you could ask people to respond with a message, but what happens when someone asks another question in the middle of responses to your question? By offering messages that have actions associated with them, you reduce clutter and can get quick answers to questions you have. Some actionable messages could be polls (which image do you like better?), coordinating a meeting (setting location and time), etc.

In some ways, even simply allowing responses to a specific message is an action. Many chat clients don’t let you respond to a specific message, but count each message sequentially. If you can respond to a specific message, then you can create a comment thread for that specific message, again reducing the clutter in the main message stream.

Polls are easy because they can stand on their own. Creating an action that adds something to your calendar is hard, because the big question is which calendar? If you want to create a separate calendar to use within your app, that’s fine, but what if the business want it to integrate with their existing scheduling system? That leads us to Integrations, Part 2…

Integrations – Part 2, Two-Way

If you have one-way integrations that bring data into your message streams, and you have actionable messages like polls and making appointments that are internal to your messaging app, then the next step is clearly making integrated messages actionable. This means making it possible to respond to a message from an external application and having that response flow back into the external application.

A great example of this is a bug-tracking application, where a new bug is created in the system, generating a message in group message stream (perhaps a group chat for developers). In a one-way system, you might be able to comment on the bug, but it would stay in the messaging system. In a two-way system those comments would show up back in the bug-tracker system. If there are comments added in the bug-tracker system, they should show up in the message stream as well, a true two-way sync. Best of all, if a bug is new and needs to be assigned, the people with the correct permissions should be able to assign the bug from within the message stream. Of course, all of this requires that the external system has an API for allowing data to flow back, something which not all systems allow.

Document Management

Most business messaging systems allow one to share documents. Some documents are shared, but must be displayed using a different application. Some documents, usually images and PDF files, can be displayed within the application. Usually there is some level of integration with file sharing services such as Dropbox, especially for mobile apps, since most mobile devices have limited access to their own file system. This is useful for review purposes, although it’s still difficult to review large documents on small screens. As these apps develop, it makes sense to allow display, and eventually mark-up and editing, of more and more file formats.

Most messaging apps are  set up to share documents, not to manage them. As these apps evolve, adding features like versioning will be the kind of premium features that business users will appreciate. If you’re discussing a logo design, for example, and over the course of a few weeks the graphic designer in your group shares a dozen iterations of the logo design, you should be able to see earlier versions, and also be sure if you load an earlier version, that you know a newer one exists. In some ways this is a killer feature. Imagine how you deal with documents today? Perhaps you share documents over e-mail. Ideally you might have a document management system that keeps all versions of documents. When you want to find something you probably go searching through your old e-mails, as that gives you context to find what you want. If you have a document management system you might have all the versions, but not necessarily the context with which each version was created. By combing your messaging and your document management, you get the best of both worlds – context and organization.

Business Time

Some start-ups are literally working 24 hours a day, but even so not everyone is working at the same time. Multinational corporations frequently have parts of teams working when other parts of the team are sleeping. Being notified of messages when you’re sleeping isn’t useful, particularly if there are a lot of them. Similarly there are times that one doesn’t want to be included in conference calls. Setting a schedule for receiving notifications and a separate one for receiving calls, would be very useful. If you missed messages overnight, you could run a kind of ‘catch up’ mode that shows everything you missed in order. For missed calls, you could allow the user the user to listen to the call, or read a transcript. The ability to record calls and generate transcripts could be premium features (see below). Users could override their set schedules, by saying they are available now (even if it’s the middle of the night) or saying they are busy now (even if it’s the middle of the day).

Audio and Video Conferencing

Several business messaging services have added some form of audio and/or video conferencing. HipChat allows video conferencing and screen sharing. Autodesk Instant, Lua and Zula all offer simple audio conferences among team members. These are useful features no doubt. Sometimes a text message just can’t accomplish what a phone call can, and being able to tap once or twice on your phone and initiate a conference call with your whole team is a good way to get quick answers.

These features are evolving. While useful, I don’t think they’re fully baked just yet for the business crowd. To truly fit within a business messaging service, I think the calls, whether audio or video, should be archived and searchable just like anything else. If you missed a conference call, why can’t you review the call later? To do this you need a few innovations that are just out of reach, but perhaps available soon. First, you need to record all the calls and store them somewhere. To be truly useful you need to know who was speaking at each moment, which means you can’t do the easy thing and record the entire call with a ghost user, a nice hack that works well when you’re just saving the file, but not so well if you want to process it later. Once you’ve recorded the call, what then? A transcript would be nice. That means some form of speech-recognition, or even human transcribers, depending on the quality level you want. Some kind of hybrid system would probably work best. At that point the calls are just a searchable as the rest of the messages and documents. In addition, when reviewing an hour-long conference call, no one want to spend an hour doing so. Rather, one could skim through the transcript, and when they reach a particularly critical point, they can then decide to listen from that point. If you recall the presidential debate transcript viewers from the last couple of US presidential elections, those are good models for how to build such a UI. If your transcripts are good enough, you could even keep them without the audio and/or video. From a cost of storage point of view, that’s a good thing. In the end, it depends what the customer wants to pay.

Multi-Platform and Notifications

It goes without saying that all messaging platforms, whether consumer or business oriented, head for iOS and Android as fast as possible. Consumer apps like LINE and Viber already have moved from mobile platforms to the desktop. In my earlier article about the history of messaging, I produced the following chart which is now probably a bit out of date:

For example, Facebook dropped their Windows client, and WeChat has added a Mac client. Either way, there is a clear trend for adding desktop clients. Depending on how they’re designed, web clients are probably going to be available as well on most platforms. WhatsApp can’t currently offer a web client because, as mentioned before, they don’t keep messages on their server.

On the business side, offering a desktop solution is more important than on the consumer side. This is primarily because the document management side becomes that much more important, and while reviewing documents on a tablet is probably okay, and sometimes okay on a phone, creating documents is still something mostly done on the desktop. The reason mobile clients support loading documents from DropBox and similar services is that they are first loaded to those services from a desktop. It’s true that some documents can be created and edited on phones and tablets, but for many documents that will not be the case for the majority of people.

On the desktop side, I personally wouldn’t want to deploy a full-fledged desktop client. Slack did something interesting and launched a Mac client that is built using MacGap, a desktop adapter for PhoneGap, the multi-platform framework intended for deploying mobile applications. It is essentially a web application with a few desktop integrations like notifications. Notifications are important on the desktop because when working on your desktop you don’t necessarily pay attention to your phone as closely. You can build notifications using HTML5 in a web client, but those only work when your browser is open to the correct page. That’s not good enough. If one is developing a full-fledged web experience, then I a desktop version only needs to fill in the pieces that a web app cannot, such as notifications and document handling. Everything else could be directed to an already logged-in web page. For quick views and responses, you can use the desktop version, but for more complicated interactions, use the web version. You could do what Slack has done and just put your web version on the desktop, but you lose something there too, you lose the ability to get the app out of the way. A desktop app intended to just do a few functions simply will be easier to use and easier to get out of the way then one trying to do everything.

The Dashboard

If you’re going to run a messaging app across your company, with chats for different departments and functional teams, it helps to have a way to oversee things. If you want a shared company directory (described above), you need a place to upload it. If you want to configure group chats for specific departments in your company, you need a place to do that as well. Companies like control over the technology they use. If I was a company there would be several features I’d like easy access to, such as exporting my data (if I want to move to another service), removing employees who have been fired, changing e-mail addresses or other contact information when they change, and other advanced features. Of course some companies would want super-admin features that would allow one or more administrators to see all chats, usage of all group chats, maybe even nice graphs showing how the system is being used by employees (good for the person who made the decision to pay for the service). In short, companies need a way to maintain control over how their employees use the service, and having a dashboard available to manage the service is useful.

Conclusion

What I’ve described above doesn’t describe any existing service perfectly, but I predict some will head in many if not all the directions I’ve outlined above. It’s an interesting field of applications, and while this year might have been a big year for consumer messaging apps, I suspect next year will be a big year for business messaging apps, as they become more feature-complete and more accepted as a replacement for e-mail as a means of coordinating teams.