The Proposal Autopilot

The moment a client record is marked ready in Airtable, this system finds the matching call in Fireflies, pulls the full transcript, and hands it to Claude. Claude drafts four sections from the conversation itself. A code node assembles those sections into a branded HTML proposal using the client's name, business, and logo already sitting in Airtable, converts it to a PDF, and emails it.

Nobody opens a template. Nobody plays back a recording to remember what was quoted. It was tested end to end on a manual run against a test client record: all 14 nodes succeeded, the transcript matched correctly, and the finished PDF, logo and pricing included, landed in the inbox.

After a discovery call, someone has to turn a conversation into a document: re-listen to the call, draft what was discussed, translate it into something that looks professional, and get it into the client's inbox before the moment cools off. None of that work is hard. All of it is manual, all of it repeats for every prospect, and all of it competes with the time that should go to the next call.

• The failure mode isn't usually a bad proposal. It's a slow one, or an inconsistent one
• The person writing it is working from memory of a conversation that happened hours or days earlier
• Every proposal is the same four questions answered from scratch, by hand, at the exact moment attention is worth the most elsewhere

One AI call, constrained to the words already spoken. Claude reads the full transcript and drafts four sections: What We Discussed, Key Takeaways, What Happens Next, and Pricing. The system prompt instructs it to work only from the transcript, so the proposal can't quote a number or a commitment that never came up on the call.

Deterministic HTML, not a second AI call. The original version used a second GPT call to turn the drafted JSON into HTML, and that is where most of the debugging time went: broken image tags, escaped characters, output that would not start with an html tag no matter how the prompt was worded. Replacing that step with a code node that assembles the HTML directly from Airtable fields plus the AI-drafted sections removed an entire category of failure, at zero extra AI cost.

Transcript matching by content, not position. The original build filtered on the first transcript in the account. That works by coincidence when there is exactly one call on file and breaks silently the moment there is a second. It was replaced with a code node that searches the full transcript list for a title containing the client's email, and throws a clear, loud error if nothing matches. A wrong proposal is worse than a failed run, and a failed run is at least visible.

Real bugs, caught in testing rather than production. Airtable's API returns record data nested under .fields, not flat on the record, so every expression reading Airtable data had to be corrected after a full failed run surfaced it. A later, unrelated node edit silently dropped the Gmail node's operation parameter, which showed up as a validation error rather than a runtime one. And PDF.co's authentication needs the API key in a header literally named x-api-key, not a Bearer-prefixed token, which looks like a broken integration until you know it.