A support forum becomes expensive the moment every thread starts looking the same.
One post is a real question that needs a durable answer. Another is a discussion with no final state. Another starts in public, then has to move private because an account detail or billing screenshot is involved. Another should not go live until a moderator sees it. If the system treats all of those as one generic thread type, the queue turns into cleanup work.
The better move is to make the thread reveal what kind of job it is doing.
Start by giving support its own operating lane
Discourse support category type with solved defaults is the plainest version of that idea. Instead of asking a general-purpose category to behave like a help desk, the team starts with a support lane where answer-state defaults already exist.
That fits naturally beside Discourse solved schema and search priority. One gives the support queue the right operating shape. The other helps the finished answer travel better once the thread is done.
Some categories need only a few questions, not a full support conversion
Discourse solved tags on mixed discussion categories is useful because many communities do not want to split every conversation into separate categories. A tag like question lets one thread behave like a support topic without forcing the whole category into support mode.
That sounds small, but it keeps taxonomy honest. A category can stay broad while the threads that actually need a finish line still get one.
Private escalations still need a visible ending
Discourse solved in group messages for private escalations fixes the support handoff that usually breaks the archive. A public thread often goes private for legitimate reasons, but the moment it becomes a loose group message the answer can disappear into DM fog.
I would pair that with Discourse assignment statuses for public support ownership. One keeps the public queue visibly owned. The other keeps the private escalation visibly finished.
Approval should slow the risky thread, not the whole forum
Discourse category approval rules by trust group matters because moderation is usually ruined by blunt settings. If every reply needs review, the queue becomes a tax. If nothing needs review, the archive fills with noise. Group-based approval rules give the team a more surgical filter.
That is especially useful for support categories, beta programs, and feedback queues where some cohorts need extra checking and others absolutely do not.
Roll out support behavior the same way you would roll out product behavior
Discourse Upcoming Changes opt-in before community rollout is the quiet trust move in this batch. Community settings are product settings. If a new category type, moderation rule, or answer pattern changes how people post, the operator should stage it instead of surprising everyone at once.
The support queue is strongest when each thread advertises its job early: discussion, answerable question, private escalation, moderated intake, or experiment in progress. That is a practical lesson for SaaS, AI products, developer tools, B2B software, and open-source products whose community doubles as help desk, onboarding surface, and trust layer.
If you want help tightening support threads, docs, and community infrastructure into a cleaner growth system, the advisory CTA is here: work with Ian Goh.