What the Slack Platform Should Look Like

Slack has an incredible product, mind-blowing growth, and is making big strides to establish itself as a meaningful platform. It’s no surprise to see predictions that $100M+ businesses will be built on the back of the Slack platform this year.

I’m confident it’ll happen — I’m a huge fan of the product, and the company seems to have the talent, culture and war chest to build a platform that rivals ones like Salesforce in importance and scale.

In fact, I’m betting it’ll happen as I work on Jell. A lot of our growth has come because of our Slack integration — over 70% of our active companies have integrated Jell with Slack, and that number keeps growing.

That said, there are still a number of weaknesses in the platform that keep users from having a first-class experience. If these are fixed, it would also make it more compelling for developers to build on Slack, and increase the overall value of Slack as a platform.

Here’s how to make the Slack platform even better:

Application Cards

The ability to build bots on the Slack platform is fantastic, but there’s a lot lacking in the user experience.

We’re still a long way away from developers having the tools to build really solid AIs so users can talk to a Slack bot using natural language. And it’s improbable that most users will learn the esoteric syntax understood by most bots, or all the parameters for advanced slash commands.

What we’re left with is a lot of apps that either do very simplistic things, or apps that quickly send you to a browser to interact with the app away from Slack.

How much more powerful would Slack applications be if they could embed “cards” directly into the Slack conversation for users to interact with? So instead of having to learn a list of keywords or commands, developers could embed a simple form or display a set of actions you can take.

Avi Eisenberger described this idea perfectly a few months ago, along with a great example of how this would work with an HR app:

Image by Avi Eisenberger

Contrast that against the alternative of developing the AI to understand this:

@pto I have to go to the dentist tomorrow. Can I take a half day?

Or to use a slash command that looks like this:

/pto request 2016–01–29 2016–01–29 4hrs “dentist appointment” #sick

Yes, there may be complexities in building this into Slack, but even if cards are initially limited to just a few simple properties, this could drastically improve the usability of Slack apps.

User Provisioning

Slack apps are currently limited because of the lack of APIs and a user experience that allows for seamless user provisioning and authentication.

Most meaningful business apps will need to authenticate each user with their respective service. Today, each user needs to go through a separate signup process to create their accounts and setup Slack authentication. Inevitably, some people on the team aren’t going to go through the process, hurting adoption and utility of new apps.

Imagine instead that as a Slack administrator, when adding an app to your account you can automatically provision accounts for everyone on your team. And as you add more people to your team, the hooks are in place for the proper accounts and permissions to be setup on each of your Slack apps. Or if someone is removed from your Slack account, that’s handled seamlessly as well.

This would mean that as an end-user you’re able to use the /pto command on day 1, without having to figure out how to connect your Slack account with the PTO service.

Monetization

Slack’s in a unique position to monetize the ecosystem by handling subscription services for apps on their platform. Quite simply, they could create a way for developers to build paid-only or freemium apps that charge the credit card you have on file at Slack.

For developers, it’s compelling to have a clear path toward monetization. This should lead to bigger, better apps being built on Slack’s platform.

As an end-user, it would give me a much-needed way to manage my long list of software subscriptions in a central place, listed on a single invoice. And Slack should be able to pull together the data on how many of my team members are actively using our Slack apps, and bill accordingly.

There are certainly some hurdles here for apps that have substantial functionality outside of Slack, and many of them likely wouldn’t want Slack handling their billing process for strategic reasons. But it’s feasible to think that a Slack app store would improve conversion rates enough to make it worthwhile as a monetization channel.

More

I’m sure there’s potential I haven’t even envisioned yet. And I know the Slack platform team is really just getting started.

It’ll be an exciting year.

Note: This post originally appeared on the Jell blog.