🎫 AI Ticketing — support tickets that investigate themselves

Released 2026-07-22

A support ticket used to be somewhere to put a problem. This release makes it the thing that works on it. A ticket raised from a chat — or from an alert, before anyone has complained — gets triaged, investigated against your own logs and databases, and written up with a root cause and the evidence behind it. You decide how far the AI is allowed to go.

Highlights

Tickets that investigate themselves

• Raised from anywhere — the AI opens one mid-conversation when it can't answer from your knowledge base, an agent raises one from a chat, or a Grafana / Alertmanager webhook opens one automatically.
• Triaged on arrival — priority, severity and intent set by the AI, the title rewritten into one clear line, and near-identical reports folded into the existing ticket instead of piling up.
• A glass box, not a black box — the AI proposes hypotheses, tests each one against your tools, and marks it validated, invalidated or inconclusive with a confidence score. Every query it ran is recorded and readable.
• A root cause you can check — summary, impact, timeline, contributing factors, remediation and prevention, with citations back to the evidence that proves it.

You set the ceiling

• L1 — investigate and document only. Every customer message stays a human action.
• L2 — the AI proposes a resolution; you approve, or reject with a reason that feeds a refined investigation.
• L3 — the AI may also message the customer and close the ticket, behind confidence guards. Best for well-scoped, low-risk queues.
• ChatterMate never writes to your systems. Approving a proposal records who decided and when — the change itself is still made by your team.

Connect your logs and databases

• Observability over MCP — one-click Grafana, Elasticsearch, Sentry and CloudWatch, or any MCP server (Datadog, Splunk, New Relic, your own).
• A guardrailed SQL connector — Postgres or MySQL, directly or over an SSH tunnel for production databases behind a bastion.
• You pick what it can see — an explicit table allowlist, masked columns, and optional row-level scoping that restricts a table to the ticket customer's own rows.

It counts against your plan

• Investigations draw from your existing message quota — one message per model call, the same meter chat and FAQ generation already use.
• Triage always runs so tickets stay classified; a full investigation pauses, with a note on the ticket, when an organization is out of credits.
• Bring-your-own-key organizations pay their provider directly and are never metered.

CSAT that closes the loop

• A resolved ticket asks for a rating, and the score now lands on the ticket — previously it only attached to the conversation, so nothing could report on it.
• The workspace shows the split that matters now that L3 exists: AI-resolved versus human-resolved satisfaction.

Fixes

• Shopify product cards attach reliably instead of depending on the model to emit them.
• A closed notification drawer no longer paints a shadow over the page on mobile.
• The installed app applies your saved theme before first paint instead of flashing the wrong one.
• Investigate is disabled on a resolved ticket until it is reopened — in the UI and enforced by the API.
• Sending an RCA to a customer can no longer be double-fired by a second click.
• Super admins can approve ticket actions in the UI; the frontend check now matches what the backend already allowed.

Under the hood

• A new ticket_investigator container runs triage, investigations and lifecycle hygiene.
• SQL from the model is parsed to a syntax tree and re-rendered before it executes, rather than pattern-matched. Comments are stripped on the way through, because MySQL executes some of them.
• Investigation evidence is PII-redacted and truncated as it is recorded.
• The Shopify product cache key now has a single source of truth.
• chattermate-cli 0.7.0 adds a ticketing command group — list, show, investigation, rca, investigate, settings.

Upgrade notes

• Add the ticket_investigator service to your compose file — same image as the backend, command: python -m app.workers.ticket_investigator. Without it nothing processes investigations: tickets will triage and then sit.
• New dependencies: sqlglot, pymysql, sshtunnel, and paramiko>=3.4,<4 — sshtunnel 0.4 still calls an API that paramiko 4 removed.
• Migrations run on backend start as usual. Deployments with the enterprise module must run the enterprise migrations separately; they do not auto-run.
• Cloud: AI Ticketing is a Pro feature. Self-hosted: fully open, no gating.
• Ticketing can be switched off per agent under the agent's Integrations tab.

Security

• Point the database connector at a least-privilege, read-only user — never a superuser — granted only the tables support genuinely needs. The connector enforces SELECT-only, an allowlist, a forced row limit, a read-only transaction and a statement timeout, but the database should be locked down as well.
• Masked columns cannot be referenced anywhere, including in a WHERE clause, so their values cannot be probed a row at a time; row-serialisation tricks that would smuggle them past name-based masking are blocked.
• The row-level scope is applied to the table the query reads from, not to a condition the model writes, so a query cannot widen its own scope.
• Identifiers belonging to anyone other than the recipient are stripped from outbound customer messages, and other customers' tickets are redacted before they reach the model.
• Every query attempt is audited with its SQL and outcome. Returned rows are never stored.