Skip to content
← Processus

Développer les comptes à partir de l'usage

Chaque matin, les comptes proches d'une limite sont lus avec la facturation, les incidents et le dernier appel, chiffrés selon vos règles et ouverts en deals d'expansion.

PostHog→Stripe→HubSpot→Linear→Granola→Gmail→Slack
Démarre
Planification quotidienne
Étapes
7
Contrôles et conditions
0
Une personne décide
Jamais, tourne seul

Déclencheur · Planifié

Planification quotidienne

Chaque matin l'exécution lit l'usage de chaque compte payant, pour qu'un compte qui a franchi une limite hier ait une proposition prête aujourd'hui.

Claude exécute la suite en autonomie

  1. 1

    Lister les comptes proches d'une limite ou sur une nouveauté

    PostHog

    PostHog

    Les comptes proches d'une limite de plan, qui utilisent une fonctionnalité hors plan ou qui croissent assez vite pour atteindre une limite bientôt reviennent avec les chiffres derrière.

  2. 2

    Récupérer le plan, les sièges et la date de renouvellement

    Stripe

    Stripe

    Ce que paie chaque compte, combien de sièges il a achetés et quand il renouvelle reviennent, avec son responsable, son customer success manager et tout deal ouvert.

    HubSpot

    HubSpot

  3. 3

    Vérifier les incidents ouverts et le dernier appel

    Linear

    Linear

    Un incident ouvert, ou une plainte lors du dernier appel, revient, parce qu'un compte avec un problème n'est pas un compte à qui vendre ce matin.

    Granola

    Granola

  4. 4

    Choisir l'offre selon vos règles de packaging

    Votre propre packaging et vos prix décident quoi proposer, plus de sièges, le plan suivant ou le module, au prix de la règle, et un compte avec un problème ou un renouvellement proche est retenu.

  5. 5

    Router chaque offre vers le CS ou les sales

    Vos règles de passage de relais décident qui porte chaque offre, le customer success manager pour un ajout de sièges ou un commercial pour un changement de plan au-dessus de la ligne que vous fixez.

  6. 6

    Rédiger la proposition avec leurs propres chiffres

    Gmail

    Gmail

    Une proposition attend en brouillon sur le fil du compte avec l'usage qui l'a déclenchée, l'offre et ce qu'elle coûte selon vos règles, jamais envoyée.

  7. 7

    Ouvrir les deals, prévenir les responsables

    HubSpot

    HubSpot

    Un deal d'expansion s'ouvre sur chaque compte avec l'offre et ses preuves, et chaque responsable reçoit un message avec les comptes qu'il porte aujourd'hui.

    Slack

    Slack

Les comptes les plus susceptibles de vous payer davantage ce trimestre vous le disent déjà, dans le produit. L'un est à 94 % de ses sièges. L'un utilise une fonctionnalité que son plan n'inclut pas depuis un essai qui n'a jamais pris fin. L'un a doublé son volume en six semaines et atteindra la limite en mai. Personne ne le voit, parce que l'usage vit dans les analytics, ce qu'ils paient dans la facturation, et la personne qui pourrait faire l'offre dans un CRM qui ne connaît ni l'un ni l'autre. L'expansion arrive au renouvellement, huit mois trop tard, comme une hausse de prix que personne n'a préparée.

Chacun de ces chiffres est enregistré quelque part. L'usage face à la limite est dans les analytics. Le plan, les sièges et la date de renouvellement sont dans la facturation. Les incidents ouverts sont dans le tracker et le dernier appel dans l'enregistreur. Votre packaging, vos prix et votre règle sur qui porte une expansion sont écrits. L'exécution les lit ensemble chaque matin, et la proposition est rédigée avant que le compte remarque la limite.

What you get

Un compte qui dépasse son plan a un deal d'expansion ouvert et une proposition rédigée avec ses propres chiffres avant que l'équipe commence sa journée, chiffrée selon vos règles de packaging, retenue quand un incident est ouvert ou un renouvellement proche, et portée par la personne que vos règles désignent.

Au regard de quoi une expansion est lue

L'exécution démarre chaque matin sur chaque compte payant. Elle lit :

  • L'usage, depuis PostHog : les comptes au-dessus de votre seuil d'une limite de plan, qui utilisent une fonctionnalité hors plan, ou qui croissent assez vite pour atteindre une limite sous deux mois, chacun avec la limite, où il en est et la tendance.
  • Le plan, depuis Stripe : ce que paie le compte, les sièges ou unités achetés, toute remise, et la date de renouvellement.
  • Le compte, dans HubSpot : son responsable, son customer success manager et tout deal ouvert, car un compte avec une expansion déjà ouverte quitte la liste.
  • Les problèmes, depuis Linear et Granola : un incident ouvert et depuis combien de temps, et tout ce qui lors du dernier appel était une plainte, une menace de partir ou une demande restée sans réponse.

La proposition est rédigée dans Gmail et les responsables l'apprennent dans Slack.

Ce qui rend l'upsell par l'usage fiable

