Préparer un appel client
Avant l'appel, les dernières conversations, l'état du compte, comment le produit est réellement utilisé, et où en sont les fonctionnalités demandées, dans un seul brief.
- Démarre
- Réunion client au calendrier
- Étapes
- 5
- Contrôles et conditions
- 0
- Une personne décide
- Jamais, tourne seul
Déclencheur · Agenda
Réunion client au calendrier
La prochaine réunion client au calendrier déclenche l'exécution, chronométrée pour que le brief soit prêt avant que quiconque ne rejoigne.
Claude exécute la suite en autonomie
- 1
Citer les demandes des appels passés
GranolaGranola
Les appels enregistrés sont trouvés par entreprise autant que par participant, et chaque demande revient dans les mots exacts du client.
- 2
Récapituler le plan, le renouvellement et les contacts
AttioAttio
Le plan, la date de renouvellement et les contacts reviennent, avec toute personne ayant parlé lors d'appels passés mais absente du dossier signalée.
- 3
Comparer l'usage avec ce qui a été dit
PostHogPostHog
Les utilisateurs actifs sur le trimestre et les fonctionnalités abandonnées reviennent, mis en regard de ce qui a été dit la dernière fois.
- 4
Donner à chaque demande son statut
LinearLinear
Chaque demande est associée à son ticket sur le fond plutôt que sur le mot à mot, et celles sans aucun ticket sont nommées.
- 5
Publier le brief, le plus gros risque en premier
SlackSlack
Le brief s'ouvre sur une baisse d'usage, un champion parti, un engagement manqué ou un renouvellement proche, avec le détail en dessous.
Préparer un appel client, c'est quatre systèmes et une vingtaine de minutes, donc en pratique c'est un système et environ deux minutes. Quelqu'un ouvre le CRM, voit le plan et la date de renouvellement, survole le dernier fil d'emails, et entre en appel. Ce qu'il n'a pas, c'est si le compte a utilisé le produit depuis la dernière conversation. Ce seul fait décide comment l'appel doit se dérouler.
Les quatre systèmes enregistrent déjà la réponse. Les appels sont transcrits, le compte est dans le CRM, l'usage est dans les analytics, et les demandes de fonctionnalités sont des tickets avec des statuts. Personne ne les relie parce que les relier veut dire ouvrir quatre onglets avant chaque appel, chaque semaine, indéfiniment.
What you get
One brief in the channel before every customer call, joining what they said last time with what they have actually been doing since and where their requests now stand.
Sur quoi le brief d'appel client est construit
L'exécution s'ouvre depuis la prochaine réunion client sur Google Calendar, chronométrée pour que le brief soit prêt avant que quiconque ne rejoigne. Elle lit quatre systèmes, chacun pour une question que les autres ne peuvent pas répondre :
- Les appels passés, depuis Granola, trouvés par email du participant et séparément par domaine d'entreprise, puisqu'un appel est enregistré par qui l'a organisé. Seul ce qui reste pertinent est gardé : ce qui a été demandé et si c'était promis, ce sur quoi chaque partie s'est engagée avec une date, et toute plainte avec si elle a été résolue. Les demandes sont citées avec les mots exacts du client.
- Le dossier du compte, depuis Attio : plan, date de renouvellement, propriétaire, opportunités ouvertes et historique de support. Toute personne apparue lors d'appels passés mais absente du dossier a probablement quitté l'entreprise, et un champion parti est la ligne la plus importante qu'un brief puisse porter.
- L'usage produit, depuis PostHog : utilisateurs actifs hebdomadaires sur le dernier trimestre et leur tendance, quelles fonctionnalités le compte utilise et lesquelles il a arrêté d'utiliser, et s'il utilise ce pour quoi il a acheté le produit ou seulement les marges.
- Le statut des demandes, depuis Linear : pour chaque demande trouvée dans les appels, si elle a été livrée, est en cours avec une cible, se trouve dans le backlog, ou a été refusée.
Le brief est publié sur Slack avant la réunion.
Ce qui fait tenir la préparation d'appel client
La contradiction entre ce qui a été dit et ce qui a été fait est la ligne la plus précieuse du brief, et aucun système seul ne peut la produire. « On va le déployer sur toute l'équipe le mois prochain », dit lors d'un appel enregistré en avril, mis à côté d'un nombre d'utilisateurs qui n'a pas bougé depuis, est une question précise et à laquelle on peut répondre. Chaque système pris seul ne montre rien qui vaille d'être mentionné. L'appel a l'air positif. Un nombre d'utilisateurs stable, sans promesse attachée, n'est qu'un chiffre.
L'usage est lu comme une tendance sur le trimestre, car un chiffre stable peut cacher une chute suivie d'une reprise. Même chose pour les fonctionnalités : une utilisée chaque semaine jusqu'à il y a deux mois et plus touchée depuis est une question précise à poser lors de l'appel.
Associez les demandes de fonctionnalités sur le fond, pas sur le mot à mot, sinon le brief devient activement nuisible. Un client dit « on a besoin de voir qui a changé quoi » et le ticket s'appelle « journal d'audit ». Une correspondance littérale ne trouve rien, le brief signale aucun ticket, et le commercial entre en appel en s'excusant pour quelque chose livré six semaines plus tôt. La correspondance sémantique, avec un « aucun ticket trouvé » explicite pour les vrais manques, est la seule version fiable. Une demande sans ticket est un point pour l'appel, pas un oubli.
Le plus gros risque en premier
Ouvrir sur la pire chose vraie plutôt que sur un résumé chronologique est une décision de mise en forme qui détermine si le brief est lu. Quelqu'un l'ouvre quatre-vingt-dix secondes avant un appel. Si un champion parti est dans le quatrième paragraphe, autant qu'il ne soit pas dans le brief du tout.
Donc le brief s'ouvre sur ce qui, parmi ceci, est vrai et le plus sérieux : l'usage a baissé significativement, un champion est parti, un engagement a été pris puis manqué, ou le renouvellement est dans moins de quatre-vingt-dix jours. Le détail suit : ce qui a été demandé et où ça en est, ce qui est utilisé et ce qui a été abandonné, et les engagements ouverts des deux côtés.
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.
# Prepare for a customer call
You have access to a call-recording tool, a CRM, product analytics, an
issue tracker, and a messaging tool. Run this for **[the account and
the meeting time]**.
## 1. Quote requests from past calls
Find the recorded calls with this account, most recent first. Search
by attendee email and separately by company domain, since a call is
recorded by whoever hosted it.
Extract only what carries forward:
- Anything they asked for, and whether it was promised.
- Anything either side committed to, with a date.
- Any complaint, and whether it was resolved.
Quote the request in their words. It is what step 3 has to match
against the tracker, and a paraphrase into internal vocabulary is
exactly what makes that match fail.
## 2. Recap plan, renewal and contacts
Pull the account record: plan, renewal date, owner, open opportunities,
and any support history. Note whether the renewal falls within ninety
days, because that changes what the brief should lead with.
Check the contacts. Anyone who appeared on past calls but is no longer
on the account record has probably left, and a departed champion is
the single most important line in this brief.
## 3. Compare product usage with what they said
This is the half a CRM cannot answer.
- Weekly active users over the last quarter, and the direction of
travel. A flat number hides a halving followed by a recovery.
- Which features they use, and which they have stopped using. A
feature they used weekly until two months ago and have not touched
since is a specific, answerable question for the call.
- Depth: are they using the thing they bought it for, or only the
edges of it?
Compare against what they said on the last call. "We are rolling it
out to the wider team next month" said in April, against a flat user
count in June, is the most useful contradiction the brief can carry.
## 4. Give each request its status
For each feature request from step 1, find the matching issue in the
tracker and report its real status: shipped, in progress with a
target, backlogged, or declined.
Match on the substance of the request, not on wording. A customer
asking for "a way to see who changed what" and an internal ticket
called "audit log" are the same thing, and reporting no match is
worse than useless because it means the call repeats a request
somebody already actioned.
Where a request has no matching ticket, say so. That is an item for
the call, not an omission.
## 5. Post the brief, biggest risk first
Post to the channel before the meeting, led by whichever of these is
true and most serious:
- Usage has fallen materially.
- A champion has left.
- A commitment was made and missed.
- The renewal is inside ninety days.
Then the detail: what they asked for and where it stands, what they
use and what they stopped using, and open commitments on both sides.
## Output
Report: calls found, requests extracted and matched to tickets,
requests with no ticket, usage direction, features abandoned, contacts
who appear to have left, and open commitments.
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, « Préparer un appel client » 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 la préparation d'appel client avec l'IA
Processus similaires
Des processus qui partagent des outils avec celui-ci. Les outils partagés sont allumés.
Préparer une démo à partir du dernier appel
Les derniers appels, l'état du deal et une recherche fraîche deviennent un brief, avec un deck construit sur les cas d'usage de cette entreprise, publié avant la démo.
- Partage
- Google Calendar, Granola, Slack
Démo au calendrier5 étapes →
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.
- Partage
- PostHog, Linear, Granola
Planification quotidienne7 étapes →
Les appels clients deviennent des tickets
Chaque appel enregistré dans la journée est passé au crible la nuit — bugs et demandes de fonctionnalités routés vers la bonne équipe en tickets et docs, plus un récap le vendredi.
- Partage
- Granola, Linear, Slack
Passage nocturne5 étapes →
