The problem
A platform serving thousands of parent accounts across dozens of nurseries receives questions all day, and they arrive on whatever channel the sender already uses: email, WhatsApp, SMS, voice notes, and photographs of documents. Not on a support portal, because nobody installs a support portal to ask what time the crèche opens.
Most of that volume is tier 1: how do I do this, where do I find that, what does this screen mean. Individually trivial, collectively a full-time job, and much of it arrives outside office hours when there is nobody to answer at all.
The rest is tier 2: questions that touch a specific contract, a specific invoice, a specific child’s record. Those need a human, and a human needs the answer to be right.
What we did
Weiwei, an n8n-orchestrated agent sitting across every inbound channel, working at two tiers with two different jobs.
Tier 1 — it answers. Product functionality, navigation, opening calendars, how-to. Multimodal by necessity rather than ambition: a parent photographs a document and sends it on WhatsApp, and that has to work as well as a typed email. Twilio carries the messaging, Claude does the reasoning.
Tier 2 — it stops answering and assists. This is the more interesting half. When a query needs a human, Weiwei does not simply hand over a transcript. It works for the support team, with direct access to the platform’s data through MCP, assembling the relevant contract, attendance and invoice context and proposing the best answer, so they reply faster and get it right first time.
The team stays accountable for what goes out. Weiwei makes them quicker.
What it delivers
Measured over 80 support requests read in full, 75 of them representative once test filings and duplicates are set aside:
| Where requests go | ||
|---|---|---|
| Tier 1 — answered end-to-end by Weiwei | 20 | 27% |
| Tier 2 — human support | 49 | 65% |
| Feature/template change requests | 6 | 8% |
Tier-1 accuracy: 85% — 17 of 20 correct.
All three errors were the same failure, which is more useful than three unrelated ones. On how-to and advisory questions it was 17 out of 17. The misses were all premature bug-labelling: ordinary or working-as-designed behaviour written up as a confirmed “Bug / High”, one of them escalating scope before anything had been checked. Every one was walked back to “working as designed” on review. So the weakness is not in answering — it is in classifying, and the fix is a guardrail rather than a better model: describe the symptom, do not assert a bug or a priority, let triage decide.
Responsiveness: same-day first contact (median 0 days), and 1–2 days to resolve once client-response and external-cycle waits are excluded. The raw average of ~7 days is inflated entirely by a handful of requests sitting idle on someone else, the longest waited months for a client reply on a fix already shipped, another needed a full billing cycle to verify end to end. That is not handling time.
What the recovered time is actually for. The point was never deflection. One in four requests never reaching a person means the team has time to talk to clients about things that matter — work only a person can do, and the first thing to disappear when a queue grows.
What made it hard
The two tiers need opposite dispositions, from one system.
At tier 1 it must be conservative to the point of unhelpfulness at the boundary: this is a platform holding children’s records, contracts and invoices, and a confident wrong answer about a medical document or a billing period does real damage. Nothing goes out unless it is grounded in the tenant’s actual data, and anything near the edge escalates.
At tier 2 it can be expansive: draft freely, surface everything possibly relevant, propose wording, precisely because a human validates before anything reaches a family.
Building one agent with two risk postures, and making the switch between them legible to the people relying on it, was the design problem. Not the language model.