Nov. 8, 2026

We chose Zammad as our service desk after trying out several others.

16 min read
We chose Zammad as our service desk after trying out several others.

Providing good customer service isn't just about responding. It's about always knowing the status of a request, not losing track of a conversation, and ensuring that whoever takes on a problem has the necessary context to resolve it. It's a matter of taking those who trust us seriously—not about how many people we have.

That's why a well-designed service desk isn't just a nice-to-have: it's the tool that allows us to maintain that level of care, ticket after ticket.

Over the years, we've tried several: Zoho Desk, Zendesk, Freshdesk. Each one solved some problems but caused others. We've been using Zammad for a while now, and we're not already thinking about what to replace it with.

The problem wasn't "we need a ticketing system"

The problem was that our work isn't linear. We develop custom software and perform system integration: a request could be a bug in production, a question about a feature, a change that needs to be quoted, or an integration that stopped communicating with an ERP system at 6 a.m. These are different types of issues, with varying levels of urgency, that come in through different channels.

What we were looking for, in order of importance:

  • a single inbox for everything—email, phone, and website forms—without forcing customers to learn yet another portal;
  • Data control: Our customers’ tickets contain logs, screenshots, and sometimes sensitive data. They must be stored where we decide, under European jurisdiction;
  • No extra charge for basic features: a model that makes you pay extra for things that should be included by default is a model that undermines the process;
  • Real APIs, because sooner or later we'll connect them to something else. We always do;
  • No lock-in: if we change our minds one day, we can take our data with us.

With Zoho Desk, Zendesk, and Freshdesk, the problem was never that “it couldn’t be done.” It was that the features we considered essential—not just extras—were locked behind a higher-tier plan, or behind a per-agent price that makes you think twice before giving a colleague access.

Why Zammad

Zammad is an open-source (AGPL-3.0) service desk developed in Germany by the same team that created OTRS. Under the hood, it runs on Ruby on Rails with PostgreSQL, Elasticsearch, and Redis—an architecture that falls within our day-to-day expertise in infrastructure management. The self-hosted version is fully featured: no essential features are hidden behind an enterprise plan, and there are no limits on the number of agents.

Here's what convinced us after we actually used it:

A multichannel system that really works. Emails, phone calls, chats, and web forms all end up in the same place, with the same history. The customer writes to support@innove.it just as they always have: we handle the complexity, not them. We’ve also added a widget to the website, so requests go straight to Zammad even from those who don’t send an email.

The tickets you're tracking are always at your fingertips. It's a small thing on paper, but it makes a big difference: you don't have to search for them every time, and Zammad notifies you right away when something new comes in. It seems obvious, but it wasn't the case with the tools we'd tried before.

The thread view is really convenient. The replies appear in a compact sequence, one after another, without the signatures, logos, and legal disclaimers that usually trail at the end of emails—and that you have to scroll through every time in other tools. You’re reading a conversation, not an archive of clutter.

Private notes for you or your colleagues. Within the ticket, you can add notes that the customer can't see—useful for sharing context between the person who opened the case and the person who closes it, or for leaving yourself a reminder.

The ticket ID is easy to copy, and it’s useful for one very practical reason: we include it wherever we log completed tasks, so every action can be traced back to the original ticket without having to figure out later “what it was referring to.”

Our data, on our own premises. We’ve installed it locally on our servers: no third-party cloud, our own backups, and de facto European jurisdiction because the data never leaves our infrastructure. For a company that also works with regulated sectors—such as insurance and healthcare—this isn’t a philosophical preference: it’s a requirement that is specified to us in writing.

APIs and webhooks. Zammad integrates with the rest of our stack rather than operating in isolation. It’s the same principle we apply to client projects: tools need to communicate with each other; otherwise, they’re just different places where information gets lost.

What It Isn't (Because No Tool Is Free)

Intellectual honesty, which is more useful than an endorsement:

  • It's not "install and go." It requires infrastructure expertise for installation, updates, and security—we've installed it and maintain it locally on our servers. If you're looking for an advanced shared mailbox without having to worry about the infrastructure, this is overkill.
  • It comes at a cost—it’s just not an invoice. It’s time: setup, maintenance, updates (including security releases, which must be applied immediately). The “free” aspect of open source is always a different form of payment, never a discount.
  • Few people are familiar with it. Compared to Zoho, Zendesk, or Freshdesk, it’s less widely used, especially in Italy: that means fewer tutorials available and a smaller—though active—community.

For us, it makes sense, for one simple reason: we’re already used to paying that cost. We manage infrastructure every day. The time another company would spend learning how to do it, we’ve already spent.

The part that really matters

The most useful thing wasn't the software. It was being forced to document the process: what a ticket is, who assigns it, how quickly we respond, when it's closed, and what happens if no one addresses it. Zammad forces you to make decisions. And most support issues, in our experience, aren’t tool-related problems—they’re decisions that no one has ever made.

If you have a support service that operates through a shared email inbox and things occasionally get lost, the problem isn't that you need Zammad. It's that you need a process—and then a tool to support it. Let’s talk about it: we design and integrate custom support systems, including ones that connect to the business management software you already use.

Frequently Asked Questions

Is Zammad free?

The software is open source under the AGPL-3.0 license and can be freely installed on your own servers, with no license fees or agent limits, and without having to pay extra for basic features, as is the case with some paid tools. Zammad GmbH offers a managed cloud version and support contracts for a fee. The real cost of the self-hosted version is the time spent managing the infrastructure.

Is Zammad a good alternative to Zendesk, Freshdesk, or Zoho Desk?

For those with in-house systems expertise (or a partner who has it), yes: it covers multichannel support, automations, a knowledge base, LDAP/SAML, and APIs—with no per-agent fee and full control over your data. For those who want zero maintenance, a SaaS solution remains the simpler option.

Where is data stored with Zammad?

In the self-hosted version, you decide: your own servers or the European cloud. We’ve installed it locally on our own servers. That’s the main reason we chose it to manage support for projects in regulated industries.

Does Zammad integrate with other systems?

Yes: It exposes REST APIs and webhooks and integrates with LDAP/Active Directory, Microsoft 365, telephony systems, and—with a bit of system integration work—with business management software and ERP systems. It also supports a widget that can be embedded directly on a website to receive tickets from visitors.

Text written with the help of AI, reviewed by Innove.

Photo by Drew Jemmett on Unsplash