Case Study Breakdown
Teardown: the inbox that drafts itself
What building the Founder Inbox OS for Freckleberry actually taught us — why the noise filter is plain rules, why triage runs on one golden rule, and why the draft, not the send, is the product.
DashboardLim · Systems desk
2026-06-247 min readTL;DR
Filter with boring rules first — 81 noise messages dropped in a single day never reached the AI, and every drop was logged.
Give the model one golden rule, not judgement — a question inside a notification is a flag; no question is a drop.
The draft is the product — every reply waits in Drafts marked [AI DRAFT] until a person sends it.
The case study for the Founder Inbox OS covers the architecture: seven mailboxes plus WhatsApp, Meta and Shopify Inbox, one triage layer, human-approved drafts. This issue is the other story — what we learned building it for Freckleberry, a family chocolate factory, and what we'd tell anyone about to automate an inbox. One truth up front: this system drafts, routes and escalates. People send.
Start with the mess, not the model
The discovery numbers were ordinary, and that was the problem. Around 50 customer emails a day in peak season, 10 to 15 direct messages across Shopify and Meta, spread across seven mailboxes and three messaging channels. Nothing converged anywhere except on the team — one person was clearing the backlog between 8pm and 1am.
The first lesson of inbox automation is that the pain is rarely volume. It's attention. Every message, important or not, cost someone a look. So the design goal was never "answer email faster" — it was to make sure a human only ever sees the messages that deserve a human.
The cheapest AI is the AI you never run
The obvious move is to point a model at the inbox and let it sort. We did the opposite. A pre-filter of plain rules — blocklists, allow-lists, pattern matches the client edits themselves from a dashboard — drops newsletters, noreply notifications and system mail before the AI sees anything. On 16 June it removed 81 messages in a single day, each one logged with its reason. Nothing disappears silently.
That decision made everything downstream cheaper and sharper. The triage model only ever reasons over messages a person would actually care about, and the client can tune the noise floor without touching a prompt or calling us.
One golden rule beats a clever prompt
Triage classifies every surviving message FLAG or DROP under a rule the founder already carried in her head — an order or booking notification with a customer question inside is a flag; the same notification with no question is a drop. Read the body, not the subject line. Read the whole thread, not the latest message.
That last clause was learned the hard way. An early version read only the newest message in a thread and politely re-asked questions the customer had already answered. The fix wasn't a smarter model — it was a sharper rule. This is the pattern that held up across the whole build: the judgement belongs to the founder, written down as rules; the model's job is enforcing them consistently at a scale one person can't.
Keep the model away from money
Drafting replies is where AI genuinely earns its place — a decent first draft, in the brand's voice, is exactly what a model is good at. But we also found its edges fast. It guessed at product pricing on quotes. It once quoted a school discount that didn't exist. The response wasn't better prompting: pricing was removed from every AI reply, and drafts now link to the website instead of quoting numbers.
Anything touching money, legal or safety never reaches the drafter at all. Chargebacks, legal threats, tax-office correspondence, refunds over $100 — a deterministic keyword matrix catches them and pings a named human on WhatsApp immediately. Where being wrong is expensive, rules win. Where being slow is the enemy, the model wins. The skill is knowing which messages are which.
The draft is the product
The deliverable was never an empty inbox. It's a drafted reply waiting in each mailbox's own Drafts folder, prefixed [AI DRAFT], never sent. The team reviews, edits what needs editing and presses send themselves. The first live week was deliberately small — a little over 50 messages processed, about ten drafts — because trust is the actual feature, and trust is earned draft by draft.
There's a graduation path, and it's strict on purpose. A category of reply earns auto-send only after shadow mode shows at least 95% of drafts going out unedited for two straight weeks, with sign-off, a capped canary and a per-category kill switch. Some categories never graduate at all: money, legal, dietary-critical, complaints. Auto-send is something the system has to earn, one category at a time — and as of this writing, it hasn't. Everything still waits for a person.
What broke, and what changed
The honest list is long. The model sometimes answered in prose instead of structured data, which silently broke downstream steps — now it returns strict JSON, and a malformed reply surfaces as zero confidence instead of slipping through. A spam subject containing the right keyword got flagged urgent at 99% confidence. Enquiries forwarded between internal mailboxes were dropped as noise until the rules learned what a forward looks like. An escalation rule treated any mention of compensation as a legal threat until real support tickets taught it otherwise.
The founder co-trains the system. She returned a corrected 15-question FAQ set that shipped the same day, sends video feedback on drafts, and her staff forward automatable emails as examples. An inbox system isn't a launch, it's a weekly tuning loop — the workflows that survive are the ones built to be edited.
What the system actually guarantees
Strip away the stack and the guarantees are plain. Nothing sends itself. Nothing disappears silently — every filtered message is logged with its reason. Anything touching money, legal or safety reaches a human fast, not eventually. And a ranked morning digest tells the founder what arrived, what was drafted and what still needs her.
That's the real shape of inbox automation done honestly. Not an AI running the inbox — a system that absorbs the attention overhead so the people keeping final approval can spend it where it counts.
The proof behind this issue
The full case study — the architecture, the message flow and the honest outcomes — is on the proof feed.
Case study
· Inbox automation
Founder Inbox OS
Seven inboxes and customer channels were feeding one overloaded team. We built a human-reviewed system that sorts every message, drafts the next reply and escalates anything that needs judgement.
7
mailboxes triaged
81
noise messages filtered in one morning
0
replies sent without human approval
Freckleberry
2026-06-18OpenClawn8nRailwayRead the case study →Get the next issue in your inbox
Real systems we've shipped, with practical lessons you can use today.
Keep reading
Founder Brief
· Newsletter
Three systems to install before Q3 planning
The Founder Brief #001 — the three operating systems we install first at every client, and the order that makes each one cheaper than the last.
DashboardLim
2026-07-014 min readRead the issue →Client Success Roundup
· Newsletter
Q2 roundup: what shipped, what it moved
The quarter in shipped systems — marketing automation, creative pipelines and forecast dashboards, with the numbers each one moved.
DashboardLim
2026-05-285 min readRead the issue →Sales automation
· Sales
AI Sales Call Memory
Every recorded sales call is transcribed, classified, summarised and pushed to the CRM with a human approval gate — three call sources unified into one AI memory.
DashboardLim
2026-06-05Read the case study →