4 Lessons We Learned Building a Slack App

We started Kipwise to help teams learn more efficiently by adding highlights and comments on shared content in Slack.

In order to live with our mission of empowering knowledge transfers, we decided to share our learned lessons during the journey of building Kipwise; the things you should pay attention to when building a Slack app (or chatbot in general) can be very different when compared to building a website.

It is so easy to fall into the trap of building a Slack app/chatbot that is too annoying within the chat interface. A lot of the time, it is very difficult to get the right timing in sending the right message. It is like building an intimate relationship; being annoying is not the best way to approach your crush.

Here are the four best practices we have learned.

1. Don’t just sit there. Don’t talk too much either.

Be simple yet clear with your onboarding messages

Onboarding is the most important part of every software, including Slack apps. It starts with a user installing the Slack app, but it never ends as long as there are new members joining and new features getting introduced.

When we first began, we didn’t really provide a step-by-step onboarding process, as we thought users would read our app description or website. That was dead wrong and frustrated the friends who believed in us and tried us. (Sorry Keith!)

It took us a whole month to continually iterate and make the onboarding process good enough. Thanks Kristine for the extra feedback.

One important thing to keep in mind is that your Slack app might offer a lot of features, but your users probably won’t want to learn all of them in one go. We learned that most of the users would skip the instructions if they were too long, and even if they did read the instructions, they would still forget about the exact steps when they needed to perform the actions in the future.

Many Slack apps onboard users with a private message introduction, but most users won’t expect to receive a 500-word long instruction and would simply skip it if they see one.

Try to send a long message to your crush via WhatsApp/Facebook Messenger

Instead of sending everything in one go right at the beginning, we found it way more effective to send users instructions step-by-step when they really needed to perform that action. It works better to skip some not-so-important features during the first touch instead of squeezing all of the possible use cases into one full-screen message.

2. Don’t hurry to introduce yourself

Don’t send onboarding messages to new members

For example, Company ABC already has 5 Slack apps installed for their team. They recently hired a brilliant rockstar, John, and invited him to the ABC Slack team. Boom! John received 5 new conversations from 5 apps instantly.

John is very unlikely to read all the messages, as it is probably too early for him as a new hire to understand the benefits of these apps when he just joined the team and doesn’t even know most of the workflows in the team yet.

There’s no obvious advantage of sending introductions to new members besides confusing the new member further.

Introductions are more engaging when triggered at a point when the new hire really needs it, or when asking the person who invited the new hire to trigger the onboarding message. The flow could be very different for different Slack apps. Nonetheless, sending it ASAP when someone joins the team is likely not the best option.

You will be more special when you introduce yourself at the right time.

3. Don’t be too demanding

Don’t build a TrojanHorseBot

Theoretically, a Slack app can read everything on every channel, including all private ones, if you gave it the permissions to do so.

It always feels easier to develop a Slack app by asking all possible permissions that one can get right at the beginning. However, it looks scary to the users and is unnecessary most of the time. We started as a QuiteDemandingBot and got many rejections (thanks, Steven, for rejecting us).

Look at that list

When looking at the permissions that a DemandingBot needs to get, users will feel like they are going to install a Trojan Horse that will collect every single secret from their team chats. It is normal for users to be skeptical with that long permission list. Being too demanding is always a bad move for a relationship.

Slack is going to launch a new Workspace-based flow for apps to ask for permissions progressively. Before that, it takes a few more steps to ask for permissions on-demand, and is a bit more complicated to implement but definitely worth doing to convince users.

4. Don’t try to do everything

Don’t do EVERYTHING via chat

There’s a reason that different apps and platforms exist; they are built for different purposes. Some actions could be done in a much easier way outside of Slack.

With the natural limitations of chat interface, some complicated actions become error intolerant. For example, there’s no good flow to correct typos just like a simple web form would do when asking for freestyle-input from users via chat.

There are some amazing interactions that happen nicely on chat platforms, while some interactions work much better outside Slack.

It is not necessary to build every action on Slack that might not fit the best in chat interface. Bringing the users to your website when needed could be a better option as long as it is helpful.

Let us know your experience with different Slack apps/bots in the comments section. We’d love to learn more from you as well. We believe that knowledge exchange is the fuel for growth.

If you are interested in discussing anything about building/running a Slack app (or in general, a chatbot), connect me at [email protected]. Happy to exchange knowledge!