Skip to content
← Processes

Expand accounts from usage

Each morning, accounts near a plan limit or on a feature their plan lacks get an offer priced on your packaging rules, an expansion deal and a drafted proposal.

PostHog→Stripe→HubSpot→Linear→Granola→Gmail→Slack
Starts
Daily schedule
Steps
7
Checks and gates
0
A person decides
Never, runs alone

Trigger · Schedule

Daily schedule

Each morning the run reads every paying account's usage, so an account that crossed a limit yesterday has a proposal waiting today.

Claude runs the rest autonomously

  1. 1

    AI lists accounts near a limit or ons a new feature.

    PostHog

    PostHog

    Accounts close to a plan limit, using a feature their plan does not include, or growing fast enough to reach a limit soon come back with the numbers behind it.

  2. 2

    AI pulls the plan, seats and renewal date.

    Stripe

    Stripe

    What each account pays, how many seats it bought and when it renews come back, with its owner, its success manager and any open deal.

    HubSpot

    HubSpot

  3. 3

    AI checks open incidents and the last call.

    Linear

    Linear

    An open incident, or a complaint on the last call, comes back, because an account with a problem is not an account to sell to this morning.

    Granola

    Granola

  4. 4

    AI chooses the offer from your packaging rules.

    Your own packaging and pricing decide what to propose, more seats, the next plan or the add-on, at the rule's price, and an account with a problem or a renewal within reach is held.

  5. 5

    AI routes each offer to success or sales.

    Your handoff rules decide who carries each offer, the success manager for a seat top-up or a rep for a plan change above the line you set.

  6. 6

    AI drafts the proposal with their own numbers.

    Gmail

    Gmail

    A proposal waits as a draft on the account's thread with the usage that triggered it, the offer and what it costs under your rules, never sent.

  7. 7

    AI opens the deals, notifies the owners.

    HubSpot

    HubSpot

    An expansion deal opens on each account with the offer and its evidence, and each owner gets one message with the accounts they are carrying today.

    Slack

    Slack

The accounts most likely to pay you more this quarter are already telling you so, in the product. One is at 94% of its seats. One has been using a feature its plan does not include since a trial that never ended. One doubled its volume in six weeks and will hit the limit in May. Nobody sees this, because usage lives in analytics, what they pay lives in billing, and the person who could make the offer lives in a CRM that knows neither. The expansion comes up at renewal, eight months late, as a price increase nobody prepared.

Each of those numbers is recorded somewhere. Usage against the limit is in analytics. The plan, the seats and the renewal date are in billing. Open incidents are in the tracker and the last call is in the recorder. Your packaging, your prices and your rule for who carries an expansion are written down. The run reads them together every morning, and the proposal is drafted before the account notices the limit.

What you get

An account that outgrows its plan has an expansion deal open and a proposal drafted with its own numbers before the team starts the day, priced under your packaging rules, held when an incident is open or a renewal is close, and carried by the person your rules say should carry it.

What an expansion is read against

The run opens every morning on every paying account. It reads:

  • Usage, from PostHog: accounts above your threshold of a plan limit, using a feature their plan does not include, or growing fast enough to reach a limit within two months, each with the limit, where it stands and the trend.
  • The plan, from Stripe: what the account pays, seats or units bought, any discount, and the renewal date.
  • The account, in HubSpot: its owner, its success manager and any open deal, since an account with an expansion already open leaves the list.
  • Problems, from Linear and Granola: an open incident and how long it has been open, and anything on the last call that was a complaint, a threat to leave or a request still unanswered.

The proposal is drafted in Gmail and the owners hear about it in Slack.

What makes usage-based upsell hold up

The offer comes from your packaging, and nothing is priced without it. What each plan includes, what the next one adds, which add-ons exist, the unit prices and the rule for pricing mid-term are read for every account, and the deal carries the rule that priced it. Where no packaging rules are written down the run decides nothing, lists the accounts and their numbers for their owners, and says that it found no rules. An agent that invents a price list is a support ticket.

An account with a problem is not sold to. An incident open, a complaint on the last call or a renewal within sixty days holds the account with the reason, and its renewal's owner is told instead: those are a renewal conversation, not an expansion, and an upsell email landing during an outage is the message every customer remembers. Support hears about any held account with an incident, so they know the account outgrowing its plan is also the one they are fixing.

Who carries the deal is your rule too. A seat top-up on the same plan and a plan change above a line you set go to different people in most teams, and the handoff line is argued about in all of them. The run reads the rule, names it on the deal and drafts the proposal from the person it chose, so the first contact comes from whoever will carry the conversation.

A proposal in the account's own numbers

The draft sits on the account's existing thread: the usage that triggered it, in the account's own numbers; what the offer is and what it covers; what it costs under your rules and from when; and one line on what happens at the limit otherwise. No feature pitch. It is created as a draft and never sent.

The expansion deal exists before the owner opens Slack, with the amount, the offer, the usage behind it and both rules on it, and nothing on the account's existing deals is touched. Each person with deals that morning gets one message with their accounts, the offer and amount on each, and where the drafts are.

The prompt

The real prompt behind the steps above, detailed enough that an agent with the same tools can run it as written. The Run buttons copy the full version, which also carries the steps for connecting those tools.

# Expand accounts from usage

You have access to product analytics, a billing system, a CRM, an
issue tracker, a call-recording tool, an email account, and a
messaging tool. Run this every morning for **[every paying
account]**.


