Building NightDraft - an AI that answers a restaurant's email

NightDraft is a micro-SaaS that reads inbound restaurant booking emails, classifies them, extracts the relevant details, and drafts replies in the restaurant owner's voice. The human is always in the loop - NightDraft puts a draft in the Drafts folder; the owner reads, edits if needed, and sends. The tool has been live at Lorne, a London restaurant, since mid-2026.

This is the build log. Not a polished retrospective - a record of the actual sequence, the wrong turns, and the decisions that turned out to matter.

The starting problem

Restaurant group bookings are high-stakes email. A table of ten for a Friday night is worth a lot of revenue. The enquiries tend to arrive in the evening - after service, when the owner is tired and has fifteen other things to do. A slow reply loses the booking to somewhere that replies faster.

The owner I built this for had a real pattern: enquiries arriving all day, replies competing with an actual restaurant to run. The backlog would pile up, evenings disappeared into the inbox, and occasionally a booking would leak entirely.

The problem felt right for AI. Not because writing the email is hard, but because the bottleneck was attention - she had the knowledge, she had the voice, she just could not be at her desk at 9pm for every enquiry.

Why voice was the hard part

My first instinct was to give the model the booking policy and let it draft. The results were technically correct and completely wrong. The phrasing was generic, the warmth was off, the specific way she handles certain situations - a party that pushes back on the deposit, a request for a vegan menu when the kitchen has one strong dish - was nowhere in the output.

The insight that unlocked it: I was training on the wrong thing. I had access to a large archive of emails she had sent over several years. Some of those were her best work - carefully written, warm, commercially sharp. Training on the whole archive would have averaged that voice down; the playbook had to be built from the best of it.

A naive model trained on everything converges on the lazy average. That is not what you want. What you want is the model to draft like her best emails, not her average ones.

The fix was a canonical playbook - a structured document that encodes her policies, her preferred phrasing for common situations, her voice patterns, and the specific operational guardrails that matter (the phrasing around the deposit ask, for example, is a protection as much as a nicety). The playbook is built from the best emails, not all of them, and it is updated when edge cases reveal a gap.

The architecture

The system is a Python pipeline. A poller reads the bookings inbox every few minutes. Inbound emails go through a triage step that classifies them - enquiry, follow-up, cancellation, junk, and a handful of other categories. A deterministic rules engine applies policy (minimum party size, deposit requirements, private dining availability). A composer then drafts the reply using the playbook and relevant context extracted from the email. A verifier checks the draft for policy compliance, factual consistency, and tone before it lands in Drafts.

The human sees the finished draft. They do not see the pipeline. From the owner's side, it looks like a draft appeared in her drafts folder, already addressed, already correct on the details. She reads it, sometimes makes a small edit, and sends.

The key design decision is the verifier step. It runs a second pass over every draft before it surfaces. It checks that pricing references match current policy, that the date arithmetic is correct, that the warmth level matches what the enquiry warrants. A draft that fails verification is held, not surfaced - the owner only sees things the system trusts.

The go-live moment

The first live draft landed in her drafts folder a few hours after connecting the inbox. Her verdict: it read like a reply she would happily have sent - she could tell she had not written it, and she was happier with it than what she would have dashed off between services. That is the honest pass mark for delegating client email: not impersonation, but drafts good enough that the edit is a glance rather than a rewrite.

The commercial signal came later: two booking enquiries converted to confirmed bookings in quick succession one afternoon while we were both watching. Her read on the second one was that she won it because she replied fast. Speed-to-reply as a competitive advantage in restaurant bookings is real - group enquiries go to whoever answers first.

What the build taught me

The quality gate is more important than the drafting. A system that surfaces a bad draft once loses trust that takes weeks to rebuild. I spent more engineering time on verification than on generation.

Voice matching is a data curation problem as much as a prompting problem. The playbook needs to be built from the right examples, updated when it drifts, and treated as a living document rather than a one-time artefact.

The cold-start problem is solvable without a long onboarding period. Because I had access to historical emails, I could score the first draft against what the restaurant had actually sent in similar situations before going live. That turned the free trial from a training period into a demonstration - the value is there from day one, before the owner has sent a single NightDraft-assisted reply.

And the fundamental thing: the hard part was not getting the AI to write. The hard part was deciding what "good enough to send" means in someone else's voice, for their business, where the margin for error is low because a booking is a commercial transaction, not a casual message.

That question - what good enough to send actually means - turns out to be the right question for a lot of AI-assisted writing. It is what I think about when building anything in this space now.

← Back to Writing