Your company brain.
Built with you, owned by you.

use cases

Subscription renewals, kept before they lapse.

Every recurring contract, on one current record - failed payments recovered before service breaks, renewals priced fairly by rule, and churn named before it completes.

“Churn arrives as a number at month end with no name on it.”

§ 01 Is this you?

Is this you?

  • Churn arrives as a number at month end, and nobody can tell you which customers it was.
  • We lose customers to a failed card payment that nobody chased.
  • Renewal prices go out without anyone checking they are fair to the customers who stayed.
  • By the time someone cancels, the signs had been in the usage data for weeks.
  • Billing, product and service each see part of a customer leaving, and nobody sees all of it.

If two or more of these sound familiar, this is the use case to start with.

§ 02 Before and after

Before and after

today with a company brain
A card payment fails Service lapses, and the customer is gone before anyone notices the payment failed. The retry runs within the bounds you set and the customer is told, before any service breaks.
A renewal price is set The standard uplift goes out, and nobody checks it against what new customers pay. A renewal priced above what new customers pay is held, with the fairness evidence attached, before the customer sees it.
A customer starts to cancel Usage had been falling for weeks. The first anyone hears is the cancellation. The owner sees the decline and a save offer within the authority you set, and the exit stays as easy as the rules require.
Month end Churn is one number, with no names on it. Every lapse has a name, a reason and a record of what was done about it.
§ 03 What you would see

Illustrative: the shape of what you would receive, not a client's record.

What you would see

payment recovery

Card declined on the monthly billing run

what happened
A card payment failed at the start of a billing cycle.
history
Paid on time every cycle until now. Nothing suggests the customer meant to leave.
what it did
Ran the retry sequence within the agreed bounds, and asked the customer to update their card.
how sure
Sure this is a lapse nobody chose.
sources
The billing record, the payment history and the retry log, each linked.

act retry run, customer notified, logged

price hold

Renewal uplift held: above the new-customer price

what was queued
The standard uplift at renewal.
why it is held
It would charge this customer more than a new customer pays for the same plan.
evidence
The renewal price, today's new-customer price and the pricing rule, side by side.
recommends
Renew at or below the new-customer price.

recommend price held, routed to the pricing owner

save offer

Cancellation started after a cycle of falling use

what changed
Usage has been falling across the cycle, and the customer has just started to cancel.
recommends
A save offer within the authority you have set, or a clean exit if the customer has moved on.
limits
The exit stays as easy as the rules require. No offer stands in the way of cancelling.
how sure
Sure of the decline. Not sure of the reason.

recommend put to the retention owner

Every output says what it saw, why it matters, what it recommends and how sure it is, and links each fact to its source.

§ 04 How it works

How it works

  1. 01 it notices Declined payments, renewal dates and prices, falling usage and cancellations started, in billing, product and service, where they already land.
  2. 02 it connects Each signal to the contract it belongs to, and each contract to its customer, its payment history, its price and its owner.
  3. 03 it judges Whether a lapse was chosen, whether a renewal price is fair to a customer who stayed, and whether a save is worth offering.
  4. 04 it checks Every action against your rules and the pricing rules: retry bounds, offer authority, and what needs a signature before a customer sees it.
  5. 05 it acts Within the permission you have granted: it retries a failed payment where you allow it, and recommends or drafts everything else.

It reads from your billing, payments, CRM and product systems. It does not replace them, and nothing is migrated.

§ 05 What it runs on

The parts of a company brain subscription renewals relies on, in the framework's own terms.

What it runs on

01The record
Every recurring contract, with its price, payments, usage and renewal date, in one record.
02Finding the answer
Each question answered with its sources, or a plain "I can't answer that well".
03The company manual
Your pricing rules, retry limits and who may make a save offer, written down and owned.
04The way in for AI tools
How your people ask it from the AI assistant they already use, on the same permissions as everyone else.
05Connectors
Your billing system, payment provider, CRM and product usage.
06Who may see and do what
Who may see each customer and price, checked before every answer.
07Agents and actions
Retrying a failed payment within agreed limits, the one action allowed to run on its own, and drafting everything else for a person.
08Where people use it
Where the pricing and retention owners approve a price or an offer.
09Testing it on your own questions
Tested against your own past renewals and lapses before it is trusted.
the company brain keeping it trustworthy, under all of it your systems documents email, calendar business systems your ai tools your people namedsources checked,then kept checkedfirst read in your terms a question,and its answer approvals acting, througha second door 05 connectors 01 the record 06 who may see and do what 02 finding the answer 03 the company manual 04 the way in for ai tools 08 where people use it 07 agents and actions 09 testing on your questions 10 keeping it running 11 keeping every brain current 12 before anythingis built
The twelve parts of a company brain, with the ones subscription renewals runs on drawn in red. Read left to right: what comes in, what it knows, and who and what uses it.

what this shows about a company brain

It works through the AI tools you already use

Your people reach it from the assistant they already have, on the same permissions. They might ask:

“Which renewals this month would charge a customer more than a new customer pays?”

It compounds

It reads the same customer record as customer retention and cash collection, so a failed payment, falling usage and a service complaint are seen together.

It is yours

The record, the rules and the permissions it builds belong to you, not to a vendor: handed over to your team or run for you. The same company brain runs every use case you add.

§ 06 You stay in control

You stay in control

  1. observeIt reads silently and measures its own accuracy against what really happened.
  2. recommendIt puts the case and a proposed action to a named owner.
  3. draftIt prepares the action, and holds it for a person to sign.
  4. actIt acts within the bounds you set, and logs everything it does.

Each permission is granted or withheld, taken back as easily as it was given, and expires unless someone renews it. Everything starts at observe, and a permission is granted on the measured record, never on a promise. Every action is checked against your rules before anything goes out.

Renewal prices, save offers and win-backs wait for a named person's signature for as long as your policy and the pricing rules require; only the routine payment retry runs on its own, and only where you allow it.

§ 07 Where it starts

Where it starts

first scope
One product or one renewal cohort: the contracts where lapses cost you most.
how it proves itself
It runs at observe against your own past renewals and lapses first, so you see how it would have done before it is allowed to do anything.
what it connects to
The billing and product systems you already run, with your payment provider and CRM. Connectors are built for you, as part of the work. How it connects.
what you own
You own the result: the contract record, the rules and the permissions, handed over to your team or run for you.
§ 08 Questions

Questions

Does it replace our billing or subscription management system?
No. It reads from it, and from your payment provider, product and service systems. Billing keeps doing the billing; the company brain reads what it holds alongside everything else.
Our billing tool already retries failed cards. What is different?
The retry is the small part. Here a failed payment is read with the customer's history, usage and renewal date, so a lapse nobody chose is recovered, and one that was chosen is seen for what it is.
Who can see what?
Only what each person is allowed to see. Permissions are checked before every answer, and every question is recorded.
Will it change a price or contact a customer on its own?
Only the routine payment retry and its notice, within bounds you set, and only if you grant that permission. Prices, save offers and win-backs wait for a named owner to sign.
Is this available today?
It is built for each company that runs it, on that company's own brain, not installed off a shelf. The question audit comes first and shows what it would and would not do for you before anything is built.
§ 09 Start

Start

try this on your own record

Take three past churns: one you saw coming, one lost to a failed payment nobody chased, and one renewal whose price nobody checked. What did your own record know, and when did you find out?

Questions like this are what the question audit answers: about two hundred real questions from your business, each answered in writing, so you know what subscription renewals on a company brain would and would not do for you before anything is built. It is a small fixed fee, credited against the build or the service if you go ahead.

book a discovery call → take the diagnostic · 10 min (opens in a new tab)