build.allanninal.dev

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

How a renewal offer reaches the owner

The drafter wrote an offer — an upgrade, a loyalty discount, or a right-size. Now it has to reach the right owner, with the discount double-checked, at a sensible time, in a form they can act on in ten seconds. Get any of those wrong and you waste a renewal: a draft routed to the wrong rep, a discount that slipped past the cap, a 2am ping nobody reads. Four small guardrails sit between the finished draft and the owner’s approval queue. The customer is never touched in this path.

Key takeaways

  • Owner resolution: per-account override beats per-tier default beats fallback to the configured admin.
  • A discount-cap gate re-checks every offer; anything over the cap is held, never queued silently.
  • Quiet hours defer the owner ping to the next business hour — the draft still waits in the queue.
  • Every draft reaches the owner with the account, plan, discount, reasoning, and the full email text.
  • The offer goes to the owner’s queue, not the customer. Only a human send in Part 5 reaches the customer.

Four guardrails before the queue

Four guardrails between the drafted offer and the approval queue A horizontal flow diagram. On the far left, a "Draft ready" box: the drafter produced an offer with the account, the chosen plan, the discount, and the email text — one of three shapes, upgrade, loyalty, or right-size. Four guardrail gates sit in a row to the right, each drawn as a vertical bar. Gate 1: Resolve owner — looks up the per-account owner column first; if blank, falls back to the per-tier owner from the rules doc; if still blank, falls back to the configured admin. Returns a Slack member ID if one is set, otherwise an email address. Gate 2: Cap re-check — re-reads the discount on the draft against the per-tier cap and the floor price from the rules doc; if the discount exceeds the cap or the price drops below the floor, the draft is held and flagged for a human instead of queued. Gate 3: Quiet hours — checks the local time against the rules-doc quiet-hours window (default 6pm to 8am); if outside business hours, defers the owner ping to the next available business minute via an EventBridge Scheduler one-off rule. The draft itself still sits in the queue; only the notification waits. Gate 4: Compose for the queue — formats the queue card with the account context, the plan, the discount, the short reasoning, the full draft email, and the approve, edit, and skip buttons. After all four gates pass, the card is written to the rn-queue table and the owner is notified via Slack or email. A note at the bottom: nothing in this path reaches the customer — the offer waits in the owner's queue until a human sends it. Draft ready upgrade, loyalty, or right-size Gate 1 Resolve owner account override? tier default? admin fallback? prefer Slack ID, fall back to email Gate 2 Cap re-check discount within cap and floor? if over, hold and flag a human Gate 3 Quiet hours local time in business window? if not, defer the ping only Gate 4 Compose for queue card: account, plan, discount + reasoning, draft email, 3 buttons Approval queue — Slack DM (preferred) or SES outbound email (fallback) card written to rn-queue · owner notified · customer not touched every queued draft logged to DDB rn-offers — nothing is sent yet Nothing in this path reaches the customer — the offer waits in the owner’s queue until a human sends it.
Fig 4. Four guardrails between the drafted offer and the approval queue. Resolve the owner. Re-check the discount cap. Honor quiet hours for the ping. Compose the queue card. Then write it to the queue and notify the owner — the customer is never touched here.

Gate 1: resolve the owner

Three places the gate looks for the owner of an account, in order. First, the registry sheet’s per-account owner_email column — if a row has a specific rep assigned, that rep owns the renewal regardless of the tier default. Second, the per-tier default in the rules doc (“all mid-tier accounts default to the account manager”). Third, the configured admin fallback — the person who set up the system and gets every unowned draft. The fallback should rarely fire; if it does, the weekly digest names every account that hit it so the rules doc can be updated.

Once the gate knows which person to notify, it looks up their delivery preference. The voice doc maps each owner to a Slack member ID if one is set, otherwise to an email address. Slack is preferred because a DM with buttons is faster to act on than an email link. Email is the fallback so nobody falls through the cracks. Either way, the message is to the owner — never to the customer.

Gate 2: the discount-cap re-check

Part 3 already checked the discount against the cap inside the drafter. Gate 2 checks it again, on purpose. Defense in depth matters most for the one thing that can’t be taken back — a discount that went out too rich. This gate re-reads the discount and the resulting price straight off the draft and compares them to the per-tier cap and the floor price in the rules doc. If the discount is at or under the cap and the price is at or above the floor, it passes. If either fails, the draft is not queued for one-tap approval; it’s held and flagged for a human to look at, with a note explaining which limit it tripped.

This is the gate that makes the system’s core promise real: a draft can never quietly offer more than your rules allow. Even a bug in the drafter, or a strange model output that slipped through the first check, gets caught here before it can reach a customer-facing queue card.

Gate 3: quiet hours

The drafter runs at a fixed hour, so most drafts are ready during business hours. But deferred drafts and re-runs can finish later. Gate 3 reads the rules doc’s quiet-hours setting (default 6pm to 8am, configurable). If the current local time is in the quiet window, the gate writes the draft to the queue anyway — it just defers the notification to the owner. It creates a one-off EventBridge Scheduler rule that pings the owner at the next business-hour minute. The draft is never lost; only the buzz waits. An owner who opens the queue early still sees everything waiting for them.

Gate 4: compose the queue card, then write it

The queue card is what the owner actually sees. Gate 4 assembles it: the account name and current plan, the proposed plan and price, the discount and which cap it sits under, the one-line reasoning (“heavy user near the Pro ceiling; loyalty discount 10%”), and the full draft email exactly as it will go to the customer if approved. Below that sit three buttons — approve & send, edit, skip. For Slack, this is a Block Kit message; for email fallback, it’s an HTML card with links that hit a Function URL. The card is written to the rn-queue DynamoDB table and a row is logged to rn-offers marking the account as drafted-and-waiting.

Crucially, composing the card sends nothing to the customer. The draft email is shown to the owner for review; it leaves the building only when the owner presses send in Part 5. The whole of Part 4 is about getting a good draft in front of the right person, safely — not about delivery.

Why the guardrails exist

None of these gates are exotic. They’re the care a thoughtful sales manager would take before handing a rep a renewal to send — check who owns it, confirm the discount is within authority, don’t buzz anyone at midnight, and lay out everything they need to decide in one glance. Putting them in code as four small sequential gates makes them part of the design, not something you’re trusting any one draft to remember. And the cap re-check, sitting in the middle, is the guardrail that keeps an automated drafter from ever becoming an automated giveaway.

Next post: what the owner can do with a draft — approve and send, edit first, or skip — and how each choice updates the account, the queue, and the audit trail.

All posts