Slack Community channels

How many channels does your Slack community have? Is 1 too little? Should you add a channel per topic? How about a channel called feature-requests? The short answer to this is for as long as possible, the fewer channels the better.

For as long as possible, the fewer channels the better.

The biggest barrier to building any community is the chicken and egg problem — until you have lots of users and lively conversation, it’s unlikely that others will want to join or stay engaged in your community. So there is nothing that will sway your members away from your community like joining it and finding it void of any conversation for the last 8 months.

When joining, the user should feel like they are welcomed, introduced to the community, and are immediately part of a stream of conversations between engaged members of the community. So first, configure member default channels to join just a couple the most popular ones and disable members adding new channels.

The case for more with less

Let’s think about this from the user side. Let’s say you have a question about the “best way to create a sourdough starter”. First, you figure out which channel to should ask — the “#sourdough” channel, “#baking” channel, or “#starters” channel. You reluctantly go to each and see how recent the last messages were posted and how lively the channel is to guess the likelihood that you get a response quickly if at all. Next, you post the question and wait. While waiting for a response, you go through the previous questions in the #baking channel since you know a lot about that and completely skip the #bbq channel even though another member asked a question just 5 minutes ago that you do know how to answer. Since no one answered your question while you were browsing, you will probably just leave the community and forget that you even asked the question to begin with.

Compare that to the universe where there is just 1 channel — as soon as you enter, you will see and respond to the question about BBQ, make a connection with a new person, ask your question about sourdough starters and get a response from anyone currently online. Next time you have a quick question about anything related, you know exactly where to ask.

By reducing the number of channels, you increase the probability of users seeing each other’s questions, making connections, and getting real value from your community. With fewer channels, there are more conversations per channel — making them seem livelier and more active.

Product-based Support Communities

How does the number of channels affect you if you run a product-related support community? One in which members are generally your customers or leads? In this case, it’s even more imperative to have fewer channels —

1. The more channels you have to monitor, the less your team seems to notice the less frequent ones. If 90% of the questions are coming into #support and a question comes into #baking — without Agent software to help, how fast does your team notice?
2. Community-based deflection (as in having others in the community answer the question) is less likely as others are also less likely to see the question. Also in product-based communities, this is very rare to begin with.
3. Cognitive dissonance — when a customer wants to ask about a topic related to multiple channels they don’t want to think about the best channel to do so. They simply want to ask and get a response quickly.
4. More chatter — The more chatter that your community has, the more lively and “bigger” your product feels. Do you want to be the first or only company using a product? The more chatter and conversations that customers see, the less it feels like you are the only one.

Overall in the context of a product-based community, unless you are in the open-source space, I recommend using the private shared channel approach — which I will talk about in a future blog.

When is a channel too big?

If you look at the Kubernetes Slack community, the #kubernetes-users channel has 100,000+ people alone. Anyone joining immediately sees a very lively community with members posting 24/7. The problem is with so much chatter, about 30% of questions are skipped by ongoing conversations. But with so many members in the Kubernetes community, each channel ends up being its own sub-community.

If your channels start becoming too big, questions are being dropped due to other chatter, and people are not posting because of streams of unrelated conversations, it may be time. But don’t create a new channel, build a sub-community. You should understand if you create a new #sour-dough channel, how many members from the parent community will join? Who will be the leaders, power-members, and influencers most active in this sub-community? How will new members find out about this sub-community? How do you differentiate this sub-community from others to reduce cognitive dissonance when members don’t know which to join or where to ask a question?

Most often, certain members passionate about an idea will ask to create this sub-community. Those members will be most passionate to keep it going and will be the power-members. But ask, are those members vested in keeping the sub-community alive like I am? If they are not or not willing or understand how much effort is required, its best to not invest and spread the community too thin.

Remember: if you do find yourself with too many channels in Slack or otherwise and are missing customer’s questions, or want a single queue of all customer requests, Agent can help! Agent gives you a queue of all your customer’s questions from across all your Slack channels, workspaces, emails, and other mediums in a centralized queue directly from Slack. Yup — support your customers over Email and Slack from a single place.

‍