## 1. List accounts near a limit or on a new feature

From product analytics, over the last **[thirty days]**, list every
account that is

- above **[your threshold, for example 80%]** of a limit its plan
  carries: seats, volume, projects, whatever your plans meter;
- using a feature its plan does not include, through a trial, an
  override or a loophole;
- growing at a rate that reaches a limit within **[sixty days]**.

For each, keep the numbers: the limit, where they are against it,
and the trend. An account is listed once with every reason that
applies. Nothing else about the account is read yet.

## 2. Pull the plan, seats and renewal date

From billing, read what each listed account pays: plan, seats or
units bought, price, any discount applied, and the renewal date.
From the CRM, read the account's owner, its success manager, and any
open deal on it.

An account with an open expansion deal already leaves the list here:
the run reports it and does nothing, since the deal's owner is
already on it.

## 3. Check open incidents and the last call

From the issue tracker, read any open incident or bug the account is
attached to, and how long it has been open. From the call recorder,
read the summary of the last call with the account and keep anything
that was a complaint, a threat to leave, or a request still
unanswered.

An account with a problem is not an account to sell to this morning,
and this step is where the run learns which ones those are.

## 4. Choose the offer from your packaging rules

Read each account against **[your packaging and pricing: what each
plan includes, what the next plan adds, which add-ons exist, seat and
unit prices, and the rules for pricing an expansion mid-term]**.

- Decide the offer: more seats or units on the same plan, the next
  plan, or the add-on that covers the feature they are using. Price
  it under your rules, pro-rated to the renewal date where your rules
  say so. Name the rule.
- Hold any account with an incident open, a complaint on the last
  call, or a renewal within **[sixty days]**: those are a renewal
  conversation, not an expansion, and the renewal's owner is told in
  step 7. Say why each one is held.
- Make no offer where the overage is small enough that your rules
  say to let it run, and say so.

If no packaging rules are written down, decide nothing: list the
accounts and their numbers for the owners in step 7, and report that
no rules were found.

## 5. Route each offer to success or sales

Read each offer against **[your handoff rules: what the success
manager carries, what goes to a rep, and the line between them]**.
A seat top-up on the same plan goes one way, a plan change above the
line goes the other, and the rule is named.

## 6. Draft the proposal with their own numbers

For each offer, draft an email from the person step 5 chose, on the
account's existing thread where one exists: the usage that triggered
it, in the account's own numbers; what the offer is and what it
covers; what it costs under your rules and from when; one line on
what happens at the limit otherwise. No feature pitch. **Create it as
a draft. Never send it.**

## 7. Open the deals, notify the owners

Create an expansion deal on each account with an offer: the amount,
the offer, the usage behind it, the rule that priced it and the rule
that routed it, with the chosen person as owner. Change nothing on
the account's existing deals.

Post one message to each person with deals today: the accounts, the
offer and amount on each, and where the drafts are. Post one line to
the owner of each held account: the usage, and why it is held. Post
one line to support for any held account with an incident open, so
they know the account is also outgrowing its plan.

## Output

Report: accounts listed and why, accounts with an expansion already
open, accounts held and why, the offer and price per account with the
rule, the owner per offer with the rule, the deals created with their
amounts, and the drafts waiting.

Why run it with Tulina

A prompt helps one person. A process moves a team.

Pasted into a chat, the prompt above works once, for whoever pasted it. In Tulina, "Expand accounts from usage" becomes a process the team shares, that keeps its history, runs on its own, and stays inside the same security perimeter as the tools it calls.

  • The whole team works on the same one

    PersonalTeamOrganisation

    A process lives where it belongs: yours, your team's or the whole organisation's. Whoever runs it can improve it, and everyone starts from the best version instead of explaining the job again.

  • Every edit is a version

    v1v2v3

    Each change is a new version with the previous one kept, so a bad edit is undone by restoring an earlier one. Every run records the version it followed, and what a run teaches goes back into the process.

  • It runs without you

    schedulewebhookon demand

    A hosted agent runs the process on Tulina's own infrastructure, on a schedule or when an event arrives, and keeps going when you close the chat. Nothing to host. Every run is tracked to its outcome.

  • Inside the same security perimeter

    vaultrolesrun log

    Credentials stay in the vault, never in the prompt. Roles decide who may run what, every call is logged, and a step a person has to approve waits for that person.

Questions about AI upsell from product usage

Yes, from the numbers the product already records: accounts above a threshold of a plan limit, accounts using a feature their plan does not include, and accounts growing fast enough to reach a limit within two months. Each is listed with the limit, where it stands and the trend, and read against billing before anything is proposed.

From your own packaging and pricing: what each plan includes, what the next one adds, which add-ons exist, unit prices and the rule for pricing mid-term. The offer is more seats, the next plan or the add-on, priced under those rules and pro-rated where they say so. With no packaging rules written down the run decides nothing and lists the accounts for their owners instead.

When the account has an incident open, a complaint on its last call, or a renewal within sixty days. Those accounts are held with the reason, their renewal's owner is told, and support hears about any held account with an incident, because an account with a problem is a renewal conversation and not an expansion.

Your handoff rules decide, and the run only applies them: a seat top-up on the same plan goes to the success manager and a plan change above the line you set goes to a rep, with the rule named on the deal. The proposal is drafted from that person and never sent, so whoever carries the deal also makes the first contact.

Other processes that run mainly on HubSpot. The tools they share with this one are lit.

See Tulina in a 30-minute demo.

Book a demo