REQUESTS, SERVICE AND FIELD WORK
Bring support requests, field inspections and everyday operations into one ticketing workspace. Keep ownership, follow-up and results together, with independent approvals when an action needs review.
Managed hosting available. Self-hosting and source-code access on Enterprise.
YOUR MODEL. YOUR INFRASTRUCTURE.
Choose where the work runs.
Use a commercial model on your own key, an open-weights model on your hardware, or your own fine-tune. Deploy Latch in your environment or in a private cloud, with approval gates and an audit trail around the work.
See model and deployment options →Your website form is now a ticket queue
Route contact forms, support requests, and demo bookings straight into Latch — with ticket routing and action history in one place. Configure an approval gate for the sensitive action that follows intake.
Ticketing that controlswhat happens next.
Keep intake, triage, action requests and returned results connected. Configure the workflow, extend it with plugins, and assess deployment against your residency requirements. Review Enterprise source access and licensing.
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
A configured action requires independent approval before execution. Permissions and the current approval state are checked when it runs.
Connected action history
Review who requested and approved the action, what ran, and what the downstream system returned. Database privileges and independent retention remain part of your operating controls.
Ready for your environment.Cloud optional.
Evaluate Latch in your own data centre or cloud account. Start with the location of tickets and attachments, then inspect identity, email, model and plugin traffic. A deployment diagram and a restore test give your platform and risk teams something concrete to review.
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 source access and licensing page explains what to review on Enterprise.
Configure the queue and its permissions first. Use a plugin to add a custom action such as transaction reprocessing. Assess a source change only when the requirement belongs in the application, and include upgrade ownership in that decision.
Choose your deployment
Evaluate self-hosting in your data centre or cloud account. Plan identity, durable attachment storage, email, backups and integration traffic as part of the deployment.
Choose how to adapt it
Start with configuration. Add a plugin for a custom external action. Enterprise source access lets you assess application changes under the commercial source licence.
Choose which actions need review
Apply maker-checker to selected plugin actions. Test reviewer permissions, expiry, ticket changes and downstream failures on the workflow your team actually runs.
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.
Bring incoming work into one ticket queue
Email, web forms and API requests create work with its context attached. Operators can assign an owner and keep follow-up on the same ticket.
Triage with operator review
Use configured routing and model-assisted suggestions to help sort incoming work. Operators review suggestions and decide which actions to request.
Request approval before a sensitive action runs
Configure a plugin action with maker-checker review. The action requester cannot approve or execute that request; another authorized person reviews it.
Run the action through a controlled plugin
Approval and execution are separate steps. The plugin connects to the downstream system, while Latch checks permissions and the request state before execution.
Keep the decision and returned result together
The ticket shows the action request, approval transitions and execution result. Reconcile an uncertain outcome with the downstream system before attempting it again.
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
Keep incoming tickets, ownership, review and action results together. Start with one queue and one approval path.
Banks & Regulated Industries
Review reversals and exception cases before execution. Evaluate deployment, independent approval and retained evidence against your own controls.
Platform Teams & Developers
Configure workflows, add custom actions through plugins, and evaluate Enterprise source access when the change belongs in the application.
Questions buyers usually ask first
Start with deployment, customization, source terms and the approval path your team needs.
Can Latch run on our own infrastructure?
Yes. Evaluate a self-hosted deployment in your data centre or cloud account. Your team owns the operating plan for identity, durable storage, backups, email and integrations. A managed service is also available.
Is the source code available?
Source code is available on Enterprise under a commercial source licence. Review the agreement for permitted changes, use and redistribution. Source availability is different from an unrestricted open-source licence.
How can we customize the ticketing workflow?
Use configuration for queues, permissions and approval settings. Write a TypeScript or Go plugin for a custom external action. Evaluate Enterprise source access for changes that belong in the application itself.
Who can approve a sensitive action?
For an action configured with maker-checker, the action requester cannot approve or execute their own request. Another authorized person reviews it. Execution is a separate step after approval, and permission and request-state checks still apply.
Does self-hosting guarantee compliance or no outbound traffic?
Self-hosting gives you control over the deployment location. Compliance depends on your policies and operating controls. Identity, email, models and plugins can have network dependencies; assess their data flows before choosing a restricted network design.
Can we use our own AI model?
Yes. Model configuration is a supporting deployment choice. Review where inference runs and what data reaches the configured endpoint. Suggestions do not replace permission checks or an approval gate configured for an action.
See one queue from request to resolution
Follow a ticket through the walkthrough. See how routing works, where approval is required, and what the audit trail records.