Call Recap to Tone-Guided Follow-Up Email
A self-directed n8n workflow prototype that converts structured call recaps into addressed Gmail drafts for human review — and the draft-only safeguard that caught its own failure.
Self-directed portfolio project inspired by a publicly posted freelance brief. Not commissioned client work.
5 min readThe short version: a self-directed n8n + Gemini workflow drafts tone-matched Gmail follow-ups from call recaps — and during testing, its human-review safeguard caught an identity mix-up before it could reach a client.
Jump to Real Engagement → Solo project — see 3-Year CX Analytics Initiative for team-scale leadership →Serves: the BD/account team member sending the follow-up, and the client on the other end of the call · Why it matters: every minute not spent drafting from scratch is a minute the BD team gets back to focus on the relationship itself, not paperwork.
A generic, unreviewed follow-up right after a phone call reads as impersonal — clients who just spoke with someone want a reply with the right tone and a personal touch, not a template. That's exactly why the workflow stops at a draft: a human still checks it before anything reaches the client.
A real business problem. One deliberately chosen slice. A prototype designed around human control.
I found a public freelance brief describing a familiar workflow problem: turning sales calls into follow-up emails was repetitive, manual, and inconsistent.
Each team member was:
- Copying call transcripts into an AI tool
- Writing prompts from scratch
- Creating recaps in different formats
- Drafting emails in their own tone and structure
The opportunity: turn that fragmented process into a repeatable workflow that could produce a consistent, voice-aligned draft for human review.
I didn't build everything. I chose the part worth testing.
Without access to the client, its systems, or real customer data, recreating the entire proposed solution would have added complexity without proving much more.
So I scoped the prototype around one high-value question:
Can a structured call recap reliably become a useful, voice-aligned email draft without giving AI the final say?
The prototype
The workflow:
- Standardizes the drafting process
- Reduces repetitive manual work
- Applies defined voice and writing rules
- Grounds the email in the supplied recap
- Stops at Gmail Drafts rather than auto-sending
Why that last decision matters
The goal wasn't maximum automation. It was finding the right boundary between automation and human judgment.
For customer-facing communication, AI could do the repetitive first-pass work. A person still owned the final decision.
That was the system I wanted to test.
The short version: a four-node pipeline that drafts the email and stops — a human decides what sends.
What I built, and why the human stays in control
I built the four-node pipeline below in a single afternoon, then spent the following days testing it against real and fictional scenarios.
The AI drafting step
The recap is converted into an email using defined voice and style rules. Click the five highlighted phrases below to see which rule shaped each one:
Hi Morgan, thanks for the time today. Per our call, the team needs API access by end of month, so I'll get a technical contact looped in this week. We can start the setup once the contract is signed, and I'm happy to hop on a quick call if anything above needs adjusting.
Best,
Jordan
Reconstructed example.
Model choice
Gemini powered the prototype, but I did not treat that choice as final.
For a real implementation, I would compare multiple models against the same test set for:
The goal would be to select the model based on evidence, not preference.
Human stays in control
The Gmail integration creates an:
Addressed email subject line completed draft
But it never sends automatically.
The workflow ends in Drafts, keeping a human responsible for reviewing and approving every customer-facing message.
The automation removes repetitive setup. It does not remove the reviewer's responsibility to verify identity, recipients, facts, commitments, action items, and tone before sending.
For testing inputs, I used my own Wispr Flow call recaps, because the meeting recorder produces the structured overview, key points, action items, and next steps this workflow needs.
Adjust the assumptions to see how the estimate moves.
That's roughly 6 hours a week returned to relationship-building instead of drafting.
Multiply by team size for organization-wide impact.
Why rejected: Ongoing API cost for a workflow meant to run on every call, not a one-off.
Chose instead: Gemini — lower cost for a prototype run repeatedly.
Why rejected: Subscription cost scales with usage — expensive to run this on every call.
Chose instead: n8n — self-hostable, no per-task cost.
Why rejected: A human needs to review the recap right after the call, not after a processing delay.
Chose instead: Wispr Flow — the structured recap is ready immediately.
| Metric | Before | After |
|---|---|---|
| Path to a follow-up | Have the call → AI drafts a transcript → prompt ChatGPT to draft the email → copy the draft into Gmail → address and send | Wispr Flow captures the call → review and paste into n8n → draft comes out → human reviews and sends |
| Tools touched per email | 3–4, switching by hand | 1 workflow, start to finish |
| Voice & tone | Whatever each person wrote that day | Defined voice rules, applied consistently |
| Human review before send | Inconsistent, easy to skip under time pressure | Required by design — draft-only |
The short version: the safeguard did its job — a flawed draft never reached a client inbox.
The output failed an identity check. The safeguard worked.
| Test | Purpose | Observed result |
|---|---|---|
| Recruiter screening recap (success case) | Confirm form submission, model drafting, and Gmail creation worked end to end | Addressed Gmail draft produced — plumbing confirmed |
| Fictional sales discovery recap (stress case) | Test the same workflow against the brief's actual target scenario | Draft completed, but contained an identity inconsistency |
The prompt assumed one sender, while the fictional recap named a different BD lead: the draft described that lead's actions in third person, then signed off in their name. It didn't pass the identity check — but because the workflow stops in Gmail Drafts, the inconsistency was caught before it could become client-facing communication.
Had it sent, the cost wasn't just an awkward typo — it was content confusion and damaged trust. A client who just got off the phone doesn't want a generic, mismatched follow-up; they want a reply with a personal touch and the right tone, checked by a person before it lands in their inbox.
Hi Morgan, following up on today's call — Jordan discussed pricing options and next steps with your team, and wanted to confirm we're aligned before the proposal goes out. Happy to jump on a quick call if anything needs clarifying.
Best,
Jordan
Click the two highlighted spans to see the inconsistency — reconstructed for illustration.
The prototype was built around a single known sender. A team-ready version needs sender identity, approved voice rules, and signature details as structured inputs — not assumptions hidden inside one prompt.
What the fix would look like
A structured sender profile, selected before drafting — instead of an assumption buried in the prompt.
A hypothesis, not yet tested — not a built feature.
The short version: six workstreams — from discovery to measurement — separate this prototype from a team-ready rollout.
What a real engagement would add
Interview BD, account, and operations leads; map call types, ownership, and approval steps.
PlannedDefine sender profiles, voice rules, required sections, and the human approval boundary.
PlannedAdd recipient/sender validation, duplicate prevention, retries, failure alerts, and prompt versioning.
PlannedTest representative call types and edge cases against a defined accuracy/identity/tone rubric, including a head-to-head comparison of drafting models before locking one in.
PlannedConfirm transcript consent, confidential-data handling, retention, and access control.
PlannedSmall-group rollout with trained reviewers before expanding to the wider team.
PlannedDefine KPIs/OKRs before rollout (e.g., minutes saved per rep, time from call to sent email, percentage of drafts sent without edits), then track them against the estimated impact above once live.
PlannedIf I had to prioritize two of these first, it would be Discover and Evaluate: you can't design real guardrails without understanding actual call patterns, and the one failure this prototype surfaced was an evaluation gap. Govern would run alongside Discover, not wait until later, given this touches real client communications.
What would remain human-owned regardless: final factual verification, commitments made to the client, recipient selection, sensitive content, relationship judgment, and the decision to send.
A safeguard caught a real identity error — before it reached a client.
The workflow stops at Drafts. A human decides what sends.
Six clear workstreams separate this prototype from a team-ready rollout.
The hardest part wasn't building the automation. It was defining the right boundary between AI and human judgment.
This prototype shows how I:
- Scope ambiguous problems
- Test responsibly
- Catch failures
- Turn experimentation into a clear next step
This is exactly the kind of work I want to keep doing: finding the deliberate boundary between automation and human judgment, and building systems people can actually trust. Solo, this is how I think. With a team, it's what I've already led — see the case studies above for what that looks like at scale.
Also relevant — both self-directed initiatives, built without being asked:
02 · 3-Year CX Analytics Initiative →