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.
- 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
Lister les comptes proches d'une limite ou sur une nouveauté
PostHogPostHog
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
Récupérer le plan, les sièges et la date de renouvellement
StripeStripe
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.
HubSpotHubSpot
- 3
Vérifier les incidents ouverts et le dernier appel
LinearLinear
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.
GranolaGranola
- 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
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
Rédiger la proposition avec leurs propres chiffres
GmailGmail
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
Ouvrir les deals, prévenir les responsables
HubSpotHubSpot
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.
SlackSlack
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
Aussi sur HubSpot
D'autres processus qui tournent surtout sur HubSpot. Les outils partagés avec celui-ci sont allumés.
Suivre les champions qui changent de poste
Chaque semaine, les champions de vos comptes gagnés sont vérifiés pour un nouvel employeur, la nouvelle entreprise notée selon votre ICP, et un deal chaud s'ouvre avec une note.
- Partage
- HubSpot, PostHog, Granola, Gmail
Planification hebdomadaire7 étapes →
Hygiène CRM et changements de poste des prospects
Doublons fusionnés et champs corrigés chaque semaine, prospects ayant changé de poste suivis jusqu'à leur nouvelle entreprise, et un récapitulatif publié à l'équipe.
- Partage
- HubSpot, Slack
Rythme hebdomadaire4 étapes →
De l'écoute sociale aux leads qualifiés
Chaque matin, ceux qui réagissent aux posts d'un concurrent et les entreprises qui lisent votre site sont rapprochés du CRM, qualifiés sur votre ICP et remis à leur commercial.
- Partage
- HubSpot, Slack
Planification quotidienne7 étapes →