Zammad knowledge base setup

Before you publish anything, decide how public and internal knowledge will be separated inside Zammad. The safest pattern is to keep public articles and internal procedures in categories that are governed by different access rules, so that visibility is decided by where an article lives rather than by how carefully someone remembered to tick a box on each article. Treat the category structure as a security control, not only as a navigation aid. Agents will reuse internal runbooks, escalation paths and troubleshooting notes, and those documents often contain internal hostnames, vendor escalation contacts or workarounds that should never reach a customer.

Next, map category-level access to your customer segments. If you serve different groups, such as retail customers, business customers under a support contract, and partners, each group may need its own set of articles. Write down which groups can read which categories, who can create and approve articles in each one, and who is allowed to move an article between categories. Then confirm how the Zammad permission model applies to knowledge base content in your installed release, because role, group and organization settings interact and the knowledge base may treat them differently from tickets. Check the current behavior in the Zammad admin documentation and test it with a customer account, an agent account with limited groups, and an administrator account before launch.

The most common failure is publishing internal procedures by mistake. This usually happens when an article is created in a public category during drafting, when an existing internal article is copied into a public category to reuse its text, or when a new category inherits broader visibility than its authors expected. Put an approval step in the process for anything entering a public category, and use a review checklist that asks whether the article names internal systems, people, prices, customer data or unreleased features. Your own environment will determine which of these risks apply, so list them with your support leads.

Plan the monitoring side of this control as well. Review who holds the roles that can publish or change category visibility, and record those changes in your normal change process. If you use single sign-on or directory groups to assign agent roles, a change in the identity provider can change what an agent is able to publish, so include the knowledge base in your access reviews. Also decide how you will remove an article that was published by mistake: who can unpublish it, how quickly that must happen, and whether you need to check search and cached copies for exposure.

Finally, before any AI-assisted drafting from solved tickets is switched on in version 7.2 or later, confirm which categories and roles the drafts will land in and who must review them before publication. Drafts created from tickets can carry customer details into an article, so the same separation rules apply to generated content. Ask your Zammad partner or your own administrators to test this path with sample tickets that contain sensitive data, and confirm the result against the release documentation for your installed version.

Zammad 7.2 can generate draft knowledge base answers from solved tickets and suggests relevant articles in the ticket sidebar through semantic search, according to the 7.2 release notes. Treat both features as assistance for agents and editors, not as a source of published content. The drafting feature reads a solved conversation and proposes an answer that someone then has to check, edit and place into the knowledge base. The sidebar suggestions help an agent find an existing article while replying, which is most useful when your article set is already organized into clear categories and titles. Drafts need agent or editor review before publication. A draft can be fluent and still be wrong about a product version, a policy, a price or a step that changed after the ticket was closed. Set a clear rule for who reviews a draft, who approves it for the public knowledge base, and whether internal-only answers can skip the public review step. Decide this before you switch the feature on for the whole team, and record the owner of each knowledge base category so that stale drafts have someone accountable for them.

Your team must also decide which ticket data is acceptable as a source for drafts. Solved tickets often contain personal data, payment details, health information, credentials or internal commentary that should never reach a public article. Review your data classification and your customer contracts, then define which queues, customers or ticket types can feed the drafting feature and which must be excluded. Confirm with Zammad documentation and your own configuration how the feature selects its source tickets and whether you can restrict that selection by group, tag or state. This section covers what the feature does and the review and source decisions around it. It does not cover where the AI processing happens. Zammad AI features that rely on external model endpoints, and the options for running a self-hosted model, are covered on a separate sibling page. Before you rely on any AI feature in production, confirm the current behavior, required settings and data flow for your Zammad version in its release notes and documentation, and test the feature against a copy of your real ticket history with sensitive content in mind.

Postpone the Zammad knowledge base build if you cannot name who owns the content, which categories it will sit under and how articles will be reviewed. A knowledge base is only as useful as the answers in it, and in Zammad every article is published under a category with its own permissions, so an empty or ambiguous category tree produces articles that are hard to find, duplicated, or visible to the wrong audience. Before any configuration work, confirm a named content owner who can approve articles for both the public and internal sections, and confirm that the owner has time allocated for this role, not just a title on a plan.

Ticket categories come next. If your agents cannot agree on how tickets are classified today, the knowledge base will inherit that confusion. Pull a sample of recent tickets and check whether the existing groups, states and tags map to the questions customers actually ask. If a large share of tickets fall into a catch-all category, fix the ticket taxonomy first, because the category and article structure, the search suggestions in the ticket sidebar and any AI drafting from solved tickets all depend on consistent classification. Treat that as a precondition, not a side task.

Identity and channel decisions also gate the project. Article permissions depend on who the user is: a customer, an agent, or an agent in a specific group. If the decision on how customers sign in, whether through a directory, a social login or a plain account, is still open, you cannot test whether a private article stays private. Similarly, if it is undecided which channels (email, web form, chat or phone) create tickets that should link to articles, the answers you publish will not match the paths customers use. Settle the identity provider integration and the channel list, then build the knowledge base against them.

Finally, check for an agreed review process. Decide how often articles are reviewed, who retires outdated content, and how scheduled publishing will be used so that launch dates are not missed. Without this, the first product change makes half the articles wrong and nobody notices until customers complain. If you cannot commit to a review cadence, start with a small set of articles for the most frequent questions, and defer the wider build until that cadence is working. Ask your Zammad partner to write these checks into the scope so that the decision to proceed or wait is made on evidence rather than on the calendar.