Hyper Personalized Event Emails
The program plan behind the end of day one emails at the Melbourne Infinite Leverage retreat, written on the 5D framework. Sixty attendees, one evening, sixty different emails, each one built from what that person said that day: their win, their struggle, their goal for tomorrow, and where they actually got to. Claude drafted every one by hand from a data card; the host approved the voice and read the review; a script sent them in under an hour.
Their words, never your data. And never invent a word.
An email that quotes what someone wrote that afternoon feels like a person noticed. An email that says “the survey shows” feels like a system looked them up. And one fabricated detail undoes every true email around it. If the data for a paragraph is missing, the paragraph is dropped.
Define the problem
The end of day one at a two-day build event is the moment people decide whether to come back fully, or just turn up. They are tired. Some built more than they thought they could. Some are quietly behind and embarrassed about it. A single “great day everyone, see you at 9” lands the same on all of them, which means it lands on none of them. “Hi {first_name}” is not the answer either; that is a mass email that knows your name.
Who needs what
- The person who is behind needs a specific offer, not a vague one: come at 8:30, an engineer will sit with you
- The person who finished needs to hear it was noticed, and what to bring tomorrow
- The person who is lost needs to hear it is normal, and which hour of tomorrow answers it
The goal
- Every attendee gets an email in the host's voice within the hour after the reflection closes
- Every email is built only from what that person wrote or did; zero invented claims
- Everyone behind or blocked is named to the team, so the promise in the email is kept in the room
Discover the data
Every signal already existed in the company OS before a word was written. The event hub collects them as surveys, so the reflection, the check-in and the kickoff are rows in the same two tables, joined to one person by email.
| Source | What it gives you | How strong it is |
|---|---|---|
| End of day reflection | What went well, what they struggled with, one thing they want tomorrow. Three short free-text answers. | The best. In their own words, that day. |
| Block check-in | The block they reached, and when they clicked it. | Good, but it lags. People forget to click. |
| Kickoff survey | Organisation, role, a confidence score out of five, and the business pain they came to solve. | Why they came. Days old by now. |
| Stack setup check | Whether their tools were ever fully working before the event. | Only matters for people who stalled early. |
| The host's past emails | The voice: how they open, how long they run, how they sign off. | Essential. Without it the drafts are accurate and cold. |
Goal and pain are different things
- The goal is what they want from tomorrow. Learning.
- The pain is why they came. Business.
- The goal wins when it exists. The pain is the bridge beyond the event: “the agent you build tomorrow is the first piece of that”
Count the rows before you trust them
- The first pull said 7 reflections. The database held 31.
- The query returned 1,000 answers at a time and the script read the first page only
- The host caught it because he knew the room. Check the pull against the database every time
Design the workflow
Four questions about each person become four short paragraphs. Each paragraph has a source and a fallback. If both are missing, the paragraph is dropped.
| Question | Source | Fallback | Becomes |
|---|---|---|---|
| What went well | Reflection, question 1 | Their progress (“you got the full system built”) | The opener: their win, in their words |
| Their challenge | Reflection, question 2 | A low confidence score from kickoff | Reassurance, then the specific help |
| Their goal for tomorrow | Reflection, question 3 | Kickoff pain point | The hook: which part of tomorrow delivers it |
| Where they are | Block check-in | Say nothing about progress | Sets the tone, and whether they get the early offer |
The help map
Before drafting, read every reflection once and sort the struggles and goals into themes. For each theme, decide exactly what tomorrow offers, so the email can say something true and specific instead of “we will cover that”. From the Melbourne room:
| What they said | How many | What tomorrow offers |
|---|---|---|
| “I don't understand what's going on in the background”, tech speak, the steps | 15 of 31 | The morning session where a senior engineer's review reads their code back to them in plain English. Plus one tip: ask Claude to explain it like you run a business. |
| “My own planning”, “what to build”, “I'd have to restructure everything” | 3 | Ten minutes with the host or an engineer at 8:30, before the room starts. |
| A specific technical blocker: DNS, a domain move, a database link, a git conflict, a slow laptop | 5 | Named: “come at 8:30, an engineer will sort it with you”. The team got the list. |
| Leads, follow-up, retention, conversion, quoting | 5 | The 11:00 block on automated nurture emails. |
| Operations, planning, SOPs, rostering, reporting, estimating, “agents” | 8 | The afternoon block on agents. |
| Real data, integrations, a job management API, legacy platforms | 6 | Honest: that is the take-home step. Bring the API key or an export and we will point the agent at it. |
| “Where to start”, AI strategy, organising projects | 4 | The method they ran today is the strategy. Name it. |
| “Nothing”, “N/A”, “I'm here for fun” | 5 | Drop the paragraph. |
Progress sets the tone and the offer
| Check-in | Means | Tone | Offer |
|---|---|---|---|
| Finished the day | Every block done | Congratulate, peer tone | The fast-track group tomorrow; bring real data |
| Nearly there | Full system built, last block open | On track, warm | “Finish that first thing and you're with the pack” |
| Behind | Halfway | Reassuring, no pressure | 8:30 with an engineer, and which prompt to paste |
| Way behind | Planning only | Honest, personal | A direct 8:30 invitation from the host |
| No check-in | Unknown | Say nothing about progress | “Let us know where you got to when you arrive” |
Always “looks like you got to”, because people forget to click. If the reflection contradicts the check-in (someone marked at planning who wrote “I built a CRM!”), the reflection wins and progress goes unmentioned.
When data is missing
Nobody fills in everything. In Melbourne, 31 of 60 wrote a reflection, 50 did the kickoff survey, 57 had a check-in. Five shapes, each with its rule decided before drafting, so nothing is improvised in the moment. Empty answers (“N/A”, “nothing”, a blank) count as missing.
| Data shape | Count | What they get |
|---|---|---|
| Reflection, survey and progress | 26 | The full four-paragraph email |
| Survey and progress, no reflection | 20 | Opener from progress, hook from the pain point, tomorrow’s block, the early offer if behind |
| Reflection and progress, no survey | 5 | The full email. Nothing is lost; the reflection is the richer source |
| Progress only | 6 | Three lines: what they built, what tomorrow brings, the early offer if behind. Still personal, because it names where they got to |
| Survey only, no check-in | 3 | Pain point hook, no claim about progress, “tell us where you got to when you arrive” |
The flow
Three human decisions, the rest is Claude and a script. The host picks the moment, approves the voice, and reads the review. Nobody writes sixty emails by hand.
How each step works
One script joins the reflection, the check-in, the kickoff survey and the people table by email into one JSON file, one card per attendee. It pages through every result, because the database returns a thousand rows at a time and the first version silently dropped most of the reflections. It prints the counts so they can be checked against the database before anyone drafts.
Dedupe by email. Remove staff. Check any address that looks mistyped against the last send log (two people had typed their email differently on two forms; the earlier log was the source of truth). Flag anyone with two check-ins under one name, a cohort mismatch, or a reflection that contradicts their check-in. Those go on the hold list, not out the door.
Every struggle and goal sorted into themes, and for each theme, exactly what tomorrow offers: which hour, which block, which person. This is the step that makes the emails specific. It also produces the staff list: everyone who will be promised help, and what each one needs.
One draft from each data shape, rewritten until the host says “that sounds like me”. The first attempt in Melbourne was accurate and cold; the fix was a list of rules taken from the host's own past emails:
- Thanks or a win first. One honest reaction before any advice.
- Their words, never your data. Quote the reflection; never “the survey shows”.
- One concrete thing, from you. A specific next step, not a recap of the agenda.
- The host's shape: three short paragraphs, one logistics line, first name sign-off. Plain text.
- No pretending. If they wrote “nothing”, do not build a paragraph on it.
- Under 120 words. It is read on a phone, in bed, after a long day.
Every email written by hand from its card, against the four-sentence shape, the help map and the voice rules. No templates for anyone with a reflection. One shared three-line shape only for the people with progress and nothing else. Each draft carries the recipient, a segment name for the review, and an optional hold flag with a reason.
A dry run checks every draft: a real address, a greeting, no template left unrendered, no duplicate recipient, no dash characters. It writes a review file grouped by data shape so the thin ones get read hardest. Then one call per recipient through the transactional email service, in sequence to respect the rate limit, with every result appended to the log.
One email to the staff: three pointers drawn from what the room said (explain, don't just fix; be on the floor at 8:30, lowest block first; make them pick one process before the agent block), then the list of everyone who was promised help and what each needs. The personal emails made promises. The team email is how they get kept.
The seven elements
Every workflow we document has the same anatomy: seven elements, each assigned to a human, a machine, or both. This is the Centaur Map from our workflow design method.
The host says go, the evening of day one, once the reflection form has been open for an hour or two. Nothing starts on a schedule; the host decides it is time.
The day one reflection, the block check-in, the kickoff survey and the people table, joined by email into one card per attendee. Plus the host’s own past emails, for the voice.
Claude decides which paragraphs each person gets, from the data shape, and which part of tomorrow answers each struggle and goal, from the help map. The host decides the voice, approves three examples, and reads the review before anything sends.
Richest data first. Anyone behind or blocked gets the early offer. Anyone with suspect data goes on the hold list instead of out the door. Staff are split off into their own briefing.
One plain-text email per attendee, under 120 words, in the host’s name. One briefing to the team with three pointers and the list of people who were promised help.
A send script validates every draft, writes a review file, then makes one call per recipient through the transactional email service, sequentially, and appends a log.
The log says what was sent. The room says whether it worked: who turned up at 8:30, who replied, and whether the people who were behind caught up by the first break.
Determine the ROI
What it costs
- About an hour of wall-clock time on the evening, most of it Claude drafting while the host does something else
- Ten minutes of the host's attention: three drafts to approve, one review file to skim
- A few dollars of tokens and sixty transactional sends
- Written by hand, sixty emails at five minutes each is five hours the host does not have at 7 pm
What it returns
- Fifteen people who were behind or blocked got a specific offer with a time and a person, instead of hoping someone would notice
- The team walked in knowing who needs what, so the 8:30 half hour is spent fixing, not finding out
- Thirty-one people saw their own words quoted back by the host the same evening, which is the difference between a cohort and a mailing list
- The honest measure is tomorrow: who comes at 8:30, who replies, and whether the four at planning are live by the first break
Deploy, and the definition of done
The runtime is deliberately small: one pull script, one drafts module per send, one send script, and the company OS as the only source of truth. It runs from the host's laptop in Claude Code, which is where the host already is.
| Piece | Role in the system |
|---|---|
| Company OS | The surveys, answers and people tables. Every signal is already there because the event hub writes it there. |
| Pull script | Joins everything by email into one card per attendee, pages through every row, prints the counts. |
| Drafts module | One file per send, in the repo, with every email as data: recipient, segment, hold flag, subject, body. Reviewable, diffable, and the record of what was said. |
| Send script | Dry run by default. Validates, writes the review, and only sends with an explicit flag. Supports a test send to one address and a single-recipient send. |
| Transactional email | One call per recipient from the host's own address, reply-to the host, plain text. |
| Claude Code | Reads the cards, builds the help map, drafts every email, writes the team briefing. |
Guardrails, always on
- Nothing sends without the host's go, and never before the review file exists
- No paragraph without a source. A missing answer drops the paragraph; it is never filled in
- Progress is always “looks like”, and the reflection overrides the check-in
- Suspect data holds the email, it does not guess the email
- Staff never get the attendee email, and attendees never see another attendee's words
Definition of done
- Every attendee in the cohort has exactly one email in the send log, or a hold with a reason
- The pull counts match the database counts for reflections, check-ins and surveys
- Three drafts were approved by the host before the rest were written
- The review file exists and was read before the send flag was used
- The team has the list of everyone who was promised help, before they go to bed
- It all went out the same evening. The reflection is fresh at 7 pm and stale by breakfast