The Community module launches with two main content surfaces: a classic, manually edited Knowledge Base (KB), and an LLM-generated auto-FAQ that synthesises new articles from the previous week's questions. The two surfaces have different scope, different management rules, and different safety nets.
The KB: tenant-admin editable
The Knowledge Base is vendor-curated content with tenant-specific overlay. The vendor ships a common baseline (~120 articles at launch: how the Finance NAV integration works, how to run a multi-warehouse stock take, etc.). Tenant admins can extend that with tenant-specific articles: their own workflows, their own procedures, their own onboarding material.
KB articles are written in markdown, version-controlled (each save creates a new revision), and per-article visibility-scoped (tenant-peers only, or cross-tenant public). Validated, vetted answers go here, not into a forum thread.
The auto-FAQ: generated from three sources
The auto-FAQ runs once a week and generates proposals from three sources:
- Top support tickets. The most-frequently-raised support topics for the week. Ticket text is anonymised (names, company identifiers, account numbers replaced with placeholders), then embedded and clustered.
- Top chat-agent transcripts. Chat-agent-answered questions where the customer feedback ("helpful" / "not helpful" button) was explicitly positive. Anonymised only.
- Resolved community questions. Threads marked resolved during the week, where a solution was tagged "Accepted Answer".
The three sources yield ~20-40 proposals per week. An LLM (GPT-5-class) formats each proposal as a Q&A, marks its source ("based on 7 support tickets and 3 community threads"), and queues it for admin review.
The approval flow and the eval gate
Proposals land in an admin queue (weekly digest email). Vendor-staff approval has three outcomes: publish-as-is, publish-with-edits, or reject. Every decision is recorded in the auto_faq_decision table.
The number we track auto-FAQ quality with is: % of FAQs that the human approver edits. Target: <30%. If that climbs above 30%, the LLM prompt needs regenerating or the source data is muddy; the iteration loop continues until the metric holds.
Rejected proposals go into a negative-example set that the next LLM-prompt iteration uses as a hint.
Two categories we deliberately do NOT auto-generate
-
Security advisories. When a security-related question shows up in support, the vendor security team always handles it manually, because an LLM-generated security article gone wrong doesn't just mislead the user, it actively expands the attack surface. Security advisories live in a separate, manually edited KB section.
-
Pricing. Pricing questions stay out of the auto-FAQ. Both list pricing (which can change) and tenant-specific discounts (which depend on contracts) are sensitive content we don't want shipped LLM-mediated. Pricing questions route to the sales team, auto-excluded from the FAQ pipeline.
What the approval rate means in practice
A <30% edit rate means roughly 65-70 of every 100 proposals ship without edits, 25-30 ship with minimal (1-2 sentence) edits, and only a handful are rejected. That's a sustainable weekly workload: ~30 minutes of admin time per week, not a quarterly rewrite-the-FAQ sprint.
Refresh cadence and stale detection
KB articles are not static. Each article has a last_reviewed_at field that the tenant admin can refresh manually. If an article is more than 6 months old and related questions are arriving via chat-agent or forum, a weekly reminder surface flags the admin that an update may be due. This is not auto-rewrite (same principle as the security + pricing exclusion above), just a warning digest.
Stale detection fires from two signals: (a) a chat-agent transaction that answered well from the KB, but the user feedback was "not helpful"; (b) a forum thread where the answer to the same question diverged from the KB and the thread closed with a peer-marked "resolved". Both signals push a stale-score, and anything above 3 lands in the digest.
Multilanguage and the HU/EN pairing
The Netorigo platform runs in both HU and EN. KB articles default to the tenant's primary locale, but we maintain both languages for every article. The LLM-generated auto-FAQ synthesises proposals from combined HU + EN ticket sources and proposes both languages at once to the human approver.
The human approver doesn't have to edit both languages by hand; the approve UI offers "approve HU, retranslate EN", which sends the HU-edited version back through the LLM for an EN draft, with a separate mini-approve.