The follow-up after a sales call is the email most people send late. AI can write it a minute after the call ends. The real question is whether it should also press Send.
I keep it at draft only. A follow-up repeats what was said on the call, so if the model mishears a price, a date or a promise, auto-send puts that mistake in writing with the prospect’s name on it.
If you build this yourself, two things save you trouble:
-
Save the email as a draft, and leave the recipient empty when the workflow is not sure who the contact is. An empty To field is easier to fix than an email sent to the wrong person.
-
Expect duplicate webhook events. Fireflies can send the same event more than once, so log each meeting ID and skip any you have already handled. Otherwise one call gives you two drafts.
My full version writes the call notes and the follow-up, saves the draft in Gmail and logs the call in Google Sheets:
I honestly feel like n8n is overkill for a use case like this. An agent like Claude or ChatGPT with tools can do the same thing and would much simpler to update and maintain - just one POV.
Drafting the message automatically is definitely the safest baseline while you refine the prompt logic. Letting AI generate the structured recap right into your CRM queue keeps reps from delaying outreach without risking an unchecked hallucination going out to an enterprise prospect.
Once your accuracy rate crosses 95% on common edge cases, adding an approval webhook or human-in-the-loop Slack notification gives you the best balance between speed and quality control.
Fair point, and for one person handling a few calls a week I would probably agree. An agent with Fireflies and Gmail connected gets you most of the way.
Where n8n earns its place for me:
- It starts on its own. Fireflies fires the webhook when the transcript is ready, so nobody has to open a chat and ask.
- It does the same thing every time. The resend check, the empty recipient rule and the sheet log are plain logic, not something the model decides on each run.
- Every run is in the execution log, so when a draft looks wrong I can see the exact transcript and output that produced it.
The model still does the writing. n8n handles everything around it.
How do you start the agent in your setup: after each call, or on a schedule?
Agreed, draft only is where I would start anyone using this.
The part I find tricky is measuring that 95%. The simplest signal I can think of is comparing each draft with the email the rep actually sent. If reps send it unchanged most of the time, the prompt is ready for an approval step instead of a full review.
The Slack approval you describe is the pattern my other templates use before anything changes in Shopify or HubSpot, so it would be a small step to add here.
How do you track accuracy in your own builds: comparing drafts with what was sent, or checking a sample by hand?
I’d go draft-only too, at least for the first few weeks. In my own follow-ups the model sometimes got a date or a number slightly off, and I only caught it because I had to read the draft first. If drafting gets boring and the drafts keep coming out right, then a quick approval step is an easy middle ground before auto-send.
One edge case I’d test is Gmail creating the draft successfully, but n8n timing out before saving the draft ID
A retry could create a second draft even with the meeting ID check. I’d keep those attempts separate from confirmed drafts and reconcile them before trying again
Fair point, and it is a real gap. Two details: the template skips events Fireflies marks as reprocessed but does not keep a list of meeting IDs, and the Gmail node has Retry On Fail turned off. So the second draft only happens if someone presses Retry on the failed run.
Keeping attempts separate from confirmed drafts is the right way to close it. My question is whether it is worth it here: nothing reaches the client, and a duplicate draft costs one click to delete. The extra steps also make setup harder for a beginner.
Would you add the reconcile step for drafts, or only once the workflow sends on its own?
For a draft-only beginner template, I probably wouldn’t add full reconciliation yet. The extra complexity can cost more than the occasional duplicate draft.
I’d document the retry limitation and, if it’s easy to implement, use the meeting ID as a lightweight dedupe key.
Once the workflow starts sending emails automatically, though, I’d treat idempotency and checking the actual Gmail outcome as essential. A failed execution doesn’t always mean the action itself failed.
So I’d keep the safeguard proportional to the consequence of duplication, rather than applying the same architecture to every workflow.
