A specialist bakery: twelve email threads collapsed into one order channel
A specialist bakery in East Sussex was managing twelve wholesale customers through twelve email threads. The head baker was reading emails at 4am to plan the day's bake.
The reading
A sourdough and viennoiserie bakery supplying twelve independent cafes and two small hotel groups across Sussex and Kent. Nine employees. The head baker was also the owner. Wholesale orders came in by email, each customer with their own habits: some sent weekly standing orders, some ordered the day before, two routinely texted the owner's personal mobile.
The owner began each day at 3.45am by reading the previous evening's emails and texts and compiling the bake sheet by hand. The compilation was the first thing he did and often the slowest. The actual baking, which he enjoyed, started at 4.30.
He had tried a shared Google Sheet. The cafes did not use it. He had tried a WhatsApp group. The hotels did not use it. The emails continued.
Twelve customers, twelve conventions
The owner had, correctly, identified that the customers would not change their behaviour to suit his systems. A cafe in Rye had been emailing orders in the same format for six years and was not going to start logging into a portal. A hotel buyer had a procurement system that only emitted PDFs.
The owner had, less correctly, assumed that the solution had to involve the customers changing something. We thought the solution was for the bakery to change something.
- 12 wholesale customers, 9 email formats, 3 messaging channels
- Daily compilation of bake sheet taking 35-50 min
- Occasional missed orders when emails were deleted in error
- No stock-forecast capability from order history
- No way to flag out-of-stock items proactively
What we built
We pointed a dedicated inbox at a parsing service that read each incoming email, extracted the order lines, and dropped them into a structured queue. The owner opened a web page at 3.45am and saw twelve orders laid out identically. Edge cases, which the parser flagged rather than guessed at, took him a minute each to resolve. The bake sheet generated itself.
The technical choice we are most comfortable with: the parsing was rule-based per customer, not generic. We built a small template for each of the twelve, which took about two hours per customer to tune. The hotel's PDF went through a specific extractor because the layout was consistent. The texts to the personal mobile were forwarded into the same inbox via a simple forwarding rule.
The stack: a Python parsing worker, Postgres queue, a web view the owner used on an iPad in the bakery.
The numbers at ninety days
| What | Before | After |
|---|---|---|
| Bake sheet compilation time | 40 min | 6 min |
| Missed orders per month | 1.5 | 0 |
| Start time for actual baking | 4:30am | 4:00am |
| Order history queryable | No | Yes |
| Out-of-stock warnings to customers | Ad hoc | Automatic |
The system changes, not the customer
The owner's instinct that the customers would not change was correct. The failure of the previous attempts was in asking them to. The bakery changed; the customers continued to email as they always had; the bake sheet appeared on time.
That is the system-first position stated plainly: the firm absorbs the complexity so that the people on both sides of it do not have to. The one-week training test here is almost trivial. A new assistant baker reads the generated sheet. There is no training required.