Models of Slack Support

I was recently was part of a conversation about different types of support models over Slack. So here it is reposted for all. Here are some of the trends we have seen in how companies are currently offering customer support over Slack and some of the pros and cons.

Open Community Slack:

‍This is where anyone can join through your website even before being a customer. It’s used to announce updates and releases. Support and engineers help customers/prospects in an ad-hoc way so there is no time guarantees or SLA. If someone has a question, customers, agents, and bystanders will often discuss it in a public channel (for the benefit of others as well) but will sometimes resort to a DM.

Open discussion between “customers” is more likely for open source projects and complex systems where there are lots of docs, and experts are not only employees. So really deflection from other community members is more likely for open source projects and least likely for regular software products.

Many companies will offer higher-cost support tiers by creating private channels in this workspace. They will staff this with a bunch of employees to monitor the channels or have named account executives that are assigned to monitor specific company channels. (Of course, there are complexities around how to staff this, how to centralize conversations, how to get reports and metrics and this is where we can help foqal.io)

Workspaces will generally have:

• A general channel that ends up being the default support+everything channel,
• Announcements channel which will be a read-only channel for company and product announcements,
• A few other support/new user/help channels that might have a few questions between them,
• A few product or feature specific channels which are usually pretty empty,
• And a few channels for things like Donut to help people connect (which I think people often ignore).

Many workspaces often set up GreetBot to welcome people into the workspace, tell them about the different channels, and sometimes require members to agree to a Code of Conduct.

Many often have an introduce-yourself channel asking every new person to say who they are and what they are doing here. You can set up Greetbot to tell each new user to introduce themselves, but either way, a manual warm greeting from you is always a nice touch — helps them get started and have someone to talk to when they first join.

Open Community + DMs‍

Another approach companies are using to offer support is setting up the open community but keeping most conversations in Direct Messages. This is where there is a central channel that everyone is invited to. People in the channel will either ask for a Direct Message manually or click a button (again we can help with this foqal.io/enterprise) to get support. When asked, agents will rotate taking questions from this central requests channel and mark read conversations with an emoji. This central Direct Message request channel becomes like your inbox or queue. If using automation, these questions can go into your customer support system like Zendesk, Freshdesk, Intercom, etc and agents will answer questions from the associated queue.

The good part about this it's very simple — there is only a single way in which customers get support, you can create a queue of questions so demand is a bit easier to predict, and you don’t waste resources monitoring a bunch of channels at once.

If this works well, another benefit is customers don’t make friends with specific agents and don’t reach out to an agent directly for help. This can often happen in regular Open Communities.

The downside of this approach is that without some tooling, there are no metrics and reports. If your agent starts a conversation and leaves for the day, no one has visibility to pick it up. And you never build a true Slack community around your product.

Private Community:‍

Some companies prefer just to create shared channels. This is where your private Slack workspaces are connected together with a single channel and your customers are not forced to join another workspace. The problem is, to create a shared channel, you need a paid version of Slack. Most companies can not afford to pay for each member of an open workspace. In this case, companies use their internal paid Slack workspace to create a shared channel with each of their customers or only the ones that pay for that premium tier. For customers that don’t have Slack, have security concerns, or simply don’t want to use shared channels, companies create a channel and invite them as a single or multi-channel guest.

The benefit of this approach is it requires fewer workspaces to monitor and you only have customers to answer — reducing the number of requests you would otherwise get. This also feels more exclusive to the customer.

The downside, is there are no leads or potential customers in the workspace that can automatically join your Slack workspace through your website and learn about your product before signing up.

Conclusion‍

Really most companies do support in very different ways. Some use one of these models, some combine multiple models. But at the end of the day, everyone is looking at the best ways to bring teams together with Slack. When you need help bringing your customers in to Slack, getting reports, metrics, or centralizing your customer conversations from across these different models and channels, let us know!

‍

‍