AI Email Enquiry Triage.
Every customer email read, understood, and checked against the business's real inventory and calendar within seconds. The safe questions get answered on their own. Everything else reaches a person with the summary and the recommended next step already written.
- Email ArrivesStraight into the support inbox
- Pull Live DataCurrent stock and open slots
- AI TriageCategory, urgency, and a real answer
- Safety GateDecides what AI may send
- Human HandoffWith the context already written
It answers what is safe. A person does the rest.
Autonomy here is deliberately narrow. The system only replies on its own when the answer is a verifiable fact it just looked up, never when the answer requires a judgment call.
It reads the enquiry, then checks the actual records.
A generic AI assistant guesses from the wording alone. This one pulls the business's current inventory and calendar into the decision before it says anything, so what it reports is what is genuinely true right now.
Reads the live source
Inventory and appointment availability are pulled fresh on every single enquiry, so nothing is answered from a stale copy or from the model's imagination.
Reports the fact, not a suggestion
When a lookup finds a real answer, the handoff states it outright, for example "Aug 4 has two open slots: 9-11am and 1-3pm". It does not tell the person to go and check.
Tested against how people actually write.
Customers do not send tidy, well-structured tickets. They ramble, they shout, they forget the details, and they reply from a phone at the bottom of a thread. Every case below was a real message put through the live system.
Three asks in one run-on message, with typos
Too vague to act on, almost no detail given
Shouting, but harmless underneath
Four words, no context
Real request buried under a quoted chain
Non-native phrasing, part described by guesswork
Built for a business where a wrong answer costs money.
The hard part of automating customer email is not writing replies. It is being disciplined about the ones that must not be automated.
A complaint passes four checks before AI may answer it
It has to be low urgency, need no technician, match a known routine topic in the knowledge base by genuine similarity search, and come from someone with no complaint already on record. Fail any one of the four and a person takes it, with a holding note going to the customer immediately so nobody sits in silence.
Nothing is ever sent half-formed
Every AI response is validated before it can leave. If the model returns something malformed, the system retries once, and if it still fails, no email is sent at all and a person is alerted instead. A broken message never reaches a customer.
An acknowledgement is not a resolution
When the AI can only acknowledge something rather than settle it, a billing charge it cannot verify for example, it says so honestly and flags the enquiry for real follow-up instead of quietly marking it as handled.
It never invents a fact
The AI is only allowed to state what the customer wrote or what a lookup actually returned. It cannot promise a refund, a discount, a booking, or a date. Those remain human decisions by design.
About this demonstration. This system runs live on real infrastructure, real inbound email, real AI, a real database, and real outbound delivery, but the business it serves is a fictional HVAC company and the inventory, calendar, and knowledge base are synthetic. It was built as a working demonstration of the architecture, not as a live customer service desk, so no real customer data is involved anywhere in it.
What it looks like underneath.
Not a diagram drawn for a slide deck. This is the actual build, colour-grouped by phase, with the reasoning written directly onto the canvas so the next person to open it understands why each branch exists.
Built on boring, replaceable parts.
Nothing here is exotic. Each piece does one job and can be swapped for whatever a business already runs, which is the point: the architecture should outlive any single vendor in it.
n8n
Self-hosted on a private VPS, so the workflow and its data stay on infrastructure I control.
Resend
Receives the inbound enquiry by webhook and delivers every reply the system sends.
OpenRouter
One integration point in front of the language models, so a model can be swapped without touching the build.
DeepSeek V4 Flash
Handles the triage decision and drafts the customer-facing replies, always into a strict output schema.
OpenAI Embeddings
Turns each enquiry into a vector so a complaint can be matched to a known topic by meaning, not keywords.
Supabase
Postgres with vector search holding the FAQ knowledge base, plus the complaint log behind the repeat-customer check.
Google Sheets
Stands in for the inventory and booking systems a real business would already have, read live on every enquiry.
Slack
Where tickets, escalations, and failure alerts land for a person to pick up.
How much of your inbox is answering the same questions?
If your team spends its day checking stock, quoting availability, and re-typing the same acknowledgements, that work can be handed off safely without taking your people out of the decisions that matter.