Contact Us

Work / AI Agents / Support Triage

Support Triage Drafts the reply. A person sends it.

Sorts the shared support inbox by topic and urgency, finds the customer, and drafts a reply from your help docs. A person approves every reply. This page shows what it does and how it is built. Every real engagement is fitted to your documents, systems and rules.

Ticket queueSample data
TicketResultWhy
Refund questionDraft readyCites the refund policy passage
Cannot sign inDraft readyCites the account help article
Cancel my planNeeds a personPolicy passage not cited
Unknown senderNeeds a personNo customer matched
The pipeline

How one email travels through it.

An email goes in on the left and stops at "awaiting review". Nothing leaves until a person approves it.

01ReceiveValidate and normalise;once per message02Match customerSender address,then domain03ClassifyTopic, urgency,confidence, reasons04Find evidenceHelp-doc passages;published versions only05DraftReply that cites thepassages it relies on06ValidateCitations, figures, datesand risky promises07A person decidesApprove, edit or rejectevery reply08SendOnly an approvedreply, onceEvery step writes an audit event · the model is used only in steps 3 and 5
Fig. 1
  1. ReceiveThe email is validated and normalised. The same message is never processed twice.
  2. Match the customerBy sender address first, then by domain.
  3. ClassifyTopic, urgency, confidence and the reasons, in a strict schema.
  4. Find evidenceHelp-doc passages for this customer, published versions only, with a minimum relevance.
  5. DraftA reply that names the passages it relies on and lists any point it could not support.
  6. Validate the draftCode checks the citations, figures, dates and risky promises against the cited text.
  7. Review and sendA person approves, edits or rejects. Only an approved reply can be sent.
States

Where a ticket can be, and where it can go next.

The pipeline stops at "awaiting review". Only the approval gate moves a ticket on, and only an approved review can lead to a send.

receivedclassifieddraftedawaiting reviewapprovedrejectedsentfailedEvery state change writes an audit event · a failed send is not retried automatically
Fig. 2
The system

Parts you can replace, and a gate you cannot skip.

Rules and the approval gate are plain code. The model sits behind one interface, so it can be hosted, self-hosted or swapped, and the help docs can be re-embedded when it changes.

EMAILSupport inboxPaste form or mailboxconnectorCODEPipeline and rulesMatch, route, validate;no model decidesPOSTGRES + PGVECTORDatabaseTickets, help-doc passages,reviews, audit eventsNEXT.JSReview screensDraft, evidence andapprove, edit, rejectONE SEAM FOR THE MODELLanguage model interfaceClassify, draft, embed: hosted,self-hosted or offlineOUTBOUNDMailerSends once per review;failures are recordedCODEApproval gateSends only a reply whoselatest review is approvedDashed: the review screens read from the database
Fig. 3
What it does

The parts that do the work.

Grounded drafts

Every draft cites the help-doc passages it came from. A figure, date or phrase like "full refund" must appear in a cited passage, or the draft is refused.

Needs-a-person routing

Unknown customer, no evidence, conflicting versions of a policy, refund or cancellation without the policy cited, critical urgency, low confidence, a suspected prompt injection.

Approval gate

Sending needs the latest review to be approved. A double click or a replay produces one send, not two.

Audit trail

Every step writes an event, so the path from email to reply can be read afterwards.

Rules it keeps

Written down first, then enforced in code.

  • It is not a website chatbot. It works the shared inbox your team already uses.
  • A person approves every reply. The pipeline stops at "awaiting review". The database will not accept a send without a review behind it.
  • The model proposes, code decides. Routing, validation and the approval gate are plain code, not model output.
  • Help docs are data, not instructions. Text inside an email or a document cannot change what the system does.
How it is built

Plain parts, chosen to be swapped.

Next.js and TypeScript · PostgreSQL with pgvector · Drizzle · AI SDK behind a provider-neutral interface

Your data, your decision

Where your data lives, and which model ever sees it, is your decision. We design to it.

Tickets, customer records and help-doc embeddings live in your own PostgreSQL. The classifier and drafting model run behind one interface: a hosted model in the region you choose, or a model you host yourself. Switching means re-embedding the help docs, which we plan for.

  • In your own cloud account, in the region you name.
  • On your own servers, with nothing in our hands.
  • With a language model that runs on your hardware, so no data goes to an AI provider.
  • With a hosted model in a region you approve, under the terms you choose.

Australia

The Privacy Act 1988 and the Australian Privacy Principles. Principle 8 covers sending personal information overseas: the sender stays accountable for how it is handled there. Some sectors and government work require data to stay onshore.

New Zealand

The Privacy Act 2020. Information privacy principle 12 limits disclosing personal information to a body outside New Zealand unless it is protected to a comparable standard or the person has agreed.

European Union

The GDPR. Moving personal data outside the EEA needs a legal basis for the transfer. Hosting and model endpoints inside the EU avoid the question.

United States

No single federal privacy law. State laws such as California’s CCPA, and sector rules such as HIPAA for health and GLBA for finance, decide what applies. Contracts often require US-only processing.

This is a summary to explain how we work, not legal advice. Your own counsel confirms what applies to you, and we build to what they decide. More on the privacy page.