Customer Service & Helpdesk
Znuny
EU-Made Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Znuny GmbH · www.znuny.org
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
Znuny is a customer service and helpdesk product, a community fork of the OTRS Community Edition shipped as a free download you host yourself, and the bench's scoring is sharply two-sided. It is strongest on ticketing core, where scores sit at a flat 4 across the bench: queues are permission objects grouped by department, service, product or country, tickets move or split between teams, and seven basic permissions run from read-only to full access. Sovereignty scores run 4–5 on a fully evidenced German contracting entity (Znuny GmbH, Berlin, Charlottenburg register HRB 139852 B, VAT DE281642846), though ownership, data residency and subprocessor exposure are recorded as unknown. Weakest are knowledge self-service, 0 across the bench, and integrations, 0–2, where the only machine surfaces shown are mail collection and X-OTRS headers; omnichannel sits at 3–4, email plus agent-logged phone screens. The judges genuinely split on customer data protection, 2–4: granular permissions weighed against no public information on retention, deletion, an audit log or a DPA. Pricing transparency spread 5–8; the software is free, professional services unpriced.
Speaks for it
- Ticketing core scored a flat 4, with queues as permission objects and tickets moved or split between teams
- Seven basic permissions per queue, from read-only to full access, let agent visibility be scoped queue by queue
- The software is a free download ("Free as free can be") you can host on your own infrastructure
- The German contracting entity is fully evidenced: Znuny GmbH, Berlin, Charlottenburg register HRB 139852 B, VAT DE281642846
- Mail collection supports any number of accounts over IMAP, POP3 and MSGraph variants with password or OAuth2 authentication
Held against it
- Knowledge self-service scored 0, with no public information on a knowledge base, help centre or deflection reporting
- Integrations scored 0–2, with no public information on a documented API, webhooks, CRM or shop connectors, SSO or SCIM
- No public information on SLA timers, breach warnings, escalation chains, macros or full-text search across ticket bodies
- No public information on retention periods, deletion of a requester's data, an audit log of ticket access, or a data processing agreement
- Only email and agent-logged phone screens are evidenced as channels, with no public information on chat, a customer portal, messengers or telephony integration
Best for
- You need a self-hosted, email-centric ticketing system where the ticket archive sits on infrastructure you control, under a German contracting party
- Your teams are organised by department, service, product or country and need granular per-queue permissions from read-only to full access
- You are a former ((OTRS)) Community Edition (6.0.x) user wanting continued bugfixes and security fixes under long-term support
Avoid if
- You rely on chat, a customer portal or messengers; the channels evidenced are email collection plus agent-logged phone screens
- Your agents need CRM or order context in the ticket without a second login; integration scores ran 0–2 and the only machine interfaces shown are inbound mail and X-OTRS headers
- You need self-service content to reduce ticket volume; the captured documentation covers queues and mail collection, and knowledge self-service scored 0
- You operate under a contractual SLA; the routing shown stops at dispatching mail to a selected queue or by the To: field, with no public information on timers or escalation chains
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
Queues are permission-based grouping objects with ticket ownership, priority changes, and close and pending screens, and inbound mail dispatches automatically to a queue or by recipient line, with moving and splitting between teams. But the captured documentation shows nothing on SLA timers, breach warnings, escalation chains, macros, or search — I found no public information on any of those, and for a team on a contractual SLA that is the whole ballgame. 3 4 5
The Agent Advocate
Real queue machinery: queues are permission objects you can group by department, service or country, tickets carry ownership and priority, teams hand off by moving or splitting tickets, and the queue view drills down through My Queues. Mail is dispatched by queue or recipient field, which is routing of a sort. But I found no public information on SLA timers, escalation chains, macros or full-text search across ticket bodies — the parts that decide whether ticket ten thousand gets found. 3 4 5
The Data Protection Officer
Queues are documented as permission objects with grouping by department, service, product or country, moving and splitting for inter-team hand-off, and personal My Queues views with drill-down filtering; ownership, priority, and pending and close permissions imply a working status model. We found no public information on SLA timers, breach warnings, escalation chains, reporting on first-response and resolution time, or full-text search across ticket bodies. 3 4 5
The Shop Operator
The queue concept is real: queues are permission objects grouped by department, service or country, tickets move or split between teams, and ownership, priority, pending and close are all permissioned screens, with mail dispatched by selected queue or by recipient. But we found no public information on SLA timers, breach warnings, escalation chains, or a search that finds a ticket from a half-remembered phrase — at December volume that search is what I live in. 3 4 5
The Integrator
Queues are documented as permission objects with ticket ownership, priorities, pending and close states, and moving or splitting tickets between teams — a real status model, not a shared mailbox. Mail is dispatched to queues either by a fixed selection or by the To: field, and I found no public information on SLA timers with breach warnings, escalation chains, macros and triggers, or full-text search across ticket bodies. Split and move are there; everything my SLA reporting would need is invisible to me. 3 4 5
The Skeptic
The queue model is real: queues grouped by department, service, product or country, tickets moved or split between them, and ownership, priority and move as explicit permissions with close, pending and bounce screens. But I found no public information on SLA timers, escalation chains, or what search actually covers, and the routing evidence stops at dispatching all mail to one queue or by recipient field. 3 4 5
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
What is documented to land in one queue is email — any number of mailboxes across IMAP, POP3 and Microsoft Graph, with OAuth2 — plus a phone screen where an agent records a call into the ticket system. We found no public information on live chat, a customer portal, messengers, social channels, or telephony with call logging, so the multi-channel pitch rests on manual phone entry. 4 5
The Agent Advocate
The email side is documented in depth — IMAP and POP3 variants, Microsoft Graph, OAuth2 tokens, any number of mailboxes with folder-level selection — and a phone permission puts phone-call screens into the same queues, so a call is a ticket rather than a separate inbox. Beyond that I found no public information on chat, a customer portal, messengers or social, so the customer has no second way in that these pages show. 4 5
The Data Protection Officer
Mail collection is documented in depth — any number of accounts over IMAP, POP3 and Microsoft Graph with OAuth2, folder selection and per-account fetch — and a phone-screen permission lets agents record calls as tickets, so this is email plus agent-logged calls. We found no public information on live chat, a customer portal, messengers or telephony integration landing in one queue. 4 5
The Shop Operator
Email is well covered — any number of mailboxes over IMAP, POP3 and MSGraph feeding the queues, with password or OAuth2 authentication — and a "phone screens" permission hints at phone tickets. We found no public information on live chat, a customer portal, WhatsApp or any messenger, on telephony integration with call logging, or on whether a customer switching channel keeps one history. For a shop that starts on WhatsApp, this reads as email with a phone screen. 4 5
The Integrator
Everything captured on channels is mail collection: any number of mailboxes over the standard IMAP and POP3 variants plus MSGraph, with OAuth2 tokens, folder selection and scheduled fetches. A permission granting access to phone screens hints that agent-logged calls become tickets, though I found no public information on chat, a customer portal, messengers or social channels landing in the same queue with a shared history. 4 5
The Skeptic
The channel evidence is one mail-collection page: any number of mailboxes over IMAP, POP3 and MSGraph with OAuth2 and folder selection — solid email plumbing, nothing more. The "phone screens" permission records agent-taken calls as tickets, but I found no public information on telephony integration, chat, a customer portal, messengers, or a customer history shared across channels. 4 5
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
We found no public information on a knowledge base, public help centre, article workflow, article suggestions, or deflection reporting anywhere in the captured pages. The homepage's listing of forum and professional services points to people-based support, and nothing evidences self-service content reducing ticket volume. 1 3
The Agent Advocate
I found no public information on a knowledge base, help centre or article workflow — the description covers corporate-level ticket management and the fork lineage, full stop. As far as the captured pages show, answers live in agents' heads and old tickets. 1 2
The Data Protection Officer
We found no public information on a knowledge base, help centre, article workflow, article suggestions or deflection reporting in any captured page; the product is presented as corporate-level ticket management and the queue documentation covers queues alone. 1 3
The Shop Operator
Nothing on the captured pages describes a customer help centre, article workflow, suggestions to agents or customers, or deflection reporting. The forum and professional services shown are the vendor's own support channels for running the software, not self-service for end customers. Deflection is my December metric, and here it is simply not evidenced. 1
The Integrator
The captured pages cover queues, mail collection and permissions, and I found no public information on a knowledge base, help centre, article workflow, suggestions to agents or customers, or deflection reporting. Nothing captured indicates that tickets are reduced as well as organised. 1 3 4 5
The Skeptic
I found no public information on a knowledge base, help centre, article workflow, article suggestions or deflection reporting on any captured page. The only self-service-adjacent item is a community forum, which serves the operator, not the operator's customers. 1
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
Access control is the evidenced strength: seven basic queue permissions plus configurable extended ones, so who sees and works which queue is genuinely granular. We found no public information on a published or requestable DPA, a stated retention period, an executable deletion path for a requester's data, an audit log, or attachment handling. 2 5
The Agent Advocate
The pages document genuinely fine-grained, executing access control: seven basic queue permissions from read-only to full write, plus extended ones for close, pending, bounce, forward and compose, all bound to queues and groups. On the protection side I found no public information on a stated retention period, a deletion path for a requester's data, an audit log of who opened which ticket, or a data processing agreement. 5
The Data Protection Officer
The permission model is the one documented strength: seven queue-level permissions from read-only to full access, with optional extended permissions behind system configuration, giving real control over which agents see which queue. Beyond that we found no public information on retention periods, executable deletion of a requester's data, an audit log of who opened which ticket, attachment handling, redaction, or a published data-processing agreement. 5
The Shop Operator
Access control is the strong part: seven basic permissions from read-only to full access, extended screen rights for close, pending, bounce, forward and compose, and queues as permission objects giving queue-level visibility. We found no public information on a published DPA, retention periods, deletion of a requester's data, an audit log of who opened which ticket, or how attachments like order confirmations are handled. 3 5
The Integrator
Access control is the documented strength: seven queue-level permissions from read-only to full access, plus extended permissions such as close and pending that only apply once implemented, so agent visibility can genuinely be scoped per queue. Against that, I found no public information on retention periods, a deletion path for a requester's data, subject-rights support, an audit log of ticket access, or a data processing agreement. 3 5
The Skeptic
Access control is genuinely granular: seven basic permissions per queue and module, plus extended permissions like phone, close and compose that only apply after system configuration — more than coarse roles. But I found no public information on a signable DPA, a stated retention period, an executable deletion path, attachment handling, or an audit log of who opened which ticket, and subprocessor exposure is recorded as unknown. 5 2
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
The only external-system connectivity shown is mail collection, including Microsoft Graph alongside IMAP and POP3. We found no public information on an API, webhooks, named CRM or shop integrations, SSO, SCIM, rate limits, or a sandbox — a support team would be copying customer context in by hand. 1 4
The Agent Advocate
The only outward-facing machinery shown is mail collection — including Microsoft Graph and OAuth2 authentication — and X-OTRS headers that can set ticket data from an incoming message. I found no public information on a documented REST API, webhooks, CRM or shop integrations, or single sign-on. 4
The Data Protection Officer
We found no public information on a documented API, named CRM, shop or identity integrations, webhooks, SSO or SCIM provisioning in the captured pages; the connectivity evidence covers mail protocols only, which is inbound mail rather than system-to-system context. 1 4
The Shop Operator
My test is the order in front of the agent without a second login, and we found no public information on shop, CRM or order-management integrations, a documented API, webhooks or SSO. The only programmatic reach shown is mail collection via MSGraph and X-OTRS headers that can set ticket data from an external system. 4
The Integrator
This is the criterion that decides my purchase, and I found no public information on a REST API, webhooks, SCIM, documented rate limits, a sandbox, SSO, or named connectors for CRM, shop or identity systems. The only machine interfaces captured are inbound X-OTRS mail headers that set ticket data without a filter, and MSGraph mail collection with OAuth2 — clever paths, but not surfaces I can build a CRM or order-management link against. Integration work appears to route through Znuny Professional Services and the community forum, which to me is a conversation where I want documentation. 1 4
The Skeptic
The only evidenced connection to an outside system is Microsoft mailbox collection via the MSGraph protocol, which reads mail in. I found no public information on a documented API, webhooks, CRM or shop integrations, SSO, SCIM provisioning, or rate limits. 4
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 German contracting entity is fully evidenced — Berlin address, Charlottenburg commercial register number, VAT ID — and the software is downloadable to run wherever we choose, so archive placement is in our own hands. We found no public information on hosting, ownership, subprocessors, or certification behind the professional services, which keeps it from going higher. 1 2
The Agent Advocate
The contracting entity is a German GmbH in Berlin with a commercial register entry and VAT ID, and the software is a free download you host yourself, so the ticket archive sits on infrastructure the customer chooses. I found no public information on ownership, hosting arrangements or any subprocessor list, which keeps this below the evidenced-in-full mark. 1 2
The Data Protection Officer
The contracting entity is firmly European — Znuny GmbH of Berlin with a Charlottenburg commercial register entry and German VAT ID — and the software ships as a download, so a buyer can run the archive on their own infrastructure. We found no public information on hosting arrangements, subprocessors, ownership or certification, which leaves the processing chain unevidenced. 1 2
The Shop Operator
Znuny GmbH is a German company with a Charlottenburg register entry, a VAT ID and a downloadable product, so the ticket archive can run on my own infrastructure under an EU contracting party. We found no public information on hosting arrangements, company ownership, subprocessors, or whether vendor support can read customer data — those gaps cap it for me. 1 2
The Integrator
The German contracting entity is fully evidenced — Znuny GmbH in Berlin, commercial register Charlottenburg under HRB 139852 B, VAT identification number DE281642846, named managing directors — and the software is a free download, so I could keep the ticket archive on my own EU infrastructure. I found no public information on hosting arrangements, a subprocessor list, or certification, and ownership and data residency are recorded as unknown. 1 2
The Skeptic
The German contracting entity is fully evidenced down to the Charlottenburg register number and VAT ID, and the software is publicly downloadable to run on your own infrastructure, which for many buyers is the strongest posture on the archive's location. But I found no public information on a subprocessor list, hosting or data-residency statements for vendor-run services, certification, or what Znuny Professional Services touches — and ownership is recorded as unknown. 1 2
Pricing transparency
not rated — the vendor publishes no price
panel disagrees
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
The licence price is public and unambiguous — the homepage states the software as "Free as free can be" with the latest release downloadable — so the software invoice is computable for any agent count with no tiers, bundles or add-on gates. What carries no public pricing is the professional services layer a team like mine would actually engage, and that is where computing the real annual cost stops. 1
The Agent Advocate
The price is one word and it is public: 'Software is free', 'Free as free can be', with download and guaranteed long-term support on the same page, so any agent count computes to the same software invoice. The single unpriced line is professional services, which the homepage names without a figure. 1
The Data Protection Officer
The software is free and downloadable — "Free as free can be" — so the annual licence invoice is zero for any agent count with the feature set as shipped, and no tiering is implied. The one unpriced element is Znuny Professional Services, for which no public prices are given. 1
The Shop Operator
The product page states the software is free, "Free as free can be", with a public download and no tier or add-on prices shown, so the software price is public for any agent count. But professional services are offered without published numbers, so a support lead who needs implementation help cannot compute the real annual invoice from the public pages alone. 1
The Integrator
"Free as free can be" is about as computable as a headline price gets: the software is a free download with the current release and an LTS release listed, so the licence line of my annual invoice is zero at any agent count. Beyond that I cannot compute the invoice: Znuny Professional Services is offered and I found no public information on its pricing, nor on what the guaranteed long-term support costs or to whom it applies. 1
The Skeptic
The licence line is unambiguous — "Software is free", with a public download and a stated latest LTS version — so the software portion of the invoice is trivially computable at zero for any agent count. But Znuny Professional Services and any paid support carry no public figures, so the real annual cost of running this with vendor backing is not computable from the captured pages. 1
European sovereignty — proven facts
1 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 | 2 Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | 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.
- 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.
- We found no public information on compliance on the pages we read (znuny.org/en, znuny.org/en/imprint, doc.znuny.org/znuny/concepts/queues/index.html, doc.znuny.org/znuny/admin/email/postmaster_mail_account.html, doc.znuny.org/znuny/annexes/permissions/index.html). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
Sources (5)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.znuny.org Checked 15 Sep 2026 Details →
- 2 Imprint www.znuny.org Checked 15 Sep 2026 Details →
- 3 Ticketing, queues & SLA — found from sitemap doc.znuny.org Checked 1 Oct 2026 Details →
- 4 Channels in one queue — found from sitemap doc.znuny.org Checked 1 Oct 2026 Details →
- 5 Customer data protection — found from sitemap doc.znuny.org Checked 1 Oct 2026 Details →