Getting started

You’ve ordered a managed Zammad at server.camp — congratulations! Zammad is a professional helpdesk and ticketing system: customer requests via email, chat or phone are collected, processed and tracked in one central place — no request slips through the cracks. This guide is aimed at freelancers, small and medium-sized businesses and associations that want to put their support on a structured, traceable footing.

In many SMBs, customer support runs through private mailboxes or personal mobile numbers. This leads to the usual problems: requests get lost, nobody knows who is currently working on what, and when an employee is off sick, the customer contact is gone.

Zammad creates a central overview: every request becomes a ticket, and every ticket has a status, an owner and a complete communication history.

Typical use cases:

• Centralise email support — support@example.org lands directly as a ticket in Zammad
• Internal helpdesk requests — structure IT support requests from your own staff
• Customer project communication — all messages about a customer in one place
• Order processing — handle incoming orders or requests in a structured way
• Escalation management — make high-priority tickets immediately visible
• Team collaboration in support — several people work on tickets without overlapping
• Time tracking — how much effort goes into which customer or project?
• Knowledge base — answer common questions once, reuse the answers again and again

Zammad has four central elements:

• Ticket — a single request, from creation to resolution
• Group — a team that tickets are assigned to (e.g. “Support”, “Sales”, “Technical”)
• Organization — a customer or company; all tickets from one organization are grouped together
• Channel — where do tickets come from? (email, web form, phone, chat)

A typical flow: a customer emails support@example.org → Zammad automatically creates a ticket in the “Support” group → agent Lisa picks up the ticket → she replies directly from Zammad → the customer receives the reply by email → the ticket is set to “closed”.

For a clean setup we recommend — following the official Zammad First Steps — this order:

1. Create groups — define your support teams (the basis for everything else)
2. Configure the email channel — so that tickets can be created at all
3. Review roles and permissions — define who is allowed to do what
4. SSO integration — connect users via SSO (OIDC, SAML), LDAP or Active Directory
5. Import agents (staff) and assign them to groups
6. Adjust overviews — set up ticket lists for your teams
7. Set up organizations — structure your customers
8. Postmaster filters — sort incoming email automatically and filter out noise
9. Create text modules — for fast, consistent replies
10. Triggers and automations — automate recurring workflows
11. Define SLAs — set response times
12. Set up AI features — enable summaries, the writing assistant and smart routing
13. Enable time tracking — record effort per ticket/customer
14. Build a knowledge base — answer common questions centrally
15. IT integration — connect other external systems

Quick start: productive in three steps

You don’t have to set everything up at once. Creating groups (1), connecting an email channel (2) and adding agents (5) are enough to start working on tickets productively right away. You can add everything else — automations, SLAs, AI — step by step as your support routine demands it.

The first step: define groups that determine which team is responsible for which tickets. Groups are the foundation for almost everything else in Zammad — every email channel is assigned to a group when you create it, and permissions, overviews and SLAs build on top of them. That’s why you create groups before you connect the email channel.

Under Admin → Groups:

Recommended group structure:

Assign the responsible staff members (agents) to each group. An agent can belong to several groups.

Keep groups small

Prefer a few clearly delineated groups over many small ones. Each group should correspond to a real team or area of responsibility. Too many groups lead to confusing assignment and tickets that get pushed back and forth between groups.

Every group needs a channel

For tickets to be created in a group, it needs at least one communication channel (e.g. an email address). Groups without a connected channel stay empty — only create them once you also have a channel for them.

Once your groups are in place, you connect your support email address to Zammad. Without an email channel, no tickets are created.

Under Admin → Channels → Email:

1. Add a “new email account”
2. Enter the email address (e.g. support@example.org)
3. Enter your IMAP credentials (server address, port, username, password)
4. Select the group that new tickets should land in (e.g. “Support”)
5. Save — from now on Zammad fetches all new emails and creates tickets

So that Zammad can send replies on behalf of your domain:

1. Enter your SMTP credentials (server address, port, username, password)
2. Configure the sender name and address
3. Send and receive a test email

Use a dedicated support address

Set up a dedicated email address for Zammad (e.g. support@example.org or tickets@example.org). Don’t use an employee’s personal mailbox. Forward customer requests that go to other addresses to this address by email forwarding. This makes sure every request is captured as a ticket.

