build.allanninal.dev

Part 5 of 7 · Renewal negotiator series ~5 min read

How a renewal gets sent or skipped

A draft for Bayside Studio lands in Maria’s queue at 8:03am: upgrade to Business, 10% off, a warm two-paragraph email ready to go. There are three buttons. What happens when she taps one? This is the part of the system where the human makes the call. This post walks through the three things Maria can do — approve and send, edit, or skip — and how the account, the queue, and the audit trail all stay in sync. Nothing reaches the customer until she presses send.

Key takeaways

  • Three actions per draft: approve & send (to the customer), edit (change then send), skip (no offer).
  • Approve & send is the only path that emails the customer — via SES, from your address.
  • Edit opens a modal; any discount change is re-checked against the cap before it can send.
  • Skip closes the cycle cleanly — the account gets no offer and the reason is logged.
  • Every action writes to the rn-audit table and is reversible from a snapshot.

Three actions on a draft

Three actions on a queued renewal draft A diagram showing one input on the left flowing through a queue card, then branching into three action paths. Far left: a "Draft in approval queue" box showing a typical queue card — account name, proposed plan, discount, and the draft email — with three button placeholders below: Approve and send, Edit, Skip. The owner taps one button. The middle column shows the three branches. Branch one, Approve and send: the offer email is sent to the customer via SES from the owner's address; the registry sheet is updated via the Sheets API to mark the account offered with the plan and discount sent; a sent event is written to the audit trail. This is the only branch that emails the customer. Branch two, Edit: opens a modal pre-filled with the draft email, the plan, and the discount; the owner can change the wording, swap the plan, or adjust the discount; any discount change is re-checked against the cap before the modal will let it send; on save the edited offer is sent and recorded. Branch three, Skip: this account gets no offer this cycle; the owner picks a reason from a short list (handling by hand, already churned, not ready); the registry is marked skipped and the reason is logged; the customer is never contacted. The right side shows the convergence: every action writes a row to the rn-audit DynamoDB table with timestamp, account id, action, by-user, and notes. A note at the bottom: only Approve and send (or a saved Edit) ever reaches the customer — Skip and an unopened draft never do. Draft in queue account, plan, discount [Approve & send] [Edit] [Skip] Action 1 Approve & send • SES emails the customer from your address • Sheets API marks offered • Only branch to the customer Action 2 Edit • Modal: wording, plan, discount within cap • Cap re-checked, then send and record Action 3 Skip • No offer this cycle — pick a reason • Customer never contacted Audit trail DynamoDB rn-audit timestamp · account_id action · by-user notes Only Approve & send (or a saved Edit) reaches the customer — Skip and an unopened draft never do.
Fig 5. Three actions per draft, three different effects. Approve & send emails the customer and marks the account offered. Edit changes the offer (re-checked against the cap) then sends. Skip closes the cycle with no offer. Every action writes to the audit trail.

Action 1: approve & send (the common path)

Maria reads the Bayside draft, agrees with it, and taps Approve & send. The button submits to a Function URL Lambda. Three things happen, in order. First, the offer email — the exact text she reviewed — is sent to the customer via SES outbound, from the owner’s own sending address, so the reply lands in Maria’s inbox like any normal email. Second, the Sheets API updates the account row: the offer is marked sent, with the plan and discount that went out and today’s date in last_offered. Third, an action: sent row is written to rn-audit with the user, timestamp, and the full offer that was sent.

This is the only one of the three actions that contacts the customer. Everything earlier in the series — intake, drafting, the four guardrails — exists to make this one tap safe and fast. When Bayside replies and upgrades, Maria edits the registry row with the new plan, price, and renewal date (or forwards the signed paperwork to the inbox lane), and the cycle rolls forward to next year.

Action 2: edit (the tweak)

Often the draft is 90% right. Maria wants to add a personal line about the project Bayside shipped last quarter, or she knows this customer responds better to a round number than a percentage. She taps Edit. A modal opens pre-filled with the draft email, the proposed plan, and the discount. She can change the wording freely. She can swap the plan from the menu. She can adjust the discount — but here’s the one hard rule: any discount change is re-checked against the cap and floor from the rules doc before the modal will let her send. If she tries to go past the cap, the modal blocks it with a note (“that’s above the 15% cap for this tier — lower it or ask for an exception”).

On save, the edited offer is sent to the customer exactly as Action 1 would, and the audit row records both the original draft and the edited version, so next year’s reviewer can see what the system proposed and what the human actually sent. The edit path is where the human’s judgment and the system’s consistency meet: the system did the heavy lifting, the person added the touch only they could.

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

Sometimes the right move is no offer. The account is one Maria is negotiating by hand. The customer already gave notice and is leaving. The renewal is far enough out that she’d rather wait. She taps Skip and picks a reason from a short list — handling by hand, already churned, not ready yet, other. The registry row is marked skipped for this cycle with the reason, and an action: skipped row is written to rn-audit. The customer is never contacted.

Skip is bounded and honest. A skipped account doesn’t silently disappear — it shows up in the weekly digest and the monthly summary as “skipped: handling by hand” so nothing falls through a crack. And not ready yet is special: it re-queues the account for a fresh draft a configurable number of days later (default 7), so “skip for now” doesn’t become “skip forever.” The most dangerous failure mode for a renewal system is an account that quietly gets no attention; skip is built so that can’t happen by accident.

Every action is logged, every action is reversible

The rn-audit table records every send, edit, and skip with the user who took the action, the timestamp, and a snapshot of the offer before and after. If an offer went out with a wrong figure, or an account was skipped that shouldn’t have been, a rep can run an “undo last action” through a small admin command that reads the previous-state snapshot and restores the row (a sent email can’t be unsent, of course, but the registry state and the cycle can be corrected, and a follow-up drafted). The undo is itself an audit row, so the trail of edits stays clean.

This reversibility matters most for the renewals you’ll only think about once a year. The next time Bayside comes up, it might be Maria again or whoever took her seat. Either way, the audit trail is the only memory the next person has — what was offered, who sent it, and what changed.

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 model call per renewal keeps the bill small.

All posts