Zammad teams often want AI that routes and classifies tickets without sending full message bodies to a third-party API. OpenTicketAI (OTAI) for Zammad is built around that idea: metadata-driven training in the EU, signed model artifacts, and on-premise inference so routine automation stays inside your perimeter.
What OTAI solves for Zammad
The product focuses on AI-powered queue routing tied to how you actually organise work in Zammad — your groups (queues), described in a concise QueueSpec (names and short descriptions). That specification is enough for OTAI Studio to generate synthetic training data and train an adapter aligned with your taxonomy, typically with a same-day turnaround. Real production tickets are not required for that training step.
How the lifecycle fits together
- Define groups — You supply Zammad group names and descriptions as the QueueSpec.
- Train — EU-hosted OTAI Studio builds synthetic data from the QueueSpec and produces a trained, signed model artifact.
- Deploy on-prem — You run OTAI Runtime Core (for example via Docker Compose), load the artifact, and keep all inference local.
- Integrate — A Zammad connector plugin reads new tickets and writes routing decisions (and optional field updates) back into Zammad.
The architecture deliberately limits what leaves your network: queue metadata for training flows to OTAI Studio, while ticket content stays on-prem for inference.
More than group assignment
On the solution page, OTAI describes automation across several Zammad dimensions, not only the target group — for example priority, state, tags, and custom object attributes, depending on how you configure and license the deployment.
Practical requirements
For a typical setup you should plan for Zammad 6.0 or newer, Docker / Docker Compose for the runtime, API access (including an admin token where needed), and at least two CPU cores and 4 GB RAM for the runtime footprint — as summarized on OpenTicketAI’s Zammad solution overview.
When this pattern fits
OTAI for Zammad is a strong match when governance or contracts rule out cloud inference on ticket bodies, but you still want modern classification and routing with a path to monitor confidence and retrain when groups or workloads change.
Softoft stays vendor-neutral on third-party products; OTAI is an independent vendor. Verify licensing, SLA, and data-flow details directly with OpenTicketAI before production commitments.
If you want help wiring Zammad APIs, connectors, or on-prem inference next to your existing processes, contact Softoft for implementation and integration support.