Your ticketing system, running
the AI model of your choice*
* Or your own.
The model that reads, classifies, and routes your tickets is one you choose: a commercial API on your own key, an open-weights model on your own hardware, or your own fine-tune. It plugs in the way any other integration does, so swapping it is a configuration change rather than a migration.
The whole system runs on your infrastructure — on-prem, private cloud, or air-gapped — so tickets, models, and identity never leave your boundary. And every triage call, approval, reject, and correction your operators make is training signal that stays on your side of it.
Work arrives as a ticket — or a case, if you work in a regulated function. Either way it carries the approval record and the audit trail with it.
Task: Duplicate settlement not reversed · Northwind Distribution · SET-4471
Auto-created by settlement-webhook/v1/duplicate-capture after the nightly settlement run matched a second capture against a payout that had already posted.
Reverse the duplicate capture on SET-4471 and credit Northwind 4,850.00. Payout PO-88213 posted on 04/08, so the second capture is recoverable in-ledger without a customer-side refund.
Matched 37 resolved tickets with the same settlement signature. Operators reversed in 35; the two exceptions were both post-dated captures.
Actions
payments-provider · second review required above $2,000
Send settlement correction notice to ap@northwind.example
Attach ledger trace SET-4471 to this task
Your website form is now a ticket queue
Route contact forms, support requests, and demo bookings straight into Latch — with ticket routing, audit logging, and approval gates applied from the moment a submission lands. No shared inbox, no spreadsheet, no lost thread.
Ticketing that controlswhat happens next.
Every ticket carries its full lifecycle — intake, triage, approval, execution, and proof — in one record. Extend it with plugins, run your own models, and deploy it where data residency rules say the data has to sit. See the self-hosted deployment model.
Your ticket volume is growing. Your audit trail is not.
Most teams start with a shared inbox, Slack approvals, and a spreadsheet of exceptions. That holds until it does not — a refund goes out without review, an escalation is handled without a record, and a regulator asks to see the decision trail.
One ticket queue
Stop splitting work between a shared inbox, Slack channels, and spreadsheets. Every ticket lands in one queue with its context, history, and evidence attached.
Approval gates that hold
Two-person review (maker-checker), role-based access, and role separation applied by the platform. Not by memory, and not by a Slack emoji.
Immutable audit trail
Every approval, every action, every denied attempt — recorded in an append-only trail. When a customer, a manager, or a regulator asks what happened, the answer is already on the ticket.
On-prem ready.Cloud optional.
A cloud help desk asks you to move the queue into the vendor tenancy first. Latch installs inside your environment instead, so ticket data, AI models, and identity stay under your control — on-prem, private cloud, or fully air-gapped. Teams under data residency rules can point at the rack the data sits in.
Teams moving off an incumbent usually want the comparison first. The Zendesk alternative comparison covers migration and data residency, including what Zendesk does better. The self-hosted ticketing page covers the deployment shapes in detail.
Most systems that learn from your tickets require you to hand over the tickets. This one does not. When an operator reroutes a ticket the system misfiled or rejects a proposed next step, that decision becomes signal, the next suggestion changes, and the improvement stays on your side of the boundary.
Run it on-prem, in private cloud, or air-gapped
Ticket data, AI models, and identity stay inside your boundary. Start on the managed service and move to self-hosted later if you prefer — the queues, the approval gates, and the audit trail do not change.
Run your own AI models
Use Latch-managed models, host your own, or point at models your team already operates. The approval gate and the audit trail behave the same regardless of where inference happens.
Human review where the risk is real
Require two-person review before a refund runs, an account change goes live, or a ticket moves to execution. Skip it where the risk is low.
One ticket from intake to resolution
Intake, triage, approval, execution, and proof stay connected on the same record. Workflow automation runs across the whole path, not just the part that sends the acknowledgement email.
Every ticket lands in one queue
Email, web forms, alerts, and system events arrive in a single queue with their context attached — not split across a shared inbox, a spreadsheet, and three chat threads.
Ticket routing that sharpens with use
The system classifies each ticket, sets priority, picks a queue, and proposes a next step. Every suggestion your team accepts, edits, or rejects feeds back in, so routing starts to reflect the calls your operators actually make. The operator still decides what runs.
Approval gates on the actions that carry risk
Require two-person review (also called maker-checker) before a refund goes out, a vendor bank detail changes, or a high-risk action executes. The platform holds the gate. A process document and a Slack emoji do not.
Extend with plugins and your own models
Write plugins in TypeScript or Go to connect Stripe, your ERP, internal APIs, or a model your team already runs — with permissions, approval gates, and immutable logging applied to every call.
Immutable audit trail on every ticket
Who approved, what changed, what the downstream system returned, and every denied attempt — recorded as it happens. When an auditor asks what happened, the answer is already on the ticket.
Built for service desks, regulated operations, and platform teams
Latch is one system, but the value shows up differently depending on who owns the queue. Start with the track closest to your work.
Operations & Service Desk
Run one ticket queue from intake to resolution, with SLA management, an escalation policy the system applies rather than remembers, and an audit trail behind every decision.
Banks & Regulated Industries
Work reversals, refunds, and exception cases with two-person review (maker-checker), immutable logging, and a deployment that satisfies your data residency rules.
Platform Teams & Developers
Write your own plugins, run your own AI models, and extend ticket workflows with the TypeScript or Go SDK — without hard-coding every integration.
Questions buyers usually ask first
These are the first questions teams ask when they evaluate Latch as a self-hosted ticketing system and help desk.
Can Latch run on our own infrastructure?
Yes. Latch Workflow is a self-hosted ticketing system first. It deploys on-prem, in a private cloud, or air-gapped, so ticket data, AI models, and identity stay inside your boundary. A managed service exists if you want to start there and self-host later.
Where does our ticket data live, and what leaves the network?
Tickets, attachments, model inference, and identity stay wherever you deploy Latch. In an air-gapped install nothing leaves at all. That is the difference from a cloud help desk, where the data has to sit in the vendor tenancy before anyone can work it — and where data residency is whatever region list the vendor offers this year.
What does the system do when an operator corrects it?
The correction becomes training signal. If your team keeps moving a class of ticket off the queue the system suggested, the suggestion changes. If reviewers keep rejecting a proposed next step, it stops being proposed. The learning happens on your tickets, inside your boundary, and it does not leave when a vendor ships a model update.
How does migration from Zendesk or Jira Service Management work?
Tickets, users, and macros come across through the API. Queue structure is rebuilt as routing and escalation rules rather than copied field for field, because that is where most of the cleanup value sits. Most teams move one queue first, run both systems for a few weeks, then cut the rest over.
What does it cost, and is this only for large enterprises?
No. Latch starts at $30 per month for teams of up to 20 users and scales to self-hosted enterprise deployments. Pricing is by tier, not per agent, so adding a reviewer who only approves does not change the bill.
How do plugins and custom models work?
Plugins connect Latch to Stripe, Slack, your ERP, internal APIs, or your own models. Write them in TypeScript or Go. Every plugin call passes the same permission check, approval gate, and immutable log as any other action on the ticket.
Start with one queue, not a migration
Take the queue that hurts most — refund approvals, vendor bank-detail changes, payment exceptions — and follow it through the walkthrough: how a ticket is routed, where the approval gate sits, what the audit trail records, and what the system does with the first correction an operator makes.