The service desk that does not send its tickets to the cloud

A ticket is a short document with a long memory. The subject line is harmless. The body is not. It names a person, a device, a contract number, sometimes a diagnosis or a payroll problem. For a service desk running OTOBO or Znuny inside its own network, that text is the reason a cloud chatbot is a hard sell.

This is not a theoretical privacy debate. It is the conversation that now happens before anyone talks about models.

What the desk is actually protecting

German and Austrian operators already keep the ticket system on their own hardware or in a contracted data centre. The queue structure, the SLAs, and the agent replies live there. The new request is narrower: can the system suggest a queue, a priority, or a first reply without copying the ticket to a vendor’s API?

Three facts decide the answer.

1. The text is personal data. A name plus a problem description is enough. A works-council agreement or a customer contract often already forbids “processing in a third-country AI service” even when the IT team would accept the risk.
2. The useful signal is local. Queue names, historical subjects, and the last few thousand closed tickets are already in the database. A classifier does not need the public internet to learn that “VPN token expired” belongs in Access, not in Hardware.
3. The failure mode is a wrong queue, not a wrong essay. Agents can correct a suggestion. They cannot easily recall a ticket body that has already left the building.

That is why the practical projects look dull from the outside. There is no chat window on the customer portal. There is a suggested queue, a confidence value, and a rule that says: below a threshold, leave the ticket alone.

What a careful pilot measures

A pilot that is honest about its scope measures four things, and only those.

• Share of tickets the model is allowed to touch. New mail in two or three high-volume queues is enough. Do not start with major incidents.
• Agreement with the agent. After two weeks, compare the suggested queue with the queue the agent finally used. Disagreement is a label, not a failure of the project.
• Time to first correct queue. The gain, when there is one, shows up here. It does not show up in a dashboard of “AI deflection.”
• What was sent off the network. If the answer is “nothing,” write that down. It is the sentence legal and the works council will ask for.

Teams that skip the fourth point and lead with a vendor demo usually restart the project three months later, with a smaller scope and a stricter host.

Where OTOBO and Znuny fit

Both systems already have a place to hang this work. Inbound mail becomes a ticket. Dynamic fields can store a suggestion and a confidence score. A generic interface or a small side process can call a model that runs next to the application, on the same network, and write the result back.

The model does not replace the agent interface. It does not need to. The interface agents already trust is the one that should show the suggestion. A second product UI is how pilots get ignored.

Znuny and OTOBO differ in release pace, packaging, and who you call when a patch misbehaves. They do not differ in the privacy question. If the ticket body must stay on the server, the model has to be reachable from that server without a public API key.

What this is not

It is not a claim that local models match every hosted assistant at open-ended writing. Drafting a long, polite reply is a different job from picking one queue out of twelve. Desks that need both should split them. Classification and routing are the part that pays for itself on historical tickets. Free-form writing can wait until someone has decided where that text is allowed to be processed.

It is also not a reason to rip out a working cloud ITSM suite. Organisations that already run ServiceNow, Jira Service Management, or a hosted help desk have a different contract and a different exit cost. The pattern in this piece is for teams that chose an open-source ticket system precisely so the data would stay put.

A reporting note

Softoft, in Mainz, implements this pattern on OTOBO and Znuny: the connector, the runtime next to the ticket system, and the rollout on the customer’s infrastructure. The product behaviour of the on-prem stack is documented separately at OpenTicketAI. Comparisons of the ticket systems themselves belong on Open ITSM Hub.

If the constraint in your environment is the same — ticket text does not leave the network — the useful next step is a bounded pilot on two queues, not a platform decision.