Tips to build better customer relationships with broadcasts

We initially built our Slack integration in February of this year, and have been making regular updates with the introduction of discussions, in-Slack actions from notifications, AI based ingestion, and more since.

Since then Slack has quickly become the main support channels for our customers. With this has come a natural shift in how you talk to customers beyond support. Updates like changelogs and product launches that would typically go out to customers in email blasts, now need to be sent through Slack as well. The way we saw our customers do this was via hacky self-built scripts or by annoying manual and error prone copying and pasting.

We also noticed that broadcasts is a vital feature for the same reasons for companies who are just getting started with doing support on Slack, and mightn’t have a need for a full support platform just yet. Equally, sometimes marketing is responsible for these messages and you naturally don’t want to pay for a full support seat just for them in your support platform too.

To fix all this we shipped Plain broadcasts as a standalone app, so our existing users could make use of it at no extra cost – they don’t need to add marketers to Plain – and so companies that don’t use Plain don’t need to sign up for the entire platform to use it.

And it’s free because we wanted it to be.

Here are some tips on how to make the best use of broadcasts as a marketing channel, and to be proactive with your customer comms.

Prepare ahead, get organized

One huge benefit of using broadcasts over Slack directly is that you can do the work of setting up your audiences, writing drafts, and sending previews before you need to send a broadcast. This means you can get all of your ducks in a row in advance without getting into a last minute tizzy.

We’ve got audiences set up at Plain for different kinds of customers and teams, and we also built audiences around specific features we’re working on where we can quickly ask for feedback or share updates with all design partners.

Set up drafts and send previews before you send them, so you can make sure your button goes to the right place and the message looks good.

Use broadcasts to start conversations – don’t treat them like a newsletter

What works for email can feel impersonal and even spammy in Slack. Don’t over-use the traditional newsletter format – big title, lots of images and emojis – in broadcasts. Broadcasts should feel custom to your users. If they feel like a newsletter people will ignore them and it will feel out of place in a channel where you normally just talk.

With the ability to customize your audiences, broadcasts are a great opportunity to do personalized marketing and request feedback on how customers are using specific features. Ship something cool recently? Ask your customers for feedback and get some insights into improvements you can make.

Be mindful of when you send broadcasts

We’ve all unsubscribed from receiving emails from companies that spam our inbox – broadcasts should never even make someone consider wanting to unsubscribe or opt-out. Build audiences that match your customer tiers and make sure your broadcasts are relevant to your chosen audience, every time you send one.

Broadcasts should feel natural and unautomated. Don’t block the flow of conversations that are already in flight. If you know there’s a customer your support team is in the middle of helping in Slack, or there’s a customer that’s been having issues with your product, step back and check if it’s the right time to send your broadcast. Track the customers you want to send the message to at a later date in an audience and draft the message so you don’t forget to send it.

Make broadcasts part of your incident process

When an incident is declared at Plain we normally assign the task of communicating updates and impact of the incident to our customers to a team member. They are then responsible for the duration of the incident to handle all public comms.  Broadcasts can be really useful in this situation as they can make the process of making customers aware of an incident and our progress on fixing the issue really fast and efficient.

What we’ve done during an incident previously is create a specific audience in the broadcasts app for the impacted customers with the name of the incident. We can then quickly and seamlessly tell people about the incident, point them to the status page as well as follow-up later as the incident status changes.

Because we use Plain for our own support, this also means that as people reply we can efficiently handle the replies directly from Plain – which is especially helpful if our incident is impacting access to Plain for us 😅.