Our managed IT service is going live. And before the first organisation reports its first problem, one question had to be settled: how do requests reach us?
The obvious answer would have been: any ticket system will do, as long as it counts upwards. We deliberately skipped it and went all in: four systems on the shortlist, each one installed, configured and worked through with test data. Here is how we went about it, and what we chose.
Why this is not a matter of taste
A ticket system is not “an inbox with numbers”. It is the place where it is decided whether a problem is solved in two hours – or spends three weeks rotting in an email thread.
In the non-profit sector, something else comes on top. Organisations rarely employ people whose job is to operate a ticket system. There is the finance colleague who, between two invoice runs, reports that the printer on the second floor has given up. There are volunteers who talk to IT twice a year. A system those people avoid does not produce tickets – it produces corridor conversations, private mobile numbers and knowledge that is written down nowhere.
And it is about data: support tickets contain names, devices, sometimes health details from an HR request. Where that system runs, and who has access to it, is not a minor detail.
Our five criteria
Before the first click we defined what we would measure. Otherwise the system with the longest feature list always wins.
- Usability and adoption. Can people without an IT background create a ticket and understand its status – without training?
- GDPR and self-hosting. Does the system run entirely on our own infrastructure in Germany, with no detour through someone else’s cloud?
- Channels and knowledge base. Do email, phone and chat arrive in one inbox? And can solved cases turn into a knowledge base, instead of typing the same answer for the fourth time?
- Open source and cost. Open code, no per-seat licence, no vendor lock-in. Non-profit budgets cannot carry pricing models that grow with every new colleague.
- AI support. Does the system help sort requests and draft replies – while the decision stays with a human?
The four candidates
Znuny
The fork of the classic OTRS, and therefore a system with a very long operational track record. Queues, escalations, SLAs, reports – all there, all proven, and rightly in use across large IT organisations.
Which is exactly the point. Znuny is built for support departments that want to cast their processes into roles and permissions. The interface assumes you know what a queue is. For our audience, that is a hurdle before the first ticket.
GLPI
Impressively broad: ticketing, asset management, problems, changes, a service catalogue and dashboards that show more at a glance than many a business intelligence report. If you need a CMDB, it comes included.
For an organisation of thirty people, that is a full ITIL apparatus for a job that needs none. The effort does not arise during installation but afterwards: a system that can do this much wants to be configured and maintained. That time is then missing from the actual work.
ITFlow
The most interesting candidate in the field – and the one we argued about longest. ITFlow does not start from the ticket but from the client: contacts, locations, assets, networks, credentials, domains, certificates and billing in one interface. Precisely the things an IT service provider otherwise spreads across three tools and a spreadsheet.
For us as the operator, that is strong. But the ticketing itself is the leanest part of it. For the place where our clients get in touch with us, it was too thin. So ITFlow is not off the table – just not as our ticket system.
Zammad
Born out of the OTRS world, but consistently rethought. Email, phone and chat converge in a single inbox. The knowledge base is part of the system, not an annex. And the interface largely explains itself: anyone who can write an email can work a ticket.
On top of that comes AI support aimed at the right place: classify, summarise, suggest replies. The decision stays with the people.
The decision: Zammad
Zammad won because it led clearly on four of five criteria, and nobody led on the fifth.
Adoption over feature count. The most powerful system is rarely the right one. What matters is whether a volunteer opens a ticket at 7pm – instead of calling the next morning.
Data sovereignty without compromise. Zammad runs entirely on our own infrastructure. No ticket data in someone else’s cloud, no processing agreement three parties deep, no debate about third-country transfers.
One inbox instead of three. Mail, phone and chat in one place – and every solved request can become an entry in the knowledge base. Support that creates less work over time, not more.
Costs that fit non-profit budgets. Open source, no per-seat price. When an organisation grows, the invoice does not grow automatically with it.
AI as relief, not as a black box. Pre-sorting and drafting yes, deciding automatically no. With data from the non-profit sector, that is not caution but obligation.
And the honest counter-reckoning: GLPI and Znuny are good systems. They did not fail on quality but on fit. Both bring a process apparatus our clients do not need, and maintaining it costs time that is missing elsewhere. ITFlow stays on our radar, but for other jobs.
What this means for you
We made this choice for ourselves. The result is only useful if it transfers – and the path to it does:
- Criteria before candidates. Look at systems first and decide what matters afterwards, and you will buy the longest feature list.
- Install instead of compare. Feature tables say little about how a system feels after twenty tickets. A test installation costs a day and replaces a lot of opinion.
- Name the reason for rejecting. A candidate that merely “didn’t quite fit” will be back in six months.
And if you would rather not make this decision yourself: we have already run the test. What we can do for ourselves, we can do for you.