Skip to content
allanninal.dev/build
Collaborate

Part 5 of 7 · Subscription audit bot series ~5 min read

How the renewal question works

The temptation with a system that can see every recurring charge is to report on all of them, regularly. That instinct is exactly wrong, and resisting it is the difference between a tool people act on and a monthly email that goes to a folder. This post is about restraint as a design feature.

Key takeaways

  • One question per subscription per year, whatever its billing interval.
  • Timed for thirty days before renewal, because that is when the answer can change something.
  • The message quotes last year’s answer, which makes “keep” a real decision rather than inertia.
  • Three buttons: keep, drop, and I do not know what this is.
  • A monthly digest exists but carries only what changed — never the full list.

Once a year, thirty days out

How a renewal question is scheduled, sent and recordedThree boxes across the top outside the AWS account. The Owner, who gets one question a year. Whoever pays, who gets a monthly digest. And the Owner tab, where answers are written back. Inside the account, three components. The Scheduler, which fires thirty days before the next expected renewal. The Question builder, which composes the annual figure and last year's answer. And the Recorder, which stores what was decided and when. Arrows show the owner replying keep, drop or unknown, whoever pays receiving only what changed, and answers being written back to the tab. A note says a monthly subscription is asked about once a year, not twelve times.AWS ACCOUNTOwnerone question a yearWhoever paysa monthly digestOwner tabanswers written backSchedulernext renewal,minus 30 daysQuestion builderannual figure,last year's answerRecorderwhat was decided,and whenkeep / drop /unknownonly what changedwritten backA monthly subscription is asked about once a year, not twelve times.
Fig 1. The asking machinery. The scheduler is the whole system’s restraint mechanism: it fires on renewal dates, not on a reporting cadence.
  • App integration
  • Management
  • People

Why thirty days

Close enough to the renewal that the decision is live, far enough out that cancelling is still possible without arguing about a refund. Many annual software contracts have a notice period of exactly thirty days, which is not a coincidence — asking on the renewal date is asking after the deadline, and asking three months out gets “remind me nearer the time”, which nobody ever does.

For a monthly subscription there is no meaningful renewal date, so the anniversary of the first charge is used. It is arbitrary, and being arbitrary is fine; what matters is that it happens once a year on a predictable date rather than every month.

What the message says

The whole message, in order

  • Line one. The product and the annual cost. “PROJTOOL — £172.80 a year (£14.40/month), on the card ending 4417.”
  • Line two. How long, and the trend. “Charged since September 2024. Up 19% on last year.”
  • Line three, if there is one. What was said last time. “Last July you said: keep — used for the client portal project.”
  • Three buttons. “Keep it” · “We should drop this” · “I don’t know what this is”.
  • The raw statement line, in small text at the bottom. It is often what makes somebody recognise it.

Quoting last year’s answer

This is the line that does the most work and is easiest to leave out. A bare renewal question invites the path of least resistance, which is “keep”. The same question with “last July you said: keep — used for the client portal project” underneath it invites a second thought, because the client portal project finished in November. It costs one extra sentence and it converts inertia into a decision roughly one time in five.

The third button

“I don’t know what this is” has to be there and has to be as prominent as the other two. Without it, a person who does not recognise a charge will pick “keep”, because picking “drop” on something you cannot identify feels risky. With it, the subscription moves to unowned, goes into the monthly digest, and gets in front of somebody else — which is exactly the right outcome and is unreachable from a two-button design.

The monthly digest, and what is not in it

Whoever pays the bills gets one message a month, and it deliberately does not contain the list of subscriptions. It contains only changes: new subscriptions detected, price rises, subscriptions that stopped charging, and anything currently unowned.

The five lines of the monthly subscription digestA horizontal row of five boxes. New: two subscriptions detected. Price rises: three, worth four hundred and ten pounds a year more. Stopped: one, worth checking whether it was intended. Unowned: four still open. Total: thirty-one thousand four hundred pounds a year, up two per cent. A note says five lines, and that the full list of fifty-two subscriptions is a link rather than the message.THE MONTHLY DIGESTNew2 detectedPrice rises3, +£410/yrStopped1, check if intendedUnowned4 still openTotal£31,400/yr, +2%Five lines. The full list of 52 subscriptions is a link, not the message.
Fig 2. The monthly digest: only what changed, plus one running total. The full inventory is available and is deliberately not the message.
  • Security & identity
  • Management
  • Analytics

The running total is the one thing that is not a change, and it earns its place because it is the number the business could not previously state. Watching it move two per cent in a month is a different relationship with software spend from discovering it once a year during budgeting.

Next: what all of this costs to run.

All posts