L'offre vient de votre packaging, et rien n'est chiffré sans lui. Ce que chaque plan inclut, ce que le suivant ajoute, quels modules existent, les prix unitaires et la règle de chiffrage en cours de contrat sont lus pour chaque compte, et le deal porte la règle qui l'a chiffré. Sans règles de packaging écrites, l'exécution ne décide rien, liste les comptes et leurs chiffres pour leurs responsables, et dit qu'elle n'a trouvé aucune règle. Un agent qui invente une grille tarifaire est un ticket au support.

On ne vend pas à un compte qui a un problème. Un incident ouvert, une plainte lors du dernier appel ou un renouvellement sous soixante jours retient le compte avec la raison, et le responsable de son renouvellement est prévenu à la place : c'est une conversation de renouvellement, pas une expansion, et un email d'upsell qui arrive pendant une panne est le message dont chaque client se souvient. Le support apprend tout compte retenu avec un incident, pour savoir que le compte qui dépasse son plan est aussi celui qu'il est en train de réparer.

Qui porte le deal est votre règle aussi. Un ajout de sièges sur le même plan et un changement de plan au-dessus d'une ligne que vous fixez vont à des personnes différentes dans la plupart des équipes, et la ligne de passage de relais fait débat dans toutes. L'exécution lit la règle, la nomme sur le deal et rédige la proposition depuis la personne choisie, pour que le premier contact vienne de celui qui portera la conversation.

Une proposition dans les chiffres du compte

Le brouillon est sur le fil existant du compte : l'usage qui l'a déclenché, dans les chiffres du compte ; ce qu'est l'offre et ce qu'elle couvre ; ce qu'elle coûte selon vos règles et à partir de quand ; et une ligne sur ce qui se passe à la limite sinon. Pas de pitch fonctionnel. Il est créé en brouillon et jamais envoyé.

Le deal d'expansion existe avant que le responsable ouvre Slack, avec le montant, l'offre, l'usage derrière et les deux règles dessus, et rien n'est touché sur les deals existants du compte. Chaque personne qui a des deals ce matin-là reçoit un message avec ses comptes, l'offre et le montant sur chacun, et où sont les brouillons.

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.

Pourquoi le faire tourner avec Tulina

Un prompt aide une personne. Un processus fait avancer une équipe.

Collé dans une conversation, le prompt ci-dessus marche une fois, pour celui qui l'a collé. Dans Tulina, « Développer les comptes à partir de l'usage » devient un processus que l'équipe partage, qui garde son historique, qui tourne seul, et qui reste dans le même périmètre de sécurité que les outils qu'il appelle.

  • Toute l'équipe travaille sur le même

    PersonnelÉquipeOrganisation

    Un processus se range à l'endroit qui lui correspond : à vous, à votre équipe ou à toute l'organisation. Celui qui l'exécute peut l'améliorer, et tout le monde repart de la meilleure version au lieu de réexpliquer le travail à chaque fois.

  • Chaque modification est une version

    v1v2v3

    Chaque changement crée une nouvelle version et garde la précédente ; une mauvaise modification se défait en restaurant une version antérieure. Chaque exécution enregistre la version qu'elle a suivie, et ce qu'elle a appris revient dans le processus.

  • Il tourne sans vous

    planifiéwebhookà la demande

    Un agent hébergé exécute le processus sur l'infrastructure de Tulina, à heure fixe ou quand un événement arrive, et continue quand vous fermez la conversation. Rien à héberger. Chaque exécution est suivie jusqu'à son résultat.

  • Dans le même périmètre de sécurité

    coffrerôlesjournal

    Les identifiants restent dans le coffre, jamais dans le prompt. Les rôles décident qui peut lancer quoi, chaque appel est journalisé, et une étape qu'une personne doit valider attend cette personne.

Questions sur l'upsell par IA à partir de l'usage produit

Oui, à partir des chiffres que le produit enregistre déjà : les comptes au-dessus d'un seuil d'une limite de plan, les comptes qui utilisent une fonctionnalité que leur plan n'inclut pas, et les comptes qui croissent assez vite pour atteindre une limite sous deux mois. Chacun est listé avec la limite, où il en est et la tendance, et lu avec la facturation avant toute proposition.

À partir de votre propre packaging et de vos prix : ce que chaque plan inclut, ce que le suivant ajoute, quels modules existent, les prix unitaires et la règle de chiffrage en cours de contrat. L'offre est plus de sièges, le plan suivant ou le module, chiffrée selon ces règles et au prorata quand elles le disent. Sans règles de packaging écrites, l'exécution ne décide rien et liste les comptes pour leurs responsables.

Quand le compte a un incident ouvert, une plainte lors de son dernier appel, ou un renouvellement sous soixante jours. Ces comptes sont retenus avec la raison, le responsable de leur renouvellement est prévenu, et le support apprend tout compte retenu avec un incident, parce qu'un compte avec un problème est une conversation de renouvellement et non une expansion.

Vos règles de passage de relais décident, et l'exécution ne fait que les appliquer : un ajout de sièges sur le même plan va au customer success manager et un changement de plan au-dessus de la ligne que vous fixez va à un commercial, avec la règle nommée sur le deal. La proposition est rédigée depuis cette personne et jamais envoyée, pour que celui qui porte le deal fasse aussi le premier contact.

D'autres processus qui tournent surtout sur HubSpot. Les outils partagés avec celui-ci sont allumés.

Découvrez Tulina en 30 minutes.

Réserver une démo