build.allanninal.dev

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

A renewal negotiator on AWS for a few dollars a month

A small business loses more customers at renewal time than it ever loses to a competitor. The annual contract that quietly lapses because nobody reached out two weeks before. The heavy user who would happily have moved up a tier if someone had asked. The loyal account who churned over a price bump that a small loyalty discount would have softened. Renewals are won by getting in front of the customer early with a fair, tailored offer — and most teams just don’t have the hours. This post walks through the design of a small helper that, ahead of each renewal, gathers what it knows, drafts an offer in your voice, and hands it to you to approve, edit, or skip. It never sends anything itself.

Key takeaways

  • Three sources for accounts: a Drive registry, an inbox forwarding lane, and a calendar import lane.
  • Ahead of each renewal the system drafts one tailored offer and puts it in your approval queue.
  • The plan and the discount come from your rules; the model only writes the words around them.
  • Nothing reaches a customer without a person pressing send. Discounts stay inside your caps.
  • Designed on AWS for about $3/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Customer accounts" — a Google Drive registry sheet listing each account with its plan, current price, renewal date, usage signal, and history, plus an inbox forwarding lane and a calendar import lane that add new accounts to the registry. Centre, "Rules and voice" — a Drive folder with a rules doc covering the plan menu, discount caps per tier, and which accounts to skip, plus a voice doc with the offer message templates and tone. Far right, "Owner" — the person who approves each draft; offers land in their approval queue, never the customer's inbox directly. Each connects via an arrow to the AWS account container below. Customer accounts feed in. Rules and voice ground every offer so the system never invents a price or a discount. The owner receives a drafted offer with the account, the proposed plan, the discount inside the cap, the reasoning, and approve, edit, and skip buttons. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Account intake — receives accounts from each source, parses forwarded contracts and usage exports, and writes the cleaned account into the registry. In the middle, the Drafter — runs daily; finds renewals coming due; picks the plan and discount band from the rules; calls Bedrock to write the offer in your voice. On the right, the Approval queue — holds each draft for the owner to approve and send, edit, or skip; only a human sends. Internal arrows flow left to right. A note at the bottom reads: the system only prepares the offer — a human always sends and can always override. Customer accounts registry, inbox, calendar Rules and voice plans, caps, templates Owner where drafts land accounts in grounds draft offer to approve AWS account Account intake parse, normalize, add to registry Drafter picks plan + discount, writes offer in your voice Approval queue approve, edit, or skip; only a human sends account draft The system only prepares the offer — a human always sends and can always override.
Fig 1. Three sources outside, three pieces inside AWS. Accounts flow in from a Drive registry, an inbox forwarding lane, and a calendar import lane. The Drafter runs daily and prepares one offer per upcoming renewal. The Approval queue holds it for the owner; only a human sends.

