diff --git a/docs.json b/docs.json
index c0d1f46..c7575e3 100644
--- a/docs.json
+++ b/docs.json
@@ -29,6 +29,7 @@
"features/workflow-builder",
"features/knowledge-base",
"features/help-center",
+ "features/ai-ticketing",
"features/mcp-tools",
"features/testing",
"features/widget",
diff --git a/features/ai-ticketing.mdx b/features/ai-ticketing.mdx
new file mode 100644
index 0000000..3e12d03
--- /dev/null
+++ b/features/ai-ticketing.mdx
@@ -0,0 +1,161 @@
+---
+title: 'AI Ticketing'
+description: 'AI-first support tickets that auto-triage, investigate your logs and databases, and document a root cause with cited evidence — under staged autonomy you control.'
+---
+
+# 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
+
+
+
+ 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.
+
+
+ An agent raises one from the Tickets workspace or straight from a conversation, with an
+ AI-drafted title and description.
+
+
+ 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.
+
+
+ 
+
+
+
+
+ The AI triages, investigates and documents. Every customer message and status change is a human action.
+
+
+ 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.
+
+
+ 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](/features/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.
diff --git a/images/ai-ticketing-autonomy.jpg b/images/ai-ticketing-autonomy.jpg
new file mode 100644
index 0000000..ebd3eb3
Binary files /dev/null and b/images/ai-ticketing-autonomy.jpg differ
diff --git a/images/ai-ticketing-connectors.jpg b/images/ai-ticketing-connectors.jpg
new file mode 100644
index 0000000..4e33a94
Binary files /dev/null and b/images/ai-ticketing-connectors.jpg differ
diff --git a/images/ai-ticketing-database.jpg b/images/ai-ticketing-database.jpg
new file mode 100644
index 0000000..cc6ff04
Binary files /dev/null and b/images/ai-ticketing-database.jpg differ
diff --git a/images/ai-ticketing-investigation.jpg b/images/ai-ticketing-investigation.jpg
new file mode 100644
index 0000000..179a76f
Binary files /dev/null and b/images/ai-ticketing-investigation.jpg differ
diff --git a/images/ai-ticketing-workspace.jpg b/images/ai-ticketing-workspace.jpg
new file mode 100644
index 0000000..173e89d
Binary files /dev/null and b/images/ai-ticketing-workspace.jpg differ