Skip to main content

​
AI Ticketing

Turn support issues into tickets that investigate themselves. ChatterMate raises a ticket from a chat (by the AI or an agent) or an incoming alert, auto-triages it, then runs an AI investigation that forms hypotheses, tests each one against your connected logs and databases, and writes a root-cause analysis with cited evidence — all in the open, with staged autonomy you decide.
AI Ticketing is a Pro / Enterprise feature. On the community (self-hosted) edition it is fully open.

​
Where to find it

  • Tickets in the main menu — the workspace: list, filters, and every ticket’s detail.
  • Ticketing under Settings — autonomy level, SLA targets, customer-message templates, and the investigation connectors.

​
How tickets are created

From a chat

When the AI can’t resolve a technical issue from the knowledge base, it opens a ticket for the conversation and links it — the customer keeps chatting normally.

Manually

An agent raises one from the Tickets workspace or straight from a conversation, with an AI-drafted title and description.

From an alert

A webhook from Grafana, Alertmanager or a generic source auto-creates a ticket and kicks off an investigation — before a customer even reports it.
Every new ticket is triaged by the AI: it sets priority, severity and intent, rewrites the title into one clear line, and deduplicates against open tickets so the same incident doesn’t spawn ten tickets.

​
The investigation — a glass box

When investigation sources are connected, the AI works the ticket like an on-call engineer, and you watch it happen. It proposes hypotheses, tests each against your tools, marks every one validated / invalidated / inconclusive with a confidence score, and cites the exact query and result behind each conclusion.
The result is a versioned root-cause analysis — summary, impact, timeline, contributing factors, conclusion, remediation, prevention, and a plain-language customer summary — with inline links back to the evidence that proves it. Nothing is a black box: every tool call is recorded, so you can audit exactly what the AI looked at.

​
Staged autonomy — you set the ceiling

The AI never exceeds the level you choose, and every level still logs its actions for audit.
1

L1 — Investigate only

The AI triages, investigates and documents. Every customer message and status change is a human action.
2

L2 — Propose, human approves

The AI also proposes a resolution. A pinned banner shows the proposal and the verification query behind it; you Approve or Reject with a reason (the reason feeds a refined investigation). Approving records who and when — ChatterMate never executes an infrastructure change.
3

L3 — Auto-resolve & notify

The AI may also message the customer and close the ticket, behind hard confidence guards. Best for well-scoped, low-risk queues.

​
Customer communications

Ticket-created and ticket-resolved messages use editable templates with [customer] and [ticket] placeholders and a live preview, so customers hear from you in your own voice. You can collect CSAT after resolution, and auto-close a resolved ticket after a set number of hours without a reply.
Customer emails are sent from your connected email inbox — connect one under Integrations to send from your own domain; otherwise ChatterMate’s address is used.

​
Connecting investigation sources

Under Settings → Ticketing, attach read-only sources for the investigation agent (they never touch the customer-facing chat agent):
One-click presets for Grafana, Elasticsearch, Sentry and CloudWatch, or any MCP server (Datadog, Splunk, New Relic, custom) as a generic entry — with encrypted per-org credentials.
Connect a Postgres or MySQL database — directly, or over an SSH tunnel for production databases behind a bastion. Pick exactly which tables the AI may read, mask sensitive columns, and optionally restrict a table to the ticket customer’s own rows.
Each saved connector shows exactly what it exposes — how many tables are allowlisted, how many columns are masked, and how many are scoped to the ticket’s own customer.

​
Database guardrails

The investigation agent reads untrusted customer text while holding live tool access, so the limits are enforced in code, not by prompting:
  • Read-only, structurally. Queries are parsed to an AST and rejected unless they’re a single plain SELECT against an allowlisted table, with a forced LIMIT. The connection itself is a read-only transaction with a statement timeout — a second, independent barrier.
  • Masked columns are never readable — blocked even in a WHERE clause, so values can’t be probed, and whole-row tricks are blocked too.
  • Row-level scoping rewrites a query to return only the ticket customer’s own rows — the AI can’t widen it.
  • Nothing is ever written to your database; approving a proposal only records the decision.
  • Every query is audited with its SQL and outcome; returned rows are never stored.
Point the connector at a least-privilege, read-only database user restricted to the tables support genuinely needs — never a superuser. Prefer views that are already scoped.

​
Usage & billing

Investigations run on the platform-hosted model and count against your plan’s message quota — one message per model call, the same meter chat and FAQ generation use. Cheap triage always runs so tickets stay classified; a full investigation is paused (with a note on the ticket) once an org is out of credits, and resumes next billing period or after an upgrade. Own-key organizations pay their provider directly and are never metered.

​
Works alongside Jira

Native tickets don’t replace an existing Jira setup. An explicit per-agent Jira configuration takes precedence, and native tickets can escalate to Jira one-way when you want an incident tracked there as well. See Jira Integration.

​
Per-agent control

Ticketing can be toggled per agent under the agent’s Integrations tab, so only the agents you choose open tickets.