The AI works out the answer,
and then somebody pastes it
into an emailThat copy-and-paste is the thing this system removes
Incoming
Arrives with customer and order context
Outgoing
Triggered by business events
Address count
Not priced per person
System ownership
Yours
What an off-the-shelf inbox can't reach
Three things, and none of them is fixed by a better provider
It doesn't know your orders
A message arrives asking why last week's order hasn't shipped. All an off-the-shelf inbox can do is tag it “support”. Who this customer is, what they bought, where the order stands, what they asked before — it knows none of it, because there's no connection between it and your storefront, your customer records or your tickets.
So a person works with two windows open: one for the message, one for the order.
It can't send what your business triggers
What should reach a customer after a purchase, when a warranty reminder is due, at which step an invoice goes out, how many days of silence before someone follows up — every one of those conditions lives in your business systems, not in an inbox.
Which leaves waiting for a person to press send, or bolting on a marketing tool — and now you have two customer lists that don't know about each other.
It's priced per person, and a process needs many addresses
Support, after-sales, warranty, invoicing, dealers, complaints, one per language market — a dozen or two is normal, and most of them don't correspond to a human being at all. They're entry and exit points of a process.
Per-seat pricing runs the opposite way to automation: the more automated the process, the more addresses it needs, and the higher the bill.
All three say the same thing: email was made into software for people, and what a process needs is a node.
Once it's connected
Four actions that stop being done by hand
By the time it's read, the context is already on the same screen
Incoming mail doesn't sit in an inbox waiting to be noticed. It's classified, prioritised and routed to the right person, and when it's read, who this customer is, what they bought and what they asked before are read alongside it — so what's understood isn't a piece of text, it's this customer's problem with this order. A reply is drafted from your own policies; a person reads it, changes a word, sends.
What should go out doesn't depend on someone remembering
Nobody presses send. Something happens in your business and the message goes: a purchase completes, a shipment goes wrong, a warranty reminder comes due, an invoice is ready, an after-sales case moves to its next step. Each one carries that customer's own data rather than a broadcast template.
Things get pushed along; people appear where judgement is needed
Customers who've gone quiet, warranties near expiry, quotes that went out and never came back — all of it used to rely on someone remembering, and nobody knew what had been missed. Now it moves on rules you set, at a steady cadence, with a person appearing at the step that needs a decision.
The things that need a paper trail go by email
Our processes keep a lot of deliberate human checkpoints, and most of them live in internal messaging. But one category has to be email: anything needing a formal record, anything going outside, anything copied to several people, anything that might have to be produced later. The approval chain and the correspondence both land in your own systems — who approved, when, and what they were looking at is all recoverable.
The same message
After it was wired in, and while it ran on people
Wired into the loop
- ✓When the message arrives, who this customer is and what they bought is already on the same screen
- ✓A reply is drafted; a person reads it, changes a word, and still holds the send button
- ✓Transactional mail is triggered by events in the business, not by someone remembering
- ✓The step that needs a decision comes and finds a person — nobody has to watch an inbox
- ✓One human answer also becomes knowledge, so the same question isn't answered from scratch next time
- ✓Opening another address for a process doesn't add a subscription line
Relayed by people
- ✕One window for the message, another for the order, matched by hand
- ✕The AI works out the answer, and then somebody copies and pastes it into an email
- ✕Notifications depend on someone remembering; when they're missed, the customer notices first
- ✕One list in the marketing tool, another in the inbox, and they don't reconcile
- ✕A question is answered and sinks; the next person asks it and it's answered again
- ✕Every extra address a process needs is another line on the bill
Three rules we don't bend
What stays under your control
The machine doesn't get the send button
Transactional mail — orders, shipping, warranty, invoices — is triggered by events and goes out automatically, because that content is determined. But an individual reply to a specific customer, and anything containing a commitment or a concession, needs a person to confirm before it sends. The system can draft it, translate it and assemble the full context. The last action is a person's.
Identity verification is a required check, not an option
A system that can read every customer exchange you've ever had, without identity verification, is a door left open. The most important lesson from building this ourselves was exactly that: get the features working and add authentication later is the most common and most dangerous order for an internal system — “later” turns into “after it went live” very easily. It's now a required pre-delivery check in our deployment standard, and that standard is handed over with the system.
Knowledge enters only with a human nod
New questions that surface in email, and how a person actually answered them, go into a review queue and take effect only once confirmed. No unattended writes — that contaminates the knowledge base with wrong answers, and afterwards nobody can say when it started.
When this doesn't apply
Three cases where we'd tell you not to
Email here is just people writing to people
Nothing upstream or downstream to connect, no follow-on action to trigger — an off-the-shelf inbox is already enough. Bringing it in would add something to maintain without removing a single action.
You want large-scale marketing sends
Purchased lists and broadcast marketing delivery aren't something we do. What this system sends is triggered by business events and carries that customer's own data. Different thing entirely.
The rules aren't settled yet
How mail should be classified, what must always go to a person, what may send automatically — someone has to be able to decide those. Connecting it before the rules are settled just moves the uncertainty somewhere else.
Where this connects
It's one node, so it only pays off next to the others
The support side of it
Classification, drafted replies and the knowledge behind them are the same machinery that answers customers on a storefront — the mail system is where those answers leave the building.
The knowledge behind the replies
Drafts are only as good as what they're drawn from. One knowledge base means the reply, the article and the internal answer all say the same thing.
Start with one flow
You don't need the whole system to get value. Triage and routing, or drafted replies, work as a single module with the interfaces left open.
Questions
What people ask about this one
01Why not just use a normal business inbox?+
For correspondence between people, you should — we'd say so. The reason this exists is different: the moment email becomes a step in a process rather than a conversation, an off-the-shelf client can't reach the thing that matters. It doesn't know the order, it can't be triggered by your business, and it charges per person while a process needs many addresses. None of those are fixed by choosing a better provider.
02Isn't running your own mail infrastructure a maintenance burden?+
It's real work, which is why it only makes sense when email is load-bearing in your process. What's delivered includes the deployment standard, the runbook and the monitoring, and day-to-day operation is ordinary system administration your own people can carry. If email isn't load-bearing for you, the honest answer is that this isn't worth it — that's why the section above exists.
03Who can read our correspondence?+
It runs inside your own infrastructure, so the mail, the records and the logs stay within your boundary. We don't operate it for you and we don't keep a back-door account; after handover we have no access, and you grant temporary permission if you want help. Where a model is involved in drafting a reply, which step that is and what it would send is listed in the proposal and can be rejected line by line.
04Does the system send things on its own?+
Only in one category. Transactional mail — orders, shipping, warranty, invoices — is triggered by events, because that content is determined. An individual reply to a specific customer, and anything carrying a commitment or a concession, waits for a person. That split is deliberate and configurable, not a stage we're working to eliminate.
05Will it improve our deliverability?+
We don't promise inbox placement or delivery rates, and nobody honestly can — that depends on your sending history, your domain and receiving providers' own judgement. What the delivery standard does cover is the technical hygiene that avoids obvious problems. If someone guarantees you a deliverability figure, ask them how.
06Can it work alongside the mailboxes we already have?+
Yes, and that's the normal starting point. Process-facing addresses can be brought in first while personal mailboxes stay where they are; how far to go is decided during the diagnostic rather than assumed.
07Does adding a new flow later cost extra?+
Yes, and it's written into the contract at signing rather than raised mid-project. Day-to-day maintenance — routing rules, wording, templates, adding an address, routine checks and incident response — your own technical people can carry, or you can buy an annual maintenance subscription. A new triggered flow, or connecting a new business system, is new development and is scoped and priced as a new project.
Next