You can connect several email addresses — e.g. support@, sales@ and accounting@. Each address can be assigned to a different group, so tickets automatically land with the right team.

Email signatures

Under Admin → Channels → Email → Signatures you can store a separate signature for each group. That way the support team replies with a different signature than sales.

Automatic provider detection

In many cases Zammad detects the IMAP and SMTP settings of your email provider based on the email address alone. Only if automatic detection fails do you have to enter the server, port and encryption manually. Keep your mailbox credentials to hand.

Roles define what a user is allowed to do in Zammad. Every user has one or more roles and inherits their permissions. Zammad ships with three default roles:

Under Admin → Roles you can adjust the default roles or create your own — e.g. a “Team lead” role with access to reporting but without full admin rights.

Review roles before importing agents

Sort out your roles and permissions before you create or invite agents. This makes sure every new staff member immediately gets the right access rights and that nobody can accidentally see too much or too little.

Organizations are at the heart of customer management in Zammad. Each organization represents a customer, a company or an institution. All tickets created by members of an organization are grouped together — so as an agent you don’t just see the individual request, but the entire communication history with that customer.

Under Admin → Organizations or directly from a ticket via the sidebar:

1. Enter a name (e.g. “Customer Inc.” or “Sports Club XY”)
2. Optional: notes, VIP status, domain
3. Assign members (associate existing contacts with the organization)

The “shared organization” option is one of the most powerful features in Zammad:

• Enabled: all members of this organization can see and work on their colleagues’ tickets. Ideal for B2B support, where the contact at the customer should know what their colleagues have already asked about.
• Disabled: each member only sees their own tickets. Suitable when members’ requests are independent of one another or confidentiality must be maintained.

When to enable shared organizations?

Enable shared organizations for corporate customers with a support quota or when the customer has a central contact person who should keep an overview of all their company’s requests. Disable it when requests are individual and confidential — e.g. for end customers or internal HR tickets.

If you enable the “domain-based assignment” option and enter a domain (e.g. customer-a.com), new contacts whose email address ends in @customer-a.com are automatically assigned to this organization. That saves considerable administrative effort, especially with larger customers with many contacts.

Set up domain assignment for all customers

Set up domain-based assignment for every corporate customer. Then, when a new employee of the customer emails your support for the first time, they are automatically assigned to the right organization — without you having to create them manually.

A contact can be assigned to a primary organization and additionally to secondary organizations. This is useful when, for example, a freelancer works for several companies or a consultant creates tickets for different customers.

The home screen shows your ticket overview. By default you see:

• My open tickets — tickets assigned to you personally
• All open tickets — all tickets in your groups
• Overview — a group-based total overview

In Zammad these lists are called overviews. Under Admin → Overviews you can adjust them and create your own — e.g. “Escalated tickets”, “Waiting for customer reply” or a list just for the “Sales” group. For each overview you define:

• Which roles it is visible to (mandatory — e.g. agents only)
• Filter conditions (group, status, priority, owner …)
• Displayed columns and sorting

Set up overviews per team

Give each team its own overview with the right filters and columns. A support agent wants to see “open tickets in my group sorted by priority”, while a team lead wants “all tickets about to miss their SLA deadline”. Well-designed overviews are the fastest lever for a tidy working day.

1. Click a ticket → see the complete communication history
2. Reply: reply directly in the ticket → the email automatically goes to the customer
3. Internal notes: add comments the customer can’t see (for internal coordination)
4. Assign: hand the ticket to a colleague or another group
5. Set the status:

• open — still being worked on
• pending reminder — waiting for a reply, should remind after X days
• pending close — closed automatically if the customer doesn’t reply
• closed — finally completed

Use internal notes generously

Internal notes help colleagues understand the context — e.g. “Informed customer by phone, waiting for a call back from Technical” or “Known bug, will be fixed in the next release”. Especially valuable when a ticket is handed to another person or group. With @@ you can mention colleagues directly in the note, and they receive a notification.

For frequently recurring replies you can create text modules — ready-made texts that are inserted into the reply with a single click.

Under Admin → Text Modules:

Examples of useful text modules:

