AI Ticket Triage

AI Reply Drafting for Support

The slowest part of answering a ticket is the blank reply box. Drafting removes it: the agent opens a ticket and finds a reply already written, grounded in your documentation and this customer's actual situation, and edits it.

Discuss your project

Why we draft rather than send

A support reply is a statement by your company. It can commit you to a refund, state a policy, or tell a customer something about their account. The asymmetry is stark: a draft an agent discards costs a few seconds, and one confidently wrong reply sent automatically to the wrong customer can cost a relationship, or occasionally a regulatory problem.

So our default is draft-and-approve, and we will argue for it if you ask for full automation. The time saving is in the writing, not in removing the human, and in practice the writing is most of the work. An agent reading and sending a good draft handles a ticket in a fraction of the time, and still catches the one in thirty that is wrong.

There is a narrow exception worth scoping explicitly: genuinely mechanical requests where the answer is a fact your systems hold and there is no judgement involved — an order status, a copy of an invoice, a password reset link. Those are defensible to automate fully, and we would define them as a short explicit list rather than letting automation expand quietly.

What makes a draft usable

Grounded in your content

Written from your help documentation and your own resolved tickets, not from the model's general knowledge. A draft citing a refund policy you do not have is worse than no draft.

Specific to this customer

Their order, their plan, their actual delivery date, pulled from your systems. Generic drafts get rewritten from scratch and save nobody anything.

In your tone

Learned from how your team actually writes rather than from a style guide nobody follows. If your support voice is brief and plain, drafts should be brief and plain.

Honest about uncertainty

Where the documentation does not cover the question, the draft says so to the agent rather than inventing an answer that reads confidently.

Showing its sources

Each claim linked to the article or past ticket it came from, so the agent can verify in a click instead of trusting it.

Editable, obviously

Delivered as a draft or internal note in your helpdesk, not as a suggestion in a separate panel the agent has to copy from.

Categories we exclude from drafting

By rule, agreed with you, and never drafted against — because a plausible draft on these is a liability rather than a help.

  • Complaints and anything indicating a customer intends to escalate.
  • Legal threats, regulatory complaints, and data subject requests.
  • Security reports and suspected account compromise.
  • Cancellations and retention conversations, which are commercial decisions.
  • Anything with a medical, financial-advice or safety dimension.
  • Press and analyst enquiries.
  • Distressed customers, where the right response is a person rather than a fast one.

Common questions

Tell us what you need

Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.

Get in touch