What you set up once (the outside)

  • Customer accounts. A Google Sheet in a Drive folder, one row per account: name, plan, current price, renewal date, a usage signal (seats used, hours billed, orders placed — whatever fits your business), owner email, and a short history (last renewal, last discount given, any notes). You can fill it in once from your billing export and forget it; new accounts can also enter via two other lanes covered in Part 2 — an inbox-forwarding lane (forward a signed contract or a usage export and the system proposes a row for one-tap approval) and a calendar import lane (renewal dates tagged in Google Calendar with #renews get pulled in automatically).
  • A rules folder. Two short Google Docs in a Drive folder. The rules doc holds your plan menu (what each tier costs and includes), your discount caps per tier (“small accounts: up to 10% loyalty discount; mid: up to 15%; never below the floor price”), how far ahead of the renewal date to prepare an offer, and which accounts to always skip (the ones you handle by hand). The voice doc holds one offer template per situation — the tone and shape of what the email to the customer should say. The model fills these in; it never makes up the numbers.
  • Owner. The person responsible for renewals. Each drafted offer lands in their approval queue — an email or a Slack message with the account, the proposed plan, the discount (always inside the cap), the short reasoning, the full draft email, and three buttons: approve & send, edit, and skip. The customer never hears from the system until the owner presses send.

What runs on every check (the inside)

  • The account intake. Three sources feed the registry. The Drive sheet itself is the canonical store. New accounts can also be added via the inbox forwarding lane (forward a contract PDF or a CSV usage export to renewals@your-company.com; the system reads it and drops a one-tap approval card so a rep can confirm before the row is added) and the calendar import lane (renewal dates tagged #renews get pulled hourly by a small sync Lambda).
  • The drafter. Runs once a day. Reads the registry. For each account whose renewal date falls inside the prepare-ahead window, it gathers the context — current plan and price, the usage signal, the history — and picks a move with plain Python: which plan to propose and which discount band to use, both straight from the rules doc. A heavy user near a plan ceiling gets an upgrade suggestion; a steady small account gets a modest loyalty discount inside the cap; a shrinking account might get a right-size-down offer to keep them. Only then does it call Bedrock to write the offer in your voice. The model gets the chosen plan and discount as fixed inputs; it writes the words, not the numbers.
  • The approval queue. Each finished draft is written to a queue and a message goes to the owner. Nothing is sent to the customer. The owner can approve and send as-is, open the draft to edit wording or nudge the discount (still inside the cap), or skip the account this cycle. Every choice is logged. A weekly digest lists what’s waiting and what was sent; a monthly summary writes a short narrative: renewals coming up, offers sent, accepted, and lost.

In plain words

Your customer Bayside Studio is on the Pro plan at $180/month and renews August 1. They’ve been with you two years, their seat usage is near the Pro ceiling, and they’ve never been given a discount. On July 2 (30 days out) the drafter prepares an offer: the rules say a heavy user near a ceiling gets an upgrade nudge plus a 10% loyalty discount, so it proposes the Business plan at $240/month with 10% off the first year. Bedrock writes a warm two-paragraph email in your voice that thanks them for two years, notes they’re bumping the Pro limits, and frames the upgrade as the cheaper-per-seat option. It lands in your queue. You read it, change one sentence, and press send. Bayside replies a week later and upgrades. The account row updates with the new plan, price, and renewal date, and the cycle starts again next year.

The cost of running this is about $3 a month at SMB volume. The cost of not running it is the renewal that lapsed in silence, the heavy user you never upsold, and the loyal account who left over a price bump you would gladly have softened.

Design rules that shaped every decision

  • The system only prepares an offer. A human approves and sends every single one — there is no auto-send.
  • The rules doc owns the numbers. Plans and discount caps come from it; the model never invents a price.
  • Every discount is checked against the cap before the draft is queued. A draft can’t exceed your limit.
  • Each draft ships with the account, the proposed plan, the discount, and the reasoning. The owner never has to dig.
  • The registry lives in Drive. Changing a plan, a cap, or an owner doesn’t need a deploy.
  • Every action is logged. Audit a renewal next year and you can see the offer, who sent it, and what changed.

Why this shape

Most teams handle renewals in one of three ways: a reminder that fires on the day with no offer attached, a generic price-increase email blasted to everyone, or nothing at all until the customer asks to cancel. The day-of reminder is too late to do anything useful. The generic blast treats a two-year heavy user the same as a trial that never converted — and annoys both. And “nothing” is how good customers slip away quietly.

The setup above moves the work to where it pays off: early, and tailored. The system gets in front of each renewal with enough lead time to actually have a conversation. It tailors the offer to the account — the plan that fits their usage, a discount sized to their loyalty and your margins. And critically, it stops short of sending. A renewal offer is a commercial promise; it should never leave the building without a person reading it. The drafter does the gathering and the first draft — the slow part — and leaves the judgment to you.

The next four posts walk through each piece in turn: how a renewal gets prepared, how an offer gets drafted, how the offer reaches the owner, and how a renewal gets sent or skipped. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts