Customer Service & Helpdesk
Zammad
EU-Made Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 2 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Zammad GmbH · zammad.com
Compare with Freshdesk → Compare with OTRS → Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Zammad is a German, open-source helpdesk offered cloud or self-hosted, and its ticketing, queues & SLA sits at a flat 6: states, assignment, escalations, SLAs, macros, templates and automation rules are named, but no rationale evidences search across ticket bodies, business-hours-aware SLA policies, merge/split or per-agent reporting. Strongest are omnichannel and pricing transparency: email, web form, SMS, chat, Telegram, Facebook and WhatsApp are priced per tier into a unified ticket view, and €7/€16/€25 per agent per month plus a metered €0.03 per AI call are public with VAT treatment stated — though telephony is advertised yet appears in no tier's channel list and carries no price. Weakest are integrations (flat 4; only GitHub/GitLab and Grafana/Elasticsearch named), knowledge base & deflection (4–5; deflection claimed, never instrumented) and customer data protection (3–4; no tenant DPA, retention period or audit log evidenced). Spreads stay within one point — on sovereignty, higher scores credit the self-hosted option while lower ones flag the unnamed data-centre provider and missing product subprocessor list — and no disagreement passed the computed threshold. Persona-weighted totals span 5.3 to 5.6.
Speaks for it
- Per-agent prices for all three tiers are public (Starter v2 €7, Professional v2 €16, Plus v2 €25 per agent / month), with agent caps, storage limits, VAT treatment and the €0.03-per-AI-call meter stated
- Email, web form, SMS, chat, Telegram, Facebook and WhatsApp are placed as channels per tier, promised in one unified ticket view with history
- A self-hosted deployment option exists, letting buyers keep the ticket archive on their own infrastructure
- The contracting entity is a German GmbH with a published commercial register number (Charlottenburg HRB 163946 B), hosting marked 'Made & hosted in Germany' in an ISO27001-certified data centre
- Automation is named in depth — automation rules, macros, text modules, templates and bulk actions — beyond a routing-and-status floor
Held against it
- The only named non-channel integrations are GitHub/GitLab and Grafana/Elasticsearch, with no CRM, shop, SSO, webhooks or documented rate limits evidenced
- No tenant DPA, stated retention period for ticket data or audit log of ticket access is evidenced anywhere on the evidence
- The privacy policy's GDPR rights and auto-delete text govern Zammad's own website inquiries, not a customer's ticket archive
- Nothing evidences search across ticket bodies, business-hours-aware SLA policies, merge/split or per-agent response reporting
- Telephony is advertised as a channel but appears in no tier's channel list and carries no price, and no minimum term or billing period is stated
Best for
- You need a per-agent-priced helpdesk whose invoice you can nearly compute from the public pricing pages alone
- You want email, chat and messengers consolidated into one ticket history per customer
- You want to self-host the ticket archive, or contract with a German GmbH hosting in Germany in an ISO27001-certified data centre
Avoid if
- You need CRM, shop or order-management connectors so agents see customer order data inside the ticket
- You must verify a tenant DPA, ticket retention period and access audit log before signing
- You rely on telephony support, which is advertised but absent from every priced tier's channel list
- You need deflection reporting, article suggestions or editorial workflow from your knowledge base
The scores
Ticketing, queues & SLA
Show reasoningHide reasoning
How this is scored
The engine: how work is routed, prioritised, escalated and measured — and whether an agent can find the ticket they need among ten thousand.
0 — A shared mailbox with labels; no ownership, no status model, no history beyond the thread.
3 — Tickets with assignment and open/closed status, but routing is manual, there are no SLA timers and search covers subject lines only.
5 — Queues with rules-based routing, priorities, a working status model, SLA timers with breach warnings, and full-text search across ticket bodies.
8 — Business-hours-aware SLA policies per queue or customer, escalation chains, macros and triggers, merge and split, and reporting on first-response and resolution time by agent and queue.
10 — The workload is managed rather than merely tracked: capacity-aware assignment, SLA per contract with reporting an account manager could show a customer, audit of every status change, and search that finds the ticket from a half-remembered phrase.
The Support Lead
The bones are evidenced — "States · Assignment · Escalations", SLAs, macros, automation rules, overviews and reporting — and escalations plus SLAs are what I need against a promised SLA. But nothing shows breach warnings, business-hours-aware SLA policies, per-agent resolution reporting, merge/split or even that search exists; and SLAs only enter at Professional v2, so Starter buyers track work they can't measure. 2 3
The Agent Advocate
States, assignment, escalations, macros, templates, automation rules and SLAs with reporting are all on the page — but SLAs only start at Professional, and nowhere does the evidence say one word about search across ticket bodies, which is the first thing I judge. No merge/split, no business-hours policies, no per-agent resolution reporting either. 2 3
The Data Protection Officer
States, assignment, escalations, macros, templates, automation rules, SLAs and reporting are all evidenced, which clears the mid anchor. But nothing on business-hours-aware SLA policies, escalation chains, merge/split, or full-text search across ticket bodies, so it stays below the 8. 2 3
The Shop Operator
States, assignment, escalations, SLAs, macros, automation rules and reporting are all named, which is a genuine engine above the routing-and-status floor. But the evidence is silent on search entirely — I need to find one parcel ticket in ten thousand — and business-hours SLA policies, escalation chains, merge/split and per-agent response reporting are nowhere evidenced. 2 3
The Integrator
States, assignment, escalations, macros, automation rules and SLAs are all named, which is the substance of rubric level 5 — but nothing evidences search across ticket bodies, priorities, business-hours SLA policies, merge/split, or what the 'Reporting' actually measures. In a ten-thousand-ticket queue I need to know an agent can find the ticket, and the evidence is silent on that. 2 3
The Skeptic
States, assignment, escalations, SLAs, macros, templates and automation rules are all named, and I can read exactly which tier SLAs start at — Professional v2. But nothing evidences business-hours-aware SLA policies, merge/split, first-response reporting by agent and queue, or full-text search across ticket bodies — the bullets are marketing nouns, so I stop just past the anchor-5 line. 2 3
Channels in one queue
Show reasoningHide reasoning
How this is scored
Email, chat, phone, portal, messengers and social — judged on what actually lands in the same queue with the same history, not on how many channel logos the marketing page carries.
0 — Email only.
3 — Email plus one more channel, but the second lives in its own inbox: no shared history, and a customer who switches channel starts again.
5 — Email, a web form or portal and live chat all landing as tickets in one queue, with the customer's history visible whichever channel they used.
8 — The above plus telephony integration with call logging, at least one messenger (WhatsApp, Signal or similar) with its consent handling stated, and a customer portal where a requester can see their own tickets.
10 — Channel is an implementation detail: every channel including voice and messengers writes to one conversation with one history, agents answer from one screen, and the customer can move between channels mid-issue without repeating themselves.
The Support Lead
Email, web form, chat, Telegram, WhatsApp and Facebook are all placed as priced channels and the unified ticket view with customer profile suggests one history per customer. Missing: no evidence of call logging for the claimed telephony integration, no messenger consent handling, no requester-visible portal — and chat and WhatsApp are tier-gated, so "one queue" depends on which invoice you sign. 2 3
The Agent Advocate
Email, web form, SMS, chat, Telegram, Facebook and WhatsApp are listed per tier plus a telephony integration, and the evidence promises all communication in one structured ticket view with history — that's genuinely one queue. Docked because call logging, messenger consent handling and a requester-visible portal for their own tickets are all unevidenced, and chat/Telegram only start at Professional while messengers wait for Plus. 2 3
The Data Protection Officer
Email, web form, chat, SMS, Telegram, WhatsApp and Facebook all land in one structured ticket view with shared history, plus telephony integration. Deducted because messenger consent handling is not stated, there is no evidenced customer portal where a requester sees their own tickets, and call logging is a bare phrase. 2 3
The Shop Operator
Chat, Telegram, Facebook and WhatsApp land as channels alongside email and web form, with a unified ticket view claimed — WhatsApp and the shop form in one queue is evidenced, not marketing. Docked below 8 because telephony is only a bare 'integration' with no call logging, messenger consent handling is unstated, and no requester-facing portal with own tickets appears anywhere. 2 3
The Integrator
Email, web form, chat, Telegram, Facebook, WhatsApp and telephony are all named, and 'all communication... in one structured ticket view' supports one history — but messenger consent handling is never stated, and there is no evidence of a portal where a requester sees their own tickets, only a help centre. That keeps it under the anchor-8 bar. 2 3
The Skeptic
Seven channels are named per tier — Email, Web Form, SMS, Chat, Telegram, Facebook, WhatsApp — plus 'Telephony integration', and the 'unified structured ticket view with history' claims one history. My follow-ups go unanswered: no evidence of call logging behind the telephony bullet, no consent handling stated for WhatsApp, and no requester portal where a customer sees their own tickets — the help centre is a knowledge base, not a ticket portal. 2 3
Knowledge base & deflection
Show reasoningHide reasoning
How this is scored
Whether the product reduces the number of tickets as well as organising them: public help centre, article workflow, suggestions to agents and to customers.
0 — No knowledge base; answers live in agents' heads and old tickets.
3 — A basic article list, public or internal, with no editorial workflow, no versioning and no link between articles and tickets.
5 — A searchable public help centre with categories, draft and publish states, and agents able to insert an article into a reply.
8 — Article suggestions to the customer before they submit and to the agent while they answer, multilingual articles, review dates that flag stale content, and reporting on which articles deflect.
10 — Knowledge is a managed asset: gaps identified from unanswered tickets, article performance measured against ticket volume by topic, versioned content with approval, and deflection reported as a number the team can act on.
The Support Lead
A help centre and knowledge base exist with the deflection promise spelled out ("without opening a ticket") and multilingual articles from Plus upward. No editorial workflow, draft/publish, article insert into replies, review dates or deflection reporting appears anywhere in the evidence — knowledge is a shelf, not a managed asset. 2 3
The Agent Advocate
A help centre and a knowledge base — multilingual from Plus upward — positioned explicitly for customers solving issues 'without opening a ticket'. But there's no evidence of article suggestions before submission or while answering, no review dates, no versioning, and no deflection reporting: deflection here is a claim, not a number the team can act on. 2 3
The Data Protection Officer
A help centre and a knowledge base exist, multilingual on the Plus tier, with the stated aim of customers solving issues without a ticket. No editorial workflow, no versioning, no suggestions to agent or customer, and no deflection reporting are evidenced, so this sits between the basic article list and the working public help centre. 2 3
The Shop Operator
A help centre explicitly positioned at 'without opening a ticket' plus a multilingual KB in the Plus tier shows deflection intent, above a bare article list. But no editorial workflow, no article suggestions to agent or customer, no review dates, and no deflection reporting — I couldn't tell you whether December's ticket count fell. 2 3
The Integrator
A public help centre with an explicit deflection claim and a multilingual knowledge base (Plus tier) clears rubric level 5. Nothing evidences editorial workflow, versioning, inserting articles into replies, suggestions to agents or customers, review dates, or deflection reporting — so I cannot credit the 8-anchor features beyond multilinguality. 2 3
The Skeptic
A help centre and knowledge base exist, multilingual from the Plus tier. Deflection is asserted — 'without opening a ticket' — but never instrumented: no draft/publish workflow, no article-insert into a reply, no suggestions before submission, and no reporting on which articles deflect. That's a basic article list with a language setting, a step above rubric level 3 and clearly short of rubric level 5. 2 3
Customer data protection
Show reasoningHide reasoning
How this is scored
A ticket archive is personal data written by the data subject. Retention, deletion, access control, subject rights, and what the vendor does with attachments — judged on what executes rather than what is promised.
0 — No retention policy stated, no deletion path, agents all see everything, and no DPA is published.
3 — A DPA on request and coarse roles; deletion is described as something the customer arranges, and there is no stated retention period.
5 — A signable DPA published, configurable agent roles and queue-level visibility, a stated retention period, and deletion of a requester's data that can actually be executed.
8 — Automatic retention rules per queue or data category, attachment handling stated, an audit log of who opened which ticket, documented support for access and erasure requests, and pseudonymisation or redaction of ticket content.
10 — Built for a data-protection audit: retention executed and evidenced per category, field-level redaction, full audit trail, subprocessor list published, and the vendor's own support access to customer instances documented and consent-gated.
The Support Lead
Configurable roles and permissions, transport encryption, 2FA, device management, an ISO27001 German data centre, and a self-hosted route that removes vendor access altogether are all evidenced. But there is no published DPA, no stated retention period for tenant ticket data, and no evidenced in-product erasure execution — the GDPR rights list and auto-delete text in the privacy policy govern Zammad's own website inquiries, not my instance. 2 3 5
The Agent Advocate
GDPR rights including deletion and portability are published, individual roles and permissions exist, and the archive sits in an ISO27001-certified German data centre with 2FA and SSL — but that's vendor posture plus coarse roles. No published DPA, no stated retention period for the ticket archive, no audit log of who opened which ticket, and nothing on attachment handling or redaction. 2 3 5
The Data Protection Officer
GDPR rights including deletion are listed and configurable roles/permissions and 2FA exist — but the deletion clause is the vendor's own website-inquiry auto-delete, not a path for a customer's ticket archive. No published DPA, no stated retention period for ticket data, no audit log of who opened which ticket, no redaction, no attachment-handling policy, and total silence on whether Zammad support can open a hosted instance's tickets. 2 3 5
The Shop Operator
Individual roles and permissions, 2FA and an ISO27001 data centre give real access control, but no published DPA, no ticket retention period, no audit log and no product-level deletion path are evidenced — the GDPR-rights facts describe Zammad's own website inquiries, not the customer archive. Deletion is left entirely to the customer to arrange. 2 3 5
The Integrator
The privacy policy lists full GDPR rights including deletion and granular roles are a feature, but that policy governs Zammad's own website — the evidence evidences no tenant DPA, no stated retention period for ticket archives, no audit log of ticket access, and no attachment handling. Roles plus documented rights sit just above the anchor-3 floor; nothing here executes. 2 3 5
The Skeptic
The GDPR rights list and auto-deletion in cover Zammad's own website inquiries, not the customer's ticket archive — that policy was last changed in 2020. Product-side I have 'Permissions' and individual roles at Professional, 2FA and an ISO27001 data centre, but no published DPA, no stated retention period for tickets, no audit log of who opened which ticket, and nothing on attachment handling or redaction. 2 3 5
Integrations & API
Show reasoningHide reasoning
How this is scored
The systems a helpdesk has to reach — CRM, shop, order management, identity — and whether the API is documented for building or gated behind a partner conversation.
0 — No API and no named integrations; context is copied in by hand.
3 — A handful of native integrations and a read-mostly API, with no webhooks and no documented rate limits.
5 — Named integrations for common CRM and shop systems, a documented REST API with keys, webhooks for the core ticket events, and SSO.
8 — Maintained bidirectional integrations, customer context from other systems shown inside the ticket, SCIM provisioning, documented rate limits and a sandbox.
10 — A component rather than a destination: versioned API with a deprecation policy, event streaming both directions, an app framework for in-ticket extensions, and integrations the vendor maintains rather than lists.
The Support Lead
"Open APIs and ready-to-use integrations" plus named GitHub/GitLab and Grafana/Elasticsearch connections are the entire evidence base. No CRM or shop system is named, and webhooks, SSO, rate limits, SCIM and any sandbox are silent — an API I can't confirm past the marketing claim is an API I can't plan a build on. 1 2 3
The Agent Advocate
Open APIs and 'ready-to-use integrations', but the only names on the evidence are GitHub/GitLab and Grafana/Elasticsearch — no CRM, no shop, no order management, no webhooks, SSO, SCIM or documented rate limits anywhere. Being open source with the code freely available softens the blow since I could build it myself, but inspectable is not documented. 1 2 3 5
The Data Protection Officer
Open APIs and ready-to-use integrations are claimed, with named GitHub/GitLab and Grafana/Elasticsearch integrations. But no CRM, shop or identity integration is named, and there is no evidence of webhooks, SSO, rate limits, bidirectional sync or a sandbox — a read-mostly API with a few connectors. 1 2 3
The Shop Operator
'Open APIs and ready-to-use integrations' plus GitHub/GitLab and Grafana/Elasticsearch is a handful of named hooks, but nothing a shop runs on. No CRM, shop or order-management connector, no webhooks, no SSO, and nothing evidenced that puts the customer's order in front of the agent without a second login — my core requirement. 1 2
The Integrator
'Open APIs and ready-to-use integrations' is a homepage bullet with no docs, and the named integrations are GitHub/GitLab and Grafana/Elasticsearch — developer tools, not one CRM, shop or identity system. My whole checklist — documented rate limits, webhooks that retry, SCIM, a sandbox, SSO — appears nowhere, which is the read-mostly rubric level 3 plus a sync claim I can't verify. 1 2 3
The Skeptic
'Open APIs and ready-to-use integrations' plus exactly two named non-channel integrations — GitHub/GitLab and Grafana/Elasticsearch. That's a handful of natives and an API asserted in marketing language: no webhooks, no documented rate limits, no SSO, and no CRM or shop system named anywhere on the evidence. 1 2 3
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where the ticket archive lives, who the contracting entity is, which subprocessors touch it, and whether vendor support can read customer data. Independently sourced by the sovereignty pipeline; scored here as this buyer weighs it.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — support tooling, analytics, AI features — are non-EU without an explained safeguard.
8 — EU or DACH hosting with a named data-centre provider, EU contracting entity, full subprocessor list published, and any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor in the EU, certification published, and a self-hosted or private-cloud option for buyers who need the archive on their own infrastructure.
The Support Lead
The contracting entity is a German GmbH with a Charlottenburg commercial register number, hosting is German on an ISO27001-certified data centre, and self-hosting exists for keeping the archive on our own infrastructure. But the data-centre provider is unnamed, there is no subprocessor list for the product itself (Matomo and Moosend cover only their website), and the pipeline marks residency and subprocessor exposure as unconfirmed — so I can't give the transparency an anchor-8 buyer would audit. 2 3 4 5
The Agent Advocate
Zammad GmbH at Marienstraße 18 Berlin, commercial register Charlottenburg HRB 163946 B, made and hosted in Germany in an ISO27001 data centre, with a self-hosted option for buyers who want the archive on their own iron — that's a chain I could defend to a customer. It falls short of 8 because no data-centre provider is named and there's no published subprocessor list for the product itself; the only subprocessors disclosed are website analytics (Matomo, Moosend), not the service chain. 2 3 4 5
The Data Protection Officer
German contracting entity (Zammad GmbH, Berlin, commercial register Charlottenburg), German ISO27001 data centre, and crucially a self-hosted option that puts the archive on the buyer's own infrastructure. The data-centre provider is unnamed and no subprocessor list exists for the product chain — the only named subprocessors, Matomo and Moosend, serve the vendor's website. 2 3 4 5
The Shop Operator
German GmbH with a commercial register number, made and hosted in Germany, ISO27001-certified data centre, and open source with a self-host option — I can keep the archive on my own infrastructure. It stops short of the higher anchor because the data-centre provider is unnamed and no subprocessor list for the hosted product is published (the named Matomo/Moosend are the vendor's website tools). 2 3 4 5
The Integrator
Zammad GmbH in Berlin is the contracting entity, hosting is 'Made & hosted in Germany' in an ISO27001-certified German data centre, and a self-hosted option exists — rubric level 5 met, with self-hosting pulling above it. But the data-centre provider is unnamed, the pipeline itself marks residency and subprocessor exposure unknown, and the only listed subprocessors (Matomo, Moosend) are website tools, not the product chain. 2 3 4
The Skeptic
The contracting entity is nailed down — Zammad GmbH, Marienstraße 18 Berlin, HRB 163946 B — with 'Made & hosted in Germany' and an ISO27001-certified German data centre, plus a genuine self-hosted option. But the data-centre provider is unnamed, the only published subprocessors are the website's Matomo and Moosend Ltd rather than the product chain's, and the metered AI feature never states who processes it or where — so rubric level 8's named-provider and full-subprocessor-list bar isn't met. 2 3 4 5
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a support lead can compute the real annual invoice for their agent count — including the channels and features they actually need — from public pages alone.
0 — No public prices at all; every tier is a sales conversation.
3 — A per-agent headline exists, but the tier where the needed channel or SLA feature begins is unstated, or light-agent and contact limits are not mentioned.
5 — Per-agent prices public for the main tiers with billing period stated, but at least one commonly needed capability (telephony, messengers, SLA policies) sits in an unpriced bundle.
8 — Every tier and add-on priced publicly with per-agent maths, billing period, minimum term and VAT treatment stated; only genuinely custom enterprise work lacks a number.
10 — Complete price computability: a calculator or table producing the annual invoice for a given agent count and channel selection, including usage-metered channels and overage.
The Support Lead
I can compute the tiered invoice from public pages alone: per-agent prices, agent caps, channel placement per tier (WhatsApp in Plus, SLAs in Professional), VAT explicitly excluded, and even the AI meter at €0.03 per call. What keeps it off rubric level 8: telephony is claimed on the product page yet appears in no priced tier, and billing commitment and minimum term are unstated. 2 3
The Agent Advocate
I can compute the invoice from public pages: €7/€16/€25 per agent per month, agent caps of 5/35/unlimited, channels mapped to tiers, storage and attachment limits, support hours, even the metered AI fee of €0.03 per call, with VAT treatment stated. What keeps it under 8 is that billing period detail and minimum term aren't stated, and a 50-agent team needing WhatsApp is silently forced to the top tier by the cap alone. 2
The Data Protection Officer
All three tiers carry public per-agent prices with agent limits, channels, storage, support hours, VAT treatment and a metered AI fee of €0.03 per call — nearly computable. Billing period and minimum term are unstated, and telephony appears on the product page but in no tier's channel list, so its price position is a guess. 2 3
The Shop Operator
Per-agent prices for all three tiers with agent caps, storage limits, VAT treatment and even usage-metered AI at €0.03 per call are public, and WhatsApp clearly starts at Plus — I can nearly compute my invoice. Docked for no stated minimum term and for telephony, which is advertised as a channel but appears in no plan's channel list and carries no price. 2 3
The Integrator
Three tiers with per-agent prices, explicit channel lists, agent caps, storage limits, VAT treatment and even a metered AI price of €0.03/call are public — most of an annual invoice is computable. But telephony is a channel on the product page that appears in no tier's channel list and carries no number, and no minimum term is stated. 2 3
The Skeptic
Three tiers priced per agent with agent limits, VAT treatment, storage caps and even the AI meter at €0.03 per call are all public — unusually honest on the AI. But there's no billing period or annual option, no minimum term, no light-agent pricing, and the usage-metered channels (SMS from Starter upward, telephony) carry no price at all, so I can't compute the invoice for a chat-plus-SMS team. 2
European sovereignty — proven facts
2 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Incorporated in DE | 3/3 pts | 4 Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | EU only ⚠ unverified | 3/3 pts | 2 Report an error |
| Subprocessors | Not determined ⚠ unverified | — | uncited Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 15 Sep 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Data residency. The hosting location is asserted in pricing and marketing copy only, with no named hosting provider or data processing agreement excerpt to independently confirm it.
- Weak sourcing — Subprocessors. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 31 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 17 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 subprocessors facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 data facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 sovereignty dimension could not be confirmed on the vendor’s own pages and is shown as unknown. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (13)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage zammad.com Checked 15 Sep 2026 Details →
- 2 Pricing zammad.com Checked 15 Sep 2026 Details →
- 3 Product overview zammad.com Checked 15 Sep 2026 Details →
- 4 Imprint zammad.com Checked 15 Sep 2026 Details →
- 5 Privacy policy zammad.com Checked 15 Sep 2026 Details →
- 6 Security / trust page zammad.com Checked 30 Sep 2026 Details →
- 7 Ticketing, queues & SLA — found from sitemap zammad.com Checked 1 Oct 2026 Details →
- 8 Channels in one queue — found from sitemap zammad.com Checked 1 Oct 2026 Details →
- 9 Channels in one queue — found from sitemap zammad.com Checked 1 Oct 2026 Details →
- 10 Knowledge base & deflection — found from sitemap zammad.com Checked 1 Oct 2026 Details →
- 11 Customer data protection — found from sitemap zammad.com Checked 1 Oct 2026 Details →
- 12 Integrations & API — found from sitemap zammad.com Checked 1 Oct 2026 Details →
- 13 Integrations & API — found from sitemap zammad.com Checked 1 Oct 2026 Details →