- Reply lands on the sending platformWebhook fires once. It is never resent.A lost interested reply is a lost deal, and there is no error to notice. The failure is the absence of an event, which nothing alerts on.
- Client identificationLookup against a client-mapping table on the sending domainRouting is data, not code. Onboarding a client is adding a row, so there is no per-client copy of the workflow drifting out of sync with its siblings.
- Intent classificationFour categories, temperature 0.1 — consistency over varietyA sorting task where the same reply must always land in the same bucket. Variety is not a virtue here, so the temperature is set near zero.
- Route, forward and persistFull reply text, classification, campaign and destination all writtenThis is what makes the reporting question answerable at all, and the audit trail if a routing decision is ever challenged.
On failureEvery node routes its errors to a failure queue that retains the entire original payload, so any failure is replayable rather than lost.
An outbound operation run on behalf of several end clients has a structural bottleneck. Every reply arrives in the operator’s tooling, not the client’s. Somebody has to read it, decide whether it is a live opportunity or a hard no, work out which client’s campaign it belonged to, and forward it to the right person — fast enough that a warm prospect does not cool off.
Two failure modes follow, and both are unrecoverable. Replies sit unread while the team is doing something else: a prospect who said yes on Monday and heard nothing until Thursday is a lost deal. And replies get routed to the wrong client, which in this sector is a confidentiality problem rather than an inconvenience.
The manual process also produced no data. Nobody could answer how many interested replies did this client get last month without counting emails by hand.
What was built
A reply-handling service sitting between the sending platform and the client’s inbox. It receives every reply the moment it lands, resolves ownership, classifies intent, routes it, and records it.
The client’s own inbox stays the interface. Interested prospects arrive as forwarded email and the client replies directly to the prospect from there. Nothing about their workflow changes; the triage layer is invisible to them.
Routing is data, not code. Ownership is resolved by looking the sending address up in a mapping table. Onboarding a new client is adding a row — not editing a workflow, and not copying an automation that then drifts out of sync with its siblings.
Classification is deliberately narrow. Four categories, at temperature 0.1, because this is a sorting task where the same reply should always land in the same bucket. Variety is not a virtue here.
Declines are recorded but not forwarded. The client’s inbox stays signal rather than volume. Everything is still written down, so the reporting question remains answerable.
The decision that matters most
Every node has an explicit failure path, and the failure queue retains the entire original payload.
The reason is specific. If a downstream API rate-limits or has an incident, the naive outcome is that the reply is simply gone — the webhook fired once, the workflow died, and the platform will not send it again. A lost interested reply is a lost deal, and nobody would know it happened. There is no error to notice, because the error was the absence of an event.
Retaining the payload makes every failure replayable. The queue carries a status field — pending, retried, resolved, abandoned — so failures get worked rather than accumulating into a table nobody opens.
That is the difference between an automation and a system somebody’s revenue can depend on.
What is not claimed
No accuracy figure for the classifier, because no evaluation set was built. No volume or outcome numbers, because they were never agreed for publication. The system ran in production against live campaigns, classifying and routing replies from named prospects at CEO level, with every reply logged and every failure recoverable. That is the whole of the claim.
Failure modes
Client identification used a substring match on the sending address, which can resolve to the wrong client where addresses share a stem. When the lookup failed outright it fell back to a hardcoded mailbox and forwarded the reply there anyway — a routing failure that produced a delivery rather than an error. In an operation where misrouting a reply is a confidentiality problem, a silent wrong-recipient path is the most serious defect in the build. No accuracy figure is claimed for the classifier: no evaluation set was built, so there is no number and no adjective standing in for one.
Sources and methodology
- Scope
- A production client-engagement architecture reconstructed without client identifiers or vendor names. No classifier accuracy, campaign volume or commercial outcome is claimed because no publishable evaluation set was retained.
- How this was produced
- Reconstructed from the deployed workflow structure and retained implementation artefacts. The architecture, operating decisions, observed defect and absence of evaluation evidence are reported separately.
Read the editorial standards, corrections policy and AI-use disclosure.