The Zendesk evaluation that ends in the security review
Most Zendesk evaluations do not fail on features. They fail when someone asks where the ticket data is stored and the honest answer is: on the vendor's infrastructure, in a region you pick from a list. For a consumer support team that answer is fine. For a bank, a hospital, a defence supplier, or anyone operating under data-residency rules, the project stops in that meeting.
The second failure arrives later. The ticket says the refund was approved. The refund ran in the Stripe dashboard, the approval happened in a Slack thread, and nobody can show what the payment processor returned. Latch Workflow is a self-hosted help desk for the queues where that gap costs something: a ticket, or a case, if you work in a regulated function.
what the review actually asks
Zendesk cloud, in a region you select on higher plans.
Your servers, your network, your backup policy.
A vendor-hosted service, under the AI terms you accept.
A model you host, inside the same boundary as the queue.
A ticket comment saying it was approved, written after the fact.
The request, the approver, the denied attempts, and the processor response.
For a high-volume consumer queue, Zendesk is usually the right answer
Zendesk has spent close to two decades building customer-experience tooling, and it shows in the places that matter for support at consumer scale. Latch does not compete on these and is not trying to.
Live chat, messaging, social, and telephony arrive in one suite with routing and staffing tools built for them. Latch covers email, web forms, and API intake. There is no Latch voice product.
Hundreds of prebuilt apps, most of which install in minutes without an engineer. Latch integrations are written against an SDK, which is slower to start and different in kind.
A mature help center with community forums, article localisation, and deflection reporting. Latch is a queue and a control layer. It does not try to be your knowledge base.
Support hires have worked a Zendesk queue before, the documentation is extensive, and the partner network is real. That lowers onboarding cost in a way a smaller vendor cannot match.
If your queue is consumer support, your volume is high, and no rule prevents ticket data from sitting in a vendor cloud, buy Zendesk. The rest of this page is for the teams where one of those three conditions does not hold.
Two things no Zendesk plan configures around
These are not gaps in a feature list. They are consequences of what Zendesk is: a hosted service that manages conversations.
Cloud only means cloud only
Zendesk offers regional hosting on higher plans, which satisfies a fair number of data-residency policies. It does not satisfy the policy that says ticket content never leaves the network, and it cannot run in an air-gapped environment at all. There is no plan, add-on, or contract clause that turns a hosted service into an on-premise one.
The whole system runs where you put it: your data centre, your private cloud, or a disconnected environment. Identity stays on your OIDC provider, the database is yours, and the AI models run beside the queue rather than behind a vendor endpoint. See the deployment and tenancy model.
The ticket tracks the conversation, not the action
Zendesk records what agents wrote and how the ticket changed state. It does not enforce that a second person approved the refund before it ran, it does not stop the preparer approving their own work, and it does not hold the response your ERP returned. Those events happen in other tabs and get summarised into a comment afterwards.
Sensitive work runs as a plugin action from inside the ticket, behind a role check and an approval step. The action does not execute until the decision exists, and the result written back includes what the external system said. Two-person review is enforced by the system rather than by a policy document.
Zendesk and Latch, side by side
The rows are ordered by what usually decides the evaluation, not by what flatters us. The last four rows go to Zendesk.
| Capability | Zendesk Cloud suite | Latch Workflow Self-hosted |
|---|---|---|
| Self-hosted deployment Runs on hardware you control | — Cloud only. No on-premise edition. | ✓ On-prem, private cloud, or your own VMs. |
| Air-gapped operation No outbound network dependency at run time | — Not possible for a hosted service. | ✓ Supported, including self-hosted models. |
| Data residency Where ticket content physically sits | ≈ Regional hosting on higher plans, on Zendesk infrastructure. | ✓ Wherever you deploy it, under your own controls. |
| Approval enforcement on downstream actions The action is blocked until a decision is recorded | — Approvals are convention. Nothing stops the refund running in another tab. | ✓ The plugin action does not execute until the approval exists. |
| Maker-checker and role separation The preparer cannot approve their own work | — No system-level separation of preparer and approver. | ✓ Self-approval is blocked and the attempt is recorded. |
| Audit evidence of the external result What Stripe or the ERP actually returned | ≈ Audit log of ticket changes and comments, not of the downstream call. | ✓ Request, decision, denied attempts, and response payload on the ticket. |
| Plugin execution against external systems How an action reaches Stripe, the ERP, or an internal API | ≈ Apps embed UI and call APIs, outside the ticket permission model. | ✓ Plugins run server-side behind role, policy, and approval checks. |
| Learning loop from operator decisions Who the model improves for, and where | ≈ Vendor-trained models improve on the vendor schedule, in the vendor cloud. | ✓ Your corrections train on your tickets, inside your boundary. |
| Per-agent pricing Whether cost tracks headcount | ≈ Priced per agent, per month, per plan tier. | ✓ Flat tiers by user band. No per-agent seat charge. |
| Live chat, messaging, and voice Real-time consumer channels | ✓ Mature chat, messaging, and telephony in one suite. | — Email, web form, and API intake. No voice product. |
| App marketplace breadth Prebuilt integrations you install rather than write | ✓ Hundreds of apps, installed in minutes. | ≈ SDK and plugins. Integrations are written, not installed. |
| Help center and self-service content Knowledge base, community, localisation | ✓ Full help center with community forums and translations. | — Not a knowledge base product. Pairs with the one you have. |
| Hiring and operator familiarity How long a new agent takes to become useful | ✓ Most support hires have already worked a Zendesk queue. | ≈ Familiar queue model, but the approval steps are new to learn. |
Compared against the Zendesk cloud suite as sold in August 2026, across plan tiers rather than a single plan. Zendesk ships changes often. Check the current plan pages before a decision rests on a row. Latch pricing is on the pricing page. The same comparison against Jira Service Management covers the ITSM and issue-tracking side of the question.
The queue sharpens on your corrections, and the improvement stays put
Most systems that learn from your tickets require you to hand over your tickets. That is the trade a cloud help desk asks you to make. Latch does not ask for it: the model runs inside the same boundary as the queue, so the corrections your operators make train the deployment they are already using.
The operator still decides. Suggestions arrive with the evidence behind them, and when the signal is thin the system offers nothing rather than guessing. Read how ticket routing and triage work.
Move one queue first, not the whole help desk
A full cutover on day one is how migrations fail. The queue with the strongest case for moving is usually the smallest: payment exceptions, vendor changes, or whichever back-office workflow currently runs half in Zendesk and half in Slack.
Export the full history
The Zendesk API returns tickets, comments, users, organizations, custom fields, tags, and attachments. Pull the whole history rather than a date window. Reconstructing an archive later costs more than storing it now.
Map the structures that survive
Groups become queues, ticket forms become ticket types, macros become templates, and SLA policies map across. Three things do not survive unchanged: marketplace apps, chat transcripts, and help-center articles. Decide where each of those lands before the import runs.
Run one queue in parallel
Point the intake address for a single workflow at Latch and leave everything else on Zendesk. Add the approval step on the action that needed one all along. The team compares the two on real work rather than on a demo dataset.
Cut over per queue, or do not
Move the next queue when the first one is boring. Keeping Zendesk for consumer chat while the regulated back office runs on Latch is a legitimate end state, not a half-finished migration. Escalation policies and handoffs work across the two.
If your volume is chat and voice, if your workflows depend on marketplace apps nobody wants to rewrite, and if no policy restricts where ticket data sits, a migration will cost more than it returns. Say no to it. The teams that gain from moving are the ones already paying for the gap in another currency: manual approval chains, evidence assembled by hand before an audit, or a compliance answer they cannot give.
Self-hosted ticketing
What on-premise, private cloud, and air-gapped deployment mean in practice, and what you take on by running it yourself.
See self-hosted ticketingPlugins and integrations
How an action reaches Stripe, an ERP, or an internal API from inside the ticket, and what the plugin writes back.
See pluginsOperations teams
Queue design, escalation policy, and SLA management for the teams running exceptions rather than consumer support.
See the operations pathQuestions teams ask before they switch
The questions that come up in the second meeting, once the feature comparison is done and the migration is real.
Does Zendesk offer an on-premise or self-hosted version?
No. Zendesk is a cloud product. Higher plans let you choose a hosting region, which satisfies some data-residency policies, but the ticket data still sits on Zendesk infrastructure under Zendesk operational control. If your requirement is that ticket content never leaves your network, or that the system runs air-gapped, regional hosting does not meet it and there is no configuration that will.
Can we keep Zendesk for consumer support and run Latch on the regulated queue?
Yes, and for several teams that is the sensible end state. Zendesk keeps the high-volume consumer channels, including chat and voice. Latch Workflow takes the back-office queue where refunds, vendor bank-detail changes, and account actions need an approval step and an evidence trail. The two systems do not need to share a database to coexist. Intake for the regulated queue is pointed at Latch, and the rest of the traffic keeps arriving where it does today.
What does a migration from Zendesk actually involve?
The export is not the hard part. The Zendesk API returns tickets, comments, users, organizations, custom fields, and attachments, and that import is mechanical. The work is in the field mapping and the apps: which marketplace apps your macros depend on, which of those are now plugin work, and which help-center content moves to a knowledge base rather than into the queue. Start with one queue and keep the rest on Zendesk while it runs in parallel.
Is Latch cheaper than Zendesk?
It depends on headcount and on who runs the infrastructure. Latch is priced in flat tiers by user band rather than per agent per month, so cost stops tracking headcount as the team grows. Against that, self-hosting means someone owns the deployment, the upgrades, and the backups. For a three-person team the difference is small. For a team of thirty on a mid-tier Zendesk plan, the seat arithmetic changes the answer.
Do we lose the Zendesk app marketplace?
Yes, and that is a real cost worth naming. Zendesk has hundreds of prebuilt apps you install in a few minutes. Latch has an SDK, so an integration is written rather than installed. The trade is that a Latch plugin runs server-side behind role, policy, and approval checks, and writes what the external system returned back onto the ticket. Installing an app is faster. Writing a plugin is what makes the action provable.
What happens to AI features if the data stays inside our boundary?
The models run where the tickets run. Latch supports self-hosted models, so triage suggestions, summaries, and classification are produced inside the same boundary as the ticket text. Operator corrections become training signal for that deployment and the improvement does not leave with it. Nothing is sent to a vendor endpoint for the queue to get sharper.
See the queue before you plan a migration
Walk through intake, triage, the approval step, and the audit trail on a real workflow. Bring the queue you would move first, the downstream system it touches, and the control you need to prove.