A complaint keeps turning up across the communities we follow, from people who don't work together and aren't talking about the same product: they are tired of being told to join a Discord server for support.
It sounds friendly. A server is quick to stand up, customers already have the app, and it feels more human than a ticket form. Then the same question appears for the third time in a week, because the earlier answer scrolled away. Someone else suggests a contact form on the site plus a public bug tracker. Another group, talking about something else entirely, says they miss older forums: threads stayed put, you could find an older answer, and the place felt calmer than a feed full of bots and takes.
We build community and Q&A software for a living, so we hear this from both sides: teams who picked chat because it was easy, and customers who are tired of searching a scrolling room. Here is a setup that keeps the useful parts of chat without making it the only memory your product has.
Why chat-as-support starts to hurt
Chat is good at "someone is stuck right now." It is bad at "someone was stuck earlier, and a stranger later has the same problem."
In a busy server, answers have a short life. They sit between welcome messages, off-topic jokes and other people's incidents. The next customer cannot search well, and your own staff cannot point to a stable link. So they answer it again. The customer who waited also cannot tell which reply was the real fix, because nothing is marked as the answer.
There is a second cost that is easy to miss. A Discord server for support is rented land. If the account that owns it disappears, or the invite expires, the history does not move with you in a form you can hand to the next teammate. Customers who only ever found you inside that server have no page to bookmark.
People who say they miss older forums are usually missing those two properties, not the software itself: a thread that stays in place, and a way to mark what actually worked.
You do not have to kill the chat
The useful disagreement in these conversations is not "chat versus a form." It is which job each surface should do.
Keep chat for:
- A customer who is mid-setup and needs a push
- Incidents that are happening now
- A little social glue, if your users actually talk to each other
Do not keep chat for:
- The first place a new customer is told to look
- Anything you will be asked again
- Bug reports you will want to find in six months
- Decisions about how the product is supposed to work
A reply we keep seeing, in different words, is the split: a form or public Q&A on your own domain for questions that will recur, and a tracker (GitHub, GitLab, or whatever you already use) for bugs. Chat becomes the overflow, not the archive.
A setup that works in practice
If we were helping a small product team move off "just join the Discord," this is the order we would use. It works whether you use a hosted help desk, a forum, a static docs site, or a Q&A plugin.
1. Put one durable address on your own domain
Pick a URL you control: example.com/support, example.com/help, or example.com/qa. Everything else can change. This address should not depend on an invite link.
2. Write the ten questions you already answer every week
Sit with whoever does support and list the questions that arrived more than once. For each one, write a short page: the situation, the steps that fix it, and what "done" looks like. Mark an official answer so a reader is not left comparing three conflicting replies.
If you already have good explanations sitting in chat, copy them across. Rewrite just enough that a stranger can follow them without the rest of the thread. This is slow the first time, then the next repeat question is a link.
3. Give bugs their own home
A support chat mixes "how do I…?" with "this is broken." Those are different jobs. Bugs need a title, a way to say "we can reproduce this," and a record of what you shipped. A public issue tracker does that well. A form that creates an issue does it too. Putting both kinds of request in one scrolling room means the bug report disappears under the how-to questions, and the how-to questions disappear under the incident.
4. Decide what stays private
Not every answer should be public. Account-specific billing, security reports and anything that identifies a customer belong in a private channel: email, a ticket, or a staff-only room. The public Q&A is for problems that any customer could hit. That split is also how you avoid turning support into a second community you now have to moderate.
5. Send people to the page first, then to chat
Change the in-app "Get help" link, the docs footer and the bot welcome message so they point at the help address. Mention the chat room as a place for things the pages do not cover yet. When someone asks a new question in chat and you answer it well, add the page that same day. If you wait, you will answer it again.
A founder who ran a few-hundred-person group in a single chat thread described the other version of this problem: one room, no segments, arguments landing on top of useful replies. The same idea applies to support: do not make every kind of question share one stream.
What to use (and what we would skip)
Tool-agnostic options that all work:
- A docs site with search, if your answers are mostly how-tos (MkDocs, Docusaurus, even a well-organised Notion export published to your domain)
- A small forum or Q&A section on your site, if customers answer each other and you want a marked solution (Discourse, GitHub Discussions, or a Q&A plugin such as Jetonomy, which we build, so weigh that accordingly)
- A dedicated help desk (Help Scout, Freshdesk, and the rest) if you need private tickets and a public knowledge base in one place
What we would skip, at least as the only layer: a Discord category called "support," a WhatsApp number, or a Telegram group. Those are fine as overflow. They make a poor system of record. WhatsApp has an extra problem some community runners have hit: it exposes members' phone numbers to everyone in the group.
Self-hosting the Q&A is optional. Owning the URL and an export of the answers is not.
A simple test that you are done
You can tell the new setup is working when a teammate can paste a link instead of rewriting the same paragraph, and a customer who never joined the chat can still solve the common problem. Count how often the same question arrives twice in a week. When that number drops, the archive is doing its job. The chat room can stay. It just stops being the only place the truth lives.
Your turn
- If you still send people to a chat server for support, what question do you answer most often, and does a page for it exist yet?
- Have you moved a set of chat answers onto your own site? What did you keep in chat on purpose?
- Where do you draw the line between a public help article and a private ticket?
- If you have tried a forum or Q&A next to a chat room, did customers actually use both, or did one go quiet?
