"OK," you may be saying, "this was long and informative and long, but what I really want is an easy checklist of what I'm supposed to do or avoid." Well, we have that for you, too. Here's what our App Review team wishes everyone knew about:
Installation, onboarding and introductions
- While you shouldn't send an unexpected message into the General channel (or any unexpected messages anywhere), we understand that you want to share the news about your app with the team. To do this, we have a couple of suggestions:
- Ask the installing user for permission to send a welcome message into a channel chosen by the user before then sending a welcome message with a suggestion that users can start using the bot (or perhaps suggest that they DM the bot with a 'help' message to get started)
- Ask the installing user if they would like to trigger the bot to send a message to other users on the workspace (either all users or a subset or those users — make this difference explicit)
- Give the installing user some suggested copy that they can copy and paste into a channel or DM of their choice to introduce the app to the relevant members
- If you're requesting a large number of scopes but only require some scopes for certain optional functionality, consider adding the option for the user to select which scopes and functionality they'd like to allow upon installation. This reduces the scopes requested of the workspace, and you can always allow them to add that functionality and the associated scopes at a later point.
- Provide the user installing your app with a "Success" page after the OAuth flow to let them know the app has been installed correctly. Make sure you also add some helpful hints about how to get started with using the app straight away. Whether that's sending a Help message to your app's bot user, waiting for a DM from the bot, or waiting for a notification to be triggered, give the user some guidance about what to expect next or what action they might need to take to get started.
- Don't send any emails to the installing user, or any other user on the workspace, using the email address information you collect from your app's installation without the explicit permission to do so.
- Don't send a DM to every user on the workspace when the bot is installed — this is an extremely poor experience for users
- Don't add your bot user to a channel (or channels) without permission and a clear warning to the installing user. workspaces that suddenly see a bot appear in their channels unexpectedly will find this a surprising and uncomfortable experience. Best to ask for permission first, or send the installing user a DM to remind them to add the bot to a channel to get it working (if it does need to be added to a channel to be used)
- Make sure you have a clear and helpful response to a "Help" message from users. Whether a user is communicating with a bot in a channel or in DM, having a helpful response to any request for help can help users on the workspace get to know your bot and what it does more quickly. Since you're a bot on their workspace, it's only polite to give them a helpful answer when they are confused or ask for help.
- If your app doesn't have a bot user but does have a slash command, make sure to add a
/myapp help command so that users can see the different commands available to them and learn more about the app, all at their fingertips in Slack.
- Don't send unnecessary notifications. If your app does send lots of notifications make it easy to opt out or configure them.
Contacting users about updates
- If you want to share updates about new features, consider bundling updates so that you're not sending a message every couple of days for new updates or changes.
- Only send updates about new features to the app installer/app admin.
- If updates require additional scopes, provide the appropriate link to reauth in your update message
- Do not send updates about new features all the time, and definitely do not send them to all users on a workspace. This is very frustrating, especially for members who might not be using the app.
Converting users to paid
- Don't send a message to every member on the workspace, or even every user making use of the app suggesting they upgrade or offering free trials. Consider sending a one-off DM to the installing user to let them know of any offers
- Do not send messages about this every day, or even every week. This will likely be seen as spam by the team and lead to frustration.
- If your app has a bot user, consider adding a way for users to get in touch with you directly with feedback. If you're going to do this though, make sure it's clear when they send the message that you'll be reading any messages sent using the feedback command. And if you want to be able to reply to the user (by email), make sure you're asking for permission/making it clear that you might be getting in touch with them.
- Do not send DMs to all the users on the workspace at any point unless the authorization for this is given explicitly by another user (with the full understanding that they're acceptance will send a DM to all users) — this is a very poor experience for a workspace, whether it's during installation or after they've been using the app for a while.
- Do not spam members with messages, even if they are actively using the app. They might want to know updates from you about the app, but any unwanted or unexpected messages sent across the workspace, or even just to one person, will cause surprise and sometimes frustration. This can be enough for users to uninstall your app.
This might seem like a long list of what you can or can't do, but if you have any questions or suggestions about anything on here, do send us a note to firstname.lastname@example.org — we'll be happy to help!