Text modules are called up in the reply field with :: and the shortcut — e.g. ::ack inserts the acknowledgement.

Text modules per group

You can assign text modules to specific groups. That way the support team sees different modules than sales. This keeps the selection clear and prevents a support agent from accidentally using a sales text module.

Triggers are the automation tool in Zammad: if a condition is met, then perform an action. Triggers are checked on every ticket update and executed immediately.

Under Admin → Trigger:

Auto-reply for new tickets:

• Condition: ticket is created, channel = email
• Action: send email to customer: “Thank you for your message. We have received your request under ticket no. #{ticket.number}.”

Assign a ticket by keyword:

• Condition: ticket is created, subject contains “invoice”
• Action: set group to “Accounting”, priority to “high”

Automatically close no-reply tickets:

• Condition: sender address contains “no-reply@” or “noreply@”
• Action: set status to “closed”

Escalation notification:

• Condition: ticket has been open for more than 24 hours, status = “open”
• Action: send an internal notification to the group lead

Prioritise VIP customers:

• Condition: the customer’s organization has VIP status
• Action: set priority to “high”, add tag “VIP”

Trigger vs. automation

Triggers are executed immediately on every ticket change (event-based). Automations (under Admin → Scheduler) run on a schedule — e.g. “Every Friday, automatically close all tickets that have been in ‘pending close’ for 30 days”. Use triggers for immediate reactions and automations for regular clean-up work.

Macros bundle several ticket actions into a single click. Under Admin → Macros:

While triggers react to ticket events, postmaster filters kick in even earlier — directly on every incoming email, before it becomes a ticket. They’re the right tool to filter out spam, assign emails to the right group or prevent loops with automatic replies.

Under Admin → Channels → Email → Filters:

Filter out newsletters and automatic replies:

• Condition: header contains Precedence: bulk or the subject contains “Automatic reply”
• Action: set the tag “Auto-Reply” or close the ticket directly

Assign emails based on the recipient:

• Condition: the “to” address is invoice@example.org
• Action: set group to “Accounting”, priority to “high”

Block a known spam sender:

• Condition: the sender contains @spam-domain.example
• Action: ignore the email (no ticket is created)

Postmaster filters vs. triggers

Postmaster filters work at the email level, before a ticket exists — ideal for sorting, assigning and discarding incoming messages. Triggers work at the ticket level, after the ticket has been created. Use postmaster filters for the basic sorting of your inbox, and triggers for reactions to existing tickets (auto-reply, escalation).

SLAs (service level agreements) define binding time targets for processing tickets. Under Admin → SLAs:

1. Create a “new SLA”
2. Define the conditions — which tickets does this SLA apply to? (e.g. “all tickets in the Support group” or “all tickets with high priority”)
3. Configure the time targets:

• First response: within what time must the agent respond for the first time?
• Update time: how long may pass between two replies to the customer at most?
• Solution time: within what time must the ticket be solved?

4. Assign a calendar — SLA times only run during business hours

Under Admin → Calendars you set up your business hours. The calendar determines when SLA times run and when they don’t.

1. Define business hours per weekday (e.g. Mon–Fri 08:00–17:00)
2. Enter public holidays or select a country (Zammad knows the statutory holidays of many countries)
3. Assign the calendar to the SLA

Set up the calendar correctly

Without a correctly configured calendar, SLA times count at night and on weekends too — this skews your reporting and triggers unnecessary escalations. Make sure business hours and holidays are correct before you activate SLAs.

When a ticket is about to miss its SLA deadline, it is marked red in the overview — so you can see at a glance what’s urgent.

Time tracking helps you document the actual effort per ticket, customer or project. Especially valuable for freelancers and agencies that bill support by effort, or for SMBs that want to know how much capacity support ties up.

1. Navigate to Admin → Time Accounting
2. Switch time tracking on (toggle at the top left)
3. Configure the filter: which tickets should time tracking apply to? (e.g. all tickets, or only certain groups/customers)

When time tracking is enabled, a dialog appears on every ticket update prompting the agent to enter the time spent. The agent enters the value and the ticket is saved as usual.

Track time consistently

Time tracking is only as good as the data that’s entered. Agree on a convention within the team: is the actual processing time entered, or research time too? Should phone calls be recorded separately? A clear agreement ensures comparable reporting.

