Your app only has one chance to make a first impression, so it's worth the time to make your onboarding experience a great one.
When people first interact with your app inside Slack, they may have different amounts of background context about your app and what it does:
Your onboarding should equip people to get something done as quickly as possible, no matter what context they have. Determine the key tasks you need a user to accomplish in the first 30 seconds of interacting with your app, and design your onboarding to help them get it done.
It's reasonable and a good idea to have a bot announce its presence and teach people how to interact with it. There is, however, a fine line between being informative and being spammy. Here's how to do it right:
Have an informative, concise welcome message When someone installs your app, it's a good idea to DM that person with a welcome message. Welcome messages should include instructions about how to use your app, and how to integrate it into your workspace.
Only the installing user should get a direct message from your app. Once that user has given you permission to enter a channel, communicate with the rest of the team there. When a bot is added to a channel for the first time, it is polite to have the bot announce its presence together with a short, instructional help text.
Your welcome message should contain enough information to help someone complete a task for the first time. That said, you may want to help people get acclimated to using your app beyond the first quick-win scenario. Let people choose to have an extended walkthrough for more complex tasks.
Onboardings should be skippable. Some users who appear new may have used your app before on other Slack workspaces. Others will find your app intuitive enough that they'd prefer not to be helped. Let users choose when to interact with your app.
A good onboarding is proactive help for getting people up and running. Even after a well-designed onboarding, people may still have questions about or need help interacting with your app.
If you have a slash command as part of your app, it's common practice to provide a help action, e.g.
/myapp help , that will respond to the user's request. The response could be as simple as printing a list of possible actions, or as detailed as triggering a flow to create a support ticket.
Just as you would with a slash command, responding with text or an interactive menu will help your users feel taken care of. Remember that the best help doesn't require them to leave their working context inside Slack.
People don't just want to reach you when they're critically stuck. Sometimes, they'll want to give feedback on simple things like the ease of going through a particular workflow, or whether a bot successfully understood their intent. If you have a place to route feedback requests, provide a way for people to get there inside Slack. Only offer a feedback channel if you plan to collect and review feedback.
Use of apps spreads differently among work colleagues than it does among groups of friends. Above all, be considerate with your use of notifications and announcements to channels. See the being a good citizen inside Slack section for more details on how to do this.