build.allanninal.dev

Part 5 of 7 · Proposal generator series ~5 min read

How a proposal gets sent

A draft lands in your Slack at 2:14pm. The cover reads right, the price is $17,500, the timeline is four weeks. There’s an Approve button. What happens when you tap it? The honest answer is “it depends on what you actually did.” This post walks through the three things you can do with a finished draft — approve, edit, discard — and how the PDF, the Drive folder, and the audit trail all stay in sync.

Key takeaways

  • Three actions per draft: approve (render and email), edit (revise in the doc), discard (archive).
  • Approve renders a branded PDF, saves it to Drive, and emails the client via SES with a short cover note.
  • Edit opens the linked Google Doc; your changes flow back and you re-approve the revised draft.
  • Discard archives the brief and the draft — nothing is deleted, so a dropped deal can be revived.
  • The Approve button is a Slack interactive message backed by a Function URL.

Three actions on Approve

Three actions on the Approve button A diagram showing one input on the left flowing through a small interactive Slack panel, then branching into three action paths. Far left: a "Draft in Slack DM" box showing a typical draft preview — client name, the price, the timeline, and a link to the full proposal — with three Slack-button placeholders below: Approve, Edit, Ack only standing in for Discard. The owner taps one button. The middle column shows the three branches. Branch one, Approve: a Function URL Lambda renders the five sections into a branded PDF with your logo and terms, saves the PDF to the Drive proposals folder, emails it to the client via SES with a short cover note, and writes a sent event to the audit trail. Branch two, Edit: opens the linked Google Doc so the owner can revise the prose directly; on re-approve, the doc's text is pulled back, the price-and-date guard runs again, and the proposal is rendered and sent. The brief and computed price aren't changed by an edit unless the owner changes them. Branch three, Discard: archives the brief and the draft to a separate sheet without sending anything; nothing is deleted, so a dropped deal can be revived later by reopening the brief. The right side shows the convergence: every action writes a row to the pg-audit DynamoDB table with timestamp, brief id, action, by-user, and notes. A note at the bottom: Discard doesn't delete — it archives. A dropped proposal can always be reopened from the brief. Draft in Slack DM client, price, timeline [Approve] [Edit] [Discard] Action 1 Approve • Render branded PDF with logo + terms • Save to Drive folder • Email client via SES Action 2 Edit • Open linked Google Doc revise the prose • Re-approve → guard re-runs, then sends Action 3 Discard • Archive brief + draft to a separate sheet • Nothing deleted — revive any time Audit trail DynamoDB pg-audit timestamp · brief_id action · by-user notes Discard doesn’t delete — it archives. A dropped proposal can always be reopened from the brief.
Fig 5. Three actions per draft, three different effects. Approve renders and emails the proposal. Edit opens the doc to revise, then re-runs the guard and sends. Discard archives without deleting. Every action writes to the audit trail.

Action 1: approve (the most common)

You read the draft, it’s right, you tap Approve. The button submits to a Function URL Lambda, and four things happen in order. First, the five sections are rendered into a branded PDF — your logo, your colors, your standard terms page, the computed price table laid out cleanly. Second, the PDF is saved to the Proposals/sent/ folder in Drive, named with the client and date so it’s easy to find later. Third, the PDF is emailed to the client through SES outbound, with a short cover note pulled from your voice doc (“Hi — great speaking earlier. Attached is our proposal; happy to walk through it.”). Fourth, an action: sent row is written to pg-audit with you, the timestamp, the brief id, and the final price.

From the client’s side, this looks like you sat down and wrote them a thoughtful proposal that afternoon. From your side, it was a ten-minute review and one tap. The draft that would have died on the blank page is in their inbox before the conversation cooled.

Action 2: edit (the tweak)

Most drafts need a small change. The approach is right but you’d phase it differently. The timeline assumed a start date that slipped. A sentence in the cover is almost right. Edit opens the linked Google Doc — the same doc Gate 4 created — and you revise the prose directly, in a tool you already know, with no new app to learn.

When you’re done, you re-approve from the doc or back in Slack. The Lambda pulls the edited text back, and — this is the important part — runs the price-and-date guard again. If your edit changed a number, the guard re-checks it against the computed values; if you deliberately overrode the price, the guard records that as a human override in the audit trail rather than blocking you. Then it renders and sends exactly as Approve would. An edit never skips the guard; it just lets you be the one who decides.

Action 3: discard (the “not this one”)

Sometimes the draft isn’t worth sending. The lead went quiet. You decided to pass. The scope was wrong and it’s easier to start fresh than to fix. Discard archives the brief and the draft to a separate archived sheet in the Drive folder, with the date and who discarded it. Nothing is deleted.

That “nothing is deleted” matters. Leads come back. Three weeks later the prospect emails “sorry, got pulled away — still keen?” and you can reopen the archived brief, re-run the draft against your current rate card, and send in minutes. A discarded proposal is paused, not lost. The archived sheet is also what the monthly summary in Part 6 reports on — how many briefs came in, how many went out, how many got dropped and why.

Every action is logged, every proposal is traceable

The pg-audit table records every approve, edit, and discard with the user who acted, the timestamp, and a snapshot of the draft before and after. Months later, when a client signs and someone asks “what exactly did we promise them?”, the answer is one lookup: the brief it came from, the version that was sent, the price that was quoted, and who approved it. If a wrong proposal somehow goes out, the snapshot lets you see exactly what was sent and send a correction with a clean paper trail.

This traceability is the quiet payoff of keeping a human in the loop and logging every step. The generator makes you fast; the audit trail makes you accountable. Neither is worth much without the other.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why the one Sonnet draft call is the bill.

All posts