What is a renewal negotiator?

A small serverless system that helps you keep customers at renewal time. Ahead of each contract or subscription renewal it gathers what it knows — current terms, usage, and history — drafts a tailored renewal offer in your voice with the right plan and any discount inside your rules, and hands it to the owner to approve, edit, or skip before it goes to the customer. It only prepares the offer; a human always sends and can always override.

Does it send offers to customers on its own?

No. The system never sends anything by itself. It prepares a draft offer and puts it in an approval queue. The owner reads it, then approves and sends, edits first, or skips it entirely. Nothing reaches a customer without a person pressing send. Discounts are capped at limits you set, so a draft can never offer more than your rules allow.

How much does it cost to run?

About $3/month at typical small-business volume (around 100 accounts renewing across a year). The fixed cost is essentially zero. The variable cost is dominated by the daily check that reads accounts plus the one Bedrock draft per upcoming renewal. At 1,000 accounts the bill lands around $14.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the approve and skip buttons, EventBridge Scheduler for the daily check and deferred sends, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 for drafting, Claude Sonnet 4.6 for tricky accounts) via Global cross-Region inference. No API Gateway, no NAT Gateway, no always-on compute.

Where do the accounts and rules live?

In a Google Sheet in a Drive folder you control. One row per account with name, plan, current price, renewal date, usage signal, owner email, and history. A rules doc holds your plan menu, your discount caps per tier, and your voice — the tone the drafts should use. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes so the system reads from S3 and gets versioning for free.

How does it decide what to offer?

Plain Python picks the plan and the discount band from your rules doc based on the account's tier, usage, and history — a heavy user near a plan ceiling gets an upgrade suggestion; a price-sensitive small account gets a modest loyalty discount inside the cap. Then Bedrock writes the offer in your voice. The model never sets the price or the discount; it only phrases an offer the rules already decided. Every number is checked against your caps before the draft is queued.

What can I do with a drafted offer?

Three buttons on every draft: Approve & send (the offer goes to the customer via your email, and the account is marked offered), Edit (open the draft in a modal, change wording, plan, or discount within the cap, then send), and Skip (this account gets no offer this cycle — useful when you'll handle it by hand or the customer already churned). Every action is recorded in the rn-audit table with timestamp, account, action, by-user, and a before-and-after snapshot, so the trail is auditable for years.

Series · 7 parts Published June 13, 2026

Renewal negotiator

A serverless helper that keeps customers at renewal time. Ahead of each contract or subscription renewal it gathers what it knows — current terms, usage, and history — drafts a tailored renewal offer in your voice with any discount inside your rules, and hands it to you to approve, edit, or skip before it ever reaches the customer. It only prepares the offer; a human always sends and can always override. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A renewal negotiator on AWS for a few dollars a month

The whole system on one page — an account intake, a drafter, and an approval queue, plus the rule that the system only ever prepares an offer and never sends one itself.
02

How a renewal gets prepared

Three lanes feed the account registry — the Drive sheet itself, an inbox-forwarding lane that parses contracts and usage exports into proposed rows, and an hourly calendar import for renewal dates tagged #renews.
03

How a renewal offer gets drafted

Plain Python picks the plan and the discount band from your rules; Bedrock then writes the offer in your voice. The model never sets a price or a discount — it only phrases what the rules already decided.
04

How a renewal offer reaches the owner

Owner resolution per account, a discount-cap check that nothing skips, quiet hours, and the four guardrails between a freshly drafted offer and the moment it lands in your approval queue.
05

How a renewal gets sent or skipped

Three actions on every draft: approve & send (the offer goes to the customer), edit (change wording, plan, or discount within the cap, then send), and skip (no offer this cycle). Every action is logged.
06

What the renewal negotiator costs

A few dollars a month at SMB volume. The daily check reads accounts with no model; Bedrock fires only when a renewal comes due and a draft is needed, plus the monthly summary.
07

Engineering reference: the renewal negotiator architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, EventBridge Scheduler config, and the DynamoDB schemas.

What is a renewal negotiator?: A small serverless system that helps you keep customers at renewal time. Ahead of each contract or subscription renewal it gathers what it knows — current terms, usage, and history — drafts a tailored renewal offer in your voice with the right plan and any discount inside your rules, and hands it to the owner to approve, edit, or skip before it goes to the customer. It only prepares the offer; a human always sends and can always override.
Does it send offers to customers on its own?: No. The system never sends anything by itself. It prepares a draft and puts it in an approval queue. The owner reads it, then approves and sends, edits first, or skips it entirely. Nothing reaches a customer without a person pressing send. Discounts are capped at limits you set, so a draft can never offer more than your rules allow.
How much does it cost to run?: About $3/month at typical small-business volume (around 100 accounts renewing across a year). The fixed cost is essentially zero. The variable cost is dominated by the daily check that reads accounts plus the one Bedrock draft per upcoming renewal. At 1,000 accounts the bill lands around $14.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the approve and skip buttons, EventBridge Scheduler for the daily check and deferred sends, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 for drafting, Claude Sonnet 4.6 for tricky accounts) via Global cross-Region inference. No API Gateway, no NAT Gateway, no always-on compute.
Where do the accounts and rules live?: In a Google Sheet in a Drive folder. One row per account with name, plan, current price, renewal date, usage signal, owner email, and history. A rules doc holds your plan menu, your discount caps per tier, and your voice. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes so the system reads from S3 and gets versioning for free.
How does it decide what to offer?: Plain Python picks the plan and the discount band from your rules doc based on the account’s tier, usage, and history — a heavy user near a plan ceiling gets an upgrade suggestion; a price-sensitive small account gets a modest loyalty discount inside the cap. Then Bedrock writes the offer in your voice. The model never sets the price or the discount; it only phrases an offer the rules already decided. Every number is checked against your caps before the draft is queued.
What can I do with a drafted offer?: Three buttons on every draft: Approve & send sends the offer to the customer via your email and marks the account offered; Edit opens the draft in a modal to change wording, plan, or discount within the cap, then send; Skip means no offer this cycle. Every action is recorded in the rn-audit DynamoDB table with timestamp, account, action, by-user, and a before-and-after snapshot, so the trail is auditable for years.

All posts

Frequently asked questions

Other series