Under Admin → Time Accounting you’ll find reports by:

• Tickets — how much time was spent per ticket?
• Customers / organizations — how much support effort does a particular customer cause?
• Agents — how is the effort distributed across team members?

The data can be exported as CSV — ideal for further processing in a spreadsheet or for invoicing.

Use time tracking for billing

If you bill support by the hour, use the organization-based report: at the end of the month you export the CSV report, filter by customer organization and have a clean basis for invoicing. Combined with SLAs, you can also keep track of contractually agreed quotas.

The built-in knowledge base lets you document frequently asked questions, guides and internal processes centrally. Customers can find answers themselves and agents can link articles in tickets — this reduces recurring requests and speeds up processing.

1. Navigate to Admin → Knowledge Base
2. Enable the knowledge base
3. Configure the languages (e.g. German and English — articles can be translated per language; untranslated articles are automatically hidden in the respective language)
4. Optionally adjust the colours to match your corporate design
5. Under header menu and footer menu, configure the navigation to link the knowledge base with your website

The knowledge base is hierarchical: categories → subcategories → articles.

Example structure for an SMB:

📁 For customers (public)
   📁 Frequently asked questions
      📄 How do I reset my password?
      📄 How do I reach support?
      📄 What response times apply?
   📁 Guides
      📄 Getting started with our product
      📄 Installing the desktop app
📁 Internal (agents only)
   📁 Processes
      📄 Escalation process for critical tickets
      📄 Onboarding new support staff
   📁 Technical knowledge
      📄 Known bugs and workarounds
      📄 Error messages and solutions

Example structure for an association:

📁 For members (public)
   📁 Membership
      📄 How do I become a member?
      📄 How do I cancel my membership?
      📄 When is the membership fee due?
   📁 Events
      📄 Registering for events
      📄 Upcoming dates
📁 For the board (internal)
   📁 Association management
      📄 Running the general meeting
      📄 Preparing the treasurer's report

Each article can have one of three visibilities:

Link knowledge base articles in tickets

When an agent works on a ticket and a matching answer exists in the knowledge base, they can insert or link the article directly in the reply. This saves typing and ensures customers always receive the current, verified answer.

The knowledge base as a self-service portal

The public knowledge base is reachable via its own URL and can be linked from your website. Customers find answers there without having to create a ticket. This noticeably reduces ticket volume — especially for standard questions.

Maintain the knowledge base continuously

After every resolved series of tickets on a recurring topic, check whether a knowledge base article exists for it. If not, create one. That way the knowledge base grows organically with your real support experience.

Since Zammad 7.0, Zammad brings AI features directly into ticketing. Ticket summaries, a writing assistant and automatic routing through AI agents help your team work faster and more consistently — without needing an external tool for it.

All AI features are disabled by default and must be set up deliberately. You decide which features you use and which LLM provider processes your data.

Before you can use AI features, an LLM provider must be configured. Zammad supports the following providers:

At server.camp you additionally have an open-source LLM available, operated in a European data centre (France). You can configure the provider you want directly in the dashboard of your Zammad instance — contact our support if needed.

Data protection and GDPR

Zammad doesn’t force you to use a particular cloud service. As an administrator, you decide which provider is used and which data flows where. If you want to be on the safe side, use the open-source LLM available at server.camp or a local Ollama instance — that way your ticket data doesn’t leave the European area.

For long ticket histories with many messages, the AI can create a structured summary at the push of a button. The summary shows:

• What is the customer’s concern?
• What has already been done?
• Which questions or points are still open?

Optionally, you can add sentiment analysis (is the customer satisfied or frustrated?) and detection of open points.

Configuration: under Admin → AI you can set per group whether the summary is generated automatically when a ticket is opened or only on click. Individual analysis modules (summary, sentiment, open points) can be enabled individually.

Summaries for long tickets

Summaries are especially valuable when a ticket is handed to another person or group. Instead of reading the entire history with 30+ messages, a glance at the AI summary is enough to get up to speed immediately.

The writing assistant is available directly in the reply editor. When you select some text, a menu appears with the following functions:

• Improve writing — turn a rough draft into a professional reply
• Simplify text — phrase complex explanations more understandably
• Fix spelling and grammar — clean up typos and grammar
• Expand — extend a terse draft into a fully formulated, clearly structured text

Administrators can store custom prompts as additional functions — e.g. for translations into specific languages, adhering to a company tone or industry-specific wording standards.

Custom prompts for the writing assistant

Typical use cases for custom prompts: “Translate into English”, “Rewrite in a formal business tone” or “Explain technical terms for laypeople”. This ensures your team communicates consistently and in the right tone.

AI agents take on tasks that would otherwise have to be done manually:

• Routing (Ticket Group Dispatcher) — incoming tickets are assigned to the right group (e.g. technical requests to “Technical”, invoice questions to “Accounting”)
• Categorisation (Ticket Categorizer) — tickets are assigned to a category based on their content
• Tagging (Ticket Tagger) — matching tags are added automatically
• Prioritisation (Ticket Prioritizer) — the AI estimates the urgency and sets the priority accordingly
• Title generation (Ticket Title Rewriter) — unclear or missing subject lines are replaced with meaningful titles
• Information extraction (Text Extractor) — data such as order or serial numbers is read from the ticket and copied into fields

AI agents don’t run on their own; they are invoked deliberately as an action in a trigger, an automation (scheduler) or a macro. This way you decide exactly when and for which tickets an AI agent becomes active — e.g. the Group Dispatcher automatically on every new ticket via a trigger, or the Categorizer via a macro at the push of a button.

AI agents and triggers

AI agents and rule-based triggers complement each other. A pure trigger condition works with fixed rules (“subject contains invoice → group Accounting”); an AI agent understands the content of a message and correctly assigns even tickets that contain no obvious keyword. Since AI agents run as an action within a trigger (or an automation or macro), it’s best to combine both: a simple trigger condition decides when the agent runs, and the AI agent then handles the content-based classification.

Under Reporting you’ll find analyses:

• How many tickets were created and solved in a period?
• How long is the average processing time?
• Which channels generate the most tickets?
• How well does the team meet its SLA times?

This data helps you improve your support in a targeted way and add staff if needed.

Regular reporting

Look at the reports at least once a month. Pay particular attention to SLA compliance and the average first response time — these are the two metrics with the biggest influence on customer satisfaction.

Zammad supports SSO via OpenID Connect (OIDC) and SAML. If you use Authentik as your identity provider, your staff can log in to Zammad and all other connected apps with a single account.

Advantages:

• Agents don’t have to remember a separate Zammad password
• Onboarding: a new employee created in Authentik → immediately has access to Zammad
• Offboarding: an account disabled in Authentik → access to Zammad and all other apps is blocked immediately
• 2FA is controlled centrally via Authentik

OIDC or SAML? For new setups, OIDC

For a new connection to Authentik we recommend OpenID Connect. OIDC builds on OAuth 2.0, works with JSON instead of XML and is considerably easier to set up: in Authentik you create an OAuth2/OpenID provider as a public client with PKCE, and in Zammad you only enter the Identifier (client ID) and issuer URL — no exchange of XML metadata or signing certificates required.

SAML remains a good alternative if you need Single Logout (SLO) or already use an established SAML role mapping. Both methods support mapping name and email as well as automatic account linking on first login. OIDC is available as an SSO method in Zammad from version 6.5 onwards.

For a step-by-step walkthrough of setting up OpenID Connect with Authentik, see the Set up single sign-on (SSO) guide. If you need a hand, our support is available any time.

Zammad can synchronise users and groups from an existing LDAP or Active Directory directory. Under Admin → Integrations → LDAP there is a setup wizard.

What is synchronised:

• User accounts (name, email, department)
• Group/role memberships
• Login credentials (agents log in with their AD password)

LDAP with managed hosting

Since your Zammad instance is hosted at server.camp, your LDAP/AD server must be reachable from outside (e.g. via VPN or a fixed IP with firewall rules). Contact our support for help with the network setup.

Organizations and LDAP

LDAP synchronisation in Zammad currently does not support direct assignment of organizations. If you want to assign customer organizations automatically, use the domain-based assignment instead — this works independently of LDAP and assigns contacts based on their email domain.

Zammad supports TOTP-based 2FA (e.g. Google Authenticator, Aegis). Every agent can enable 2FA in their personal settings. If you use SSO via Authentik, we recommend configuring 2FA there centrally — that way it applies automatically to all connected apps.

Zammad has an extensive REST API with which you can manage tickets, users and organizations programmatically. Via webhooks (Admin → Webhooks), Zammad can notify external systems on certain ticket events.

Typical integrations:

Zammad + Mattermost

If you use Mattermost, you can automatically send a message to a Mattermost channel via webhook on new or escalated tickets. That way the team notices immediately when something urgent comes in — even without keeping Zammad open all the time.

Customers can log in to the Zammad customer portal and:

• Create their own tickets and track their status
• Search the knowledge base
• With shared organizations: see their colleagues’ tickets

Under Admin → Channels → Chat you can configure a chat widget that is embedded on your website. Incoming chat messages land as a ticket in Zammad.

After a phone call, the agent can manually create a ticket and add the call notes. That way phone support is documented seamlessly too.

Under Admin → Channels → Form you can generate a contact form that is embedded on your website. Incoming forms automatically create tickets.

Alongside the practical tips, there are some technical ground rules that Zammad itself recommends to keep performance and clarity healthy in the long run (Zammad: 4 configuration traps). They cost little time during setup, but save you a lot of clean-up later.

Always grant permissions via roles, not individually per user. If you mix the two approaches, you quickly end up with a confusing tangle where nobody knows any more why an agent sees a particular ticket (or doesn’t). Roles scale, can be documented and can be revoked cleanly during offboarding.

Before you create a scheduled automation (scheduler), check whether a postmaster filter or a trigger can do the same job. Scheduled jobs check their conditions every minute across all tickets — many of them add up to noticeable system load. Zammad’s rule of thumb: less is more.

Overviews are task lists, not a ticket database. Every active overview is continuously recalculated — too many of them (Zammad names 25+ as critical) burden the server and cause agents to lose focus. Only create overviews a team really needs every day, and remove unused ones consistently.

Anyone following too many tickets as an observer drowns in notifications and misses what’s important. Agree within the team to subscribe only to relevant tickets, and clean up subscriptions regularly (since Zammad 6.4 also as a bulk action via a macro).

Name SLAs, triggers, macros and overviews so it’s clear at a glance what they do and whom they affect (e.g. “SLA – VIP customers first response 1h” instead of “SLA 1”). This pays off at the latest when a colleague takes over or extends the configuration.

Keep an eye on escalated tickets

As soon as you use SLAs, the built-in “Escalated tickets” overview is worth using — it shows tickets that have already escalated and are about to escalate. Sort your most important overviews by escalation time instead of creation date, so urgent cases are always at the top.

• Use one group (“Support”) and text modules for fast replies
• Enable time tracking to keep track of and bill support effort per customer
• Set up SLAs to keep an eye on your own response times
• Build a public knowledge base so customers can clarify standard questions themselves
• Use organizations to see tickets grouped by customer
• Enable the AI writing assistant to phrase replies faster and more professionally

• Structure groups by team (support, sales, technical)
• Use shared organizations for B2B customers with several contacts
• Set up domain-based assignment so new customer contacts are automatically assigned to the right organization
• Use triggers for automatic assignment, escalation and VIP prioritisation
• Define SLAs with realistic time targets and a correct calendar
• Integrate Zammad into your existing IT via SSO (Authentik) or LDAP
• Use webhooks to Mattermost for real-time notifications
• Analyse reporting and time tracking monthly to improve support continuously
• Enable AI agents for automatic routing and prioritisation — especially with high ticket volume
• Use ticket summaries so agents immediately have the context on ticket handovers

• Use Zammad as a central mailbox for association requests (info@myassociation.org)
• Create groups like “Board”, “Events”, “Membership”
• Build a public knowledge base with FAQs on membership, fees and events
• Use text modules for recurring requests such as joining or cancellation enquiries
• Enable the customer portal so members can track the status of their requests themselves
• Use the web form as a contact form on the association’s website

If you need help setting up the email channel, SLAs, AI features, automations or the SSO connection, you can reach us any time at support@server.camp. We’re happy to help!

You can also find frequently asked questions about Zammad on our Zammad product page.