Founder of Erudience. Head of AI at Absolute Intelligence UK. Ships production n8n and voice AI systems for UK and international teams.
A reliable AI email follow up system separates leads, contacts, conversations, messages, and events into five distinct tables, rather than storing everything as flat email records. This lets the system track the full back and forth history per contact, summarize long threads on demand, and know exactly when to send an automated follow up versus hand off to a human, without losing context as conversations grow.
Following up with inbound leads by email consistently, at scale, without losing the context of ongoing conversations, is hard to do manually across many leads at once. It is also hard to automate badly: most 'AI email follow up' systems fail not on the writing, but on losing track of what has already been said in a thread.
The fix is a proper data model underneath the automation. This is the five table schema that makes it work.
Why a flat email log is not enough
A naive version of this system logs each email as a row and calls it done. This breaks down fast: there is no clean way to ask 'what is the full context of this person's conversation with us' without reconstructing it from scattered rows, and no reliable way to track conversation-level state like 'is this closed' or 'has a human taken over' separately from individual messages.
The five table structure, leads, contacts, conversations, messages, and events, separates who someone is, what conversation they are part of, what was actually said, and what happened around it, so the system can track not just 'was an email sent' but the full back and forth history per contact.
First touch and inbound handling
New leads are automatically sent an initial outreach email as the first message in a new conversation record. Replies come in through a webhook, get matched to the right conversation thread, and get logged as new messages. Getting the thread-matching step right, correctly attributing a reply to the existing conversation rather than starting a new one, is what makes everything downstream trustworthy.
Summarization as the antidote to context loss
An AI agent periodically summarizes longer conversation threads so a human can catch up in seconds instead of re-reading everything. This is only possible because messages are stored as a structured, ordered sequence per conversation rather than scattered rows with no clear thread boundary. The summary is generated from the actual message table, not from a human's memory of what happened.
Automated follow up and human handoff as conversation-level state
If a lead has not replied after a set period, an AI generated follow up is sent automatically, continuing the thread naturally, which requires knowing precisely how long it has been since the last message on that specific conversation, not a global timer.
Conversations that need a real person, complex questions, ready to close leads, are flagged and handed off, and closed conversations are marked as such to stop further automated messages. This handoff and closure state lives on the conversation record itself, which is what prevents an automated follow up firing on a conversation a human already closed by hand.
The events table: the part people skip and regret
A separate events table logs things that are not messages but matter to the conversation's state: an email opened, a link clicked, a lead marked as qualified by a human, a conversation reassigned. Without this, the system has no way to distinguish 'went quiet because they are not interested' from 'went quiet because a human is already handling this offline', and ends up automating over a conversation that should have been left alone.
- ·A flat log of sent emails cannot answer 'what is the full context of this relationship', which is the actual requirement for good follow up.
- ·Separating leads, contacts, conversations, messages, and events lets the system reason about conversation-level state, not just individual sends.
- ·AI summarization only works well when messages are stored as a structured, ordered thread, not scattered rows.
- ·Follow up timing needs to be per-conversation, based on that thread's last message, not a global timer across all leads.
- ·An events table capturing opens, clicks, and human actions is what prevents the automation from following up on a conversation a human already took over.
Frequently asked
Why not just use the CRM's built in email tracking instead of a custom schema?+
Most CRMs track emails as a flat activity log tied to a contact, without the conversation-level state (closed, handed off, awaiting reply) this system needs to make correct automated decisions. The custom schema exists specifically to support that decision logic.
What database does this run on?+
Supabase, chosen for row level security and straightforward Postgres access from n8n, which orchestrates the workflow logic around this schema.
How does the system know when to stop automating a conversation?+
A closed flag on the conversation record, set either by a human explicitly closing it or by a defined business rule, is checked before any automated follow up fires. If it is set, nothing further gets sent automatically.
Does this scale to a high volume of leads without the summarization step becoming a bottleneck?+
Yes, since summarization runs per conversation on demand or on a schedule, not as a blocking step in the send pipeline. High volume is handled by the schema's structure, not by adding more compute to a single choke point.
Further reading and references
Related work on this site, and the tools and profiles referenced above.
Get new guides like this one
Whatever I ship next, straight to your inbox. No noise, unsubscribe any time.
