"It's not letting me send."
Seven people typed some version of that into our dashboard chat in one week. Not one of them clicked the "Report an issue" link at the bottom of the page.
So we deleted the form and taught the chat assistant to file the ticket.
Here's the one rule that made it work: the model never picks the severity. It reports yes-or-no facts, and plain server code turns those facts into a rating. The full install prompt is in our prompt library: AI-driven support ticketing prompt.
Why the model doesn't get a vote
The first version let the model weigh how frustrated the user sounded. It turned out the loudest user rarely had the worst bug.
Now the assistant fills in five yes-or-no fields: blocking, workaround exists, affects money, affects data, affects security. The server scores them in order:
Security → P1, always.
Money or data → at least P2.
Blocking with no workaround → at least P2.
Blocking with a workaround → at least P3.
Everything else → P4.
A later rule can raise a ticket's level, but nothing lowers it. Frustration still gets logged as context. It just can't move the rating.
The math on one bad deploy
Say a deploy breaks the send button and 40 users hit it. Without deduplication, that's 40 tickets, and 100% of your queue is the same bug. Fingerprint matching (same product area, same page, symptom text stripped of numbers and names) turns it into 1 ticket with 40 occurrences. That's 97.5% fewer rows to read. Auto-escalation bumps it a level once 3 distinct users hit it (7.5% of them) and again at 8 (20%). So a P4 lands in front of you as a P2.
What you actually watch is the occurrence count, not the label.
The rule we learned the hard way
Our matcher started out too eager. It merged two different failures on the same page into one ticket, and a real bug sat hidden inside another ticket for about a week.
So the rule is simple: when unsure, create a new ticket. A duplicate costs 30 seconds to merge by hand. A wrong merge buries a bug where you'll never see it.
Merges also never overwrite the original report. They add an occurrence record, because the fifth report is often the one with the detail you need to reproduce the bug.
How the assistant behaves
Try to help first. If it's user error or known behavior, answer it and file nothing.
Ask at most two questions: what were you trying to do, and what happened instead?
Show a one-line summary of the ticket and get a yes before filing it.
Give the user the ticket ID. If the report merged into an existing ticket, say "a few others hit this too, it's already flagged."
Never promise a fix date.
The security part nobody does
Someone once pasted a full application into chat while describing a problem, and it went into a ticket word for word. Scrub personal data before anything gets saved.
Treat everything a user types as untrusted input. Prompt injection is number one on OWASP's Top 10 for LLM applications. Keep API keys on the server, never in your front-end code.
Install it
Open the ticketing prompt and paste it into Claude Code or Cursor inside your project.
Answer its setup questions: your product areas, your database, and where your admin panel lives.
Put every business-specific value in one config file, so the next install is copy, edit, deploy.
Test with three fake complaints, two of them describing the same bug. You should end up with one ticket showing two occurrences.
No chat widget yet? Start with the support chat widget prompt. Next in the series: turn a working feature into a one-file kit.
