Cycle de vie des réunions des propriétaires d'agence : de la préparation au suivi de quinze appels par semaine

L'opérateur

Le propriétaire d'une agence gérant huit comptes clients actifs avec une équipe de cinq personnes dispose d'un calendrier qui ressemble à un tableau des départs d'un aéroport. Quinze appels ou plus par semaine – bilans de situation, briefs créatifs, séances de planification trimestrielles, conversations sur de nouvelles affaires – chacun nécessitant une préparation différente en nature et souvent différente en profondeur. L'équipe livre le travail ; le propriétaire participe à presque tous les appels destinés aux clients et est la personne dont le travail consiste à connaître l'historique, à entretenir la relation et à prendre des décisions dans la salle.

L'équipe utilise une combinaison de dossiers Gmail, Slack et Google Drive partagés pour la communication avec les clients et la gestion des livrables. Cinq personnes génèrent chaque jour des fils de discussion, des décisions et des engagements dans ces huit relations. Le propriétaire n'est pas présent sur tous les sujets. Ils sont présents à chaque appel. C’est dans l’écart entre ces deux faits que les choses tournent mal.

Le point de rupture

Arriver à un appel client sans préparation n’est pas un risque abstrait ; c'est un événement hebdomadaire. Pas vraiment mal préparé : le propriétaire sait qui est le client, quel est le projet, à peu près à quel stade en sont les choses. Mais le type spécifique de préparation qui compte réellement – ​​savoir ce qui a été décidé il y a deux semaines, savoir sur quel élément ouvert le client va poser des questions, savoir qu'un membre de l'équipe est en retard de trois jours sur un livrable qui arrivera dans les cinq premières minutes – qui nécessite une séance de préparation qui se produit rarement. Quinze appels par semaine ne laissent pas de place à quinze séances de préparation.

Le problème de suivi est l’image miroir du problème de préparation. Une fois l’appel terminé, le propriétaire a une liste mentale de ce qui a été décidé et de ce à quoi il s’est engagé. Cette liste commence à s’évaporer immédiatement. Le propriétaire répond souvent au prochain appel avant d’avoir eu la possibilité d’écrire quoi que ce soit. En fin de compte, deux ou trois engagements issus d'appels précédents n'ont aucune trace dans aucun système. L'équipe ne sait pas qu'ils existent. Les clients s'en souviennent ; l'agence ne le fait pas.

Le résultat est un cycle de vie de réunion avec deux extrémités brisées : la fin de préparation, où le propriétaire arrive avec une image incomplète, et la fin de suivi, où les engagements pris dans la salle ne figurent jamais sur un tableau de tâches ou dans un récapitulatif client. Le milieu – la conversation proprement dite – est bien. L’infrastructure qui l’entoure ne l’est pas.

La configuration

Le propriétaire de l'agence connecte son Gmail et l'agenda Google partagé que son équipe utilise pour la planification des clients. Ils se connectent à Google Drive, où l'équipe conserve les briefs clients, les ressources créatives et les documents de statut. Chacun des huit clients dispose de sa propre organisation chez Lodestar, avec des projets à l'intérieur de chacun qui correspondent aux engagements actifs : un projet de rafraîchissement de la marque ici, un mandat média payant là-bas, un site Web créé ailleurs.

Les cinq membres de l'équipe sont ajoutés aux organisations et aux projets concernés afin que leurs fils de discussion et leurs actions soient intégrés à l'image partagée. Le propriétaire de l'agence a désormais une visibilité sur les engagements pris par son équipe dans des fils de discussion sur lesquels il n'a jamais été — extraits par Lodestar, liés à la citation source, apparus dans la vue du projet. Ils ne lisent pas tous les e-mails ; ils voient le signal extrait de chacun d’eux.

Le flux de travail

Le cycle de vie d’une réunion se déroule en deux phases. La phase de préparation a lieu avant l'appel, idéalement quelques minutes avant, ce qui correspond à tout le temps disponible. La phase de suivi a lieu immédiatement après. Les deux sont gérés via une conversation avec Claude via le Lodestar MCP, sans ouvrir aucune autre application.

• ·Avant — Le propriétaire demande à Claude de les préparer pour le prochain appel en nommant le client. Claude appelle `calendar_retrieve` pour confirmer les détails de la réunion et les participants, puis `emails_content` sur les deux dernières semaines de discussions avec ces participants.
• ·Avant — Claude appelle « knowledge_search » pour faire apparaître les documents Drive pertinents : le brief du projet en cours, le dernier état des lieux, toutes les propositions en suspens. Il appelle « contacts_retrieve » et « knowledge_org_charts » pour confirmer qui est dans la salle, y compris toutes les nouvelles parties prenantes apparues dans les discussions récentes.
• ·Avant — Claude appelle `action_items_list` pour ouvrir les éléments sur les projets de ce client, en signalant ceux qui sont en retard ou qui ont été engagés personnellement par le propriétaire. Le brief de préparation revient : le contexte de l'ordre du jour de la réunion, les dernières décisions, les points ouverts susceptibles de survenir, les personnes présentes et leur ton de communication récent.
• ·Avant — Le propriétaire lit le mémoire. C'est une page. Ils se présentent à l'appel en sachant exactement ce que le client est susceptible de soulever, ce que l'équipe leur doit encore et ce qui a été décidé lors de leur dernière rencontre.
• ·Après — Le propriétaire saisit ses notes de l'appel dans la même conversation avec Claude — les décisions prises, les livrables engagés, à qui appartient quoi, les dates mentionnées. Claude extrait des éléments d'action structurés à partir des notes brutes.
• ·Après — Claude appelle `action_items_create` pour chaque engagement, en attribuant chacun au bon projet dans Lodestar. Lorsqu'un membre de l'équipe a été désigné comme propriétaire, l'élément lui est attribué. Lorsqu'une date d'échéance a été indiquée, elle est fixée. Claude appelle `milestones_partial_update` si un jalon a été affecté par les décisions de l'appel.
• ·Après — Claude appelle `timeline_events_create` pour enregistrer la réunion elle-même par rapport à la chronologie du projet du client. Il appelle ensuite « emails_reply_link » pour rédiger le récapitulatif post-appel pour le client : un résumé clair de ce qui a été décidé et de ce qui va suivre, prêt à être examiné et envoyé par le propriétaire.
• ·Après : le propriétaire lit le brouillon récapitulatif, effectue les ajustements nécessaires et clique sur Envoyer. La boucle est bouclée : le client a un dossier écrit, l'équipe a ses missions dans Lodestar et le calendrier du projet reflète la réunion.

Quels changements

Le problème de préparation est résolu au point où il était réellement impossible à résoudre auparavant : quelques minutes avant l'appel, sur un calendrier chargé. Le propriétaire n'a plus besoin d'un bloc de préparation dédié pour chaque réunion car le brief s'assemble lui-même à partir des données en direct dans Lodestar. Ce n’est pas une plongée en profondeur parfaite ; il s'agit d'une page fiable et précise qui couvre ce qui se passe réellement au cours des dix premières minutes d'un appel client.

Les engagements cessent de s’évaporer. Les notes post-appel du propriétaire, aussi brèves soient-elles, deviennent des actions structurées quelques minutes après la fin de l'appel. Les membres de l'équipe voient leurs missions dans Lodestar sans avoir besoin d'un message Slack du propriétaire. Les clients reçoivent un e-mail récapitulatif qui a été rédigé à partir du véritable enregistrement de la conversation plutôt que reconstruit à partir d'un souvenir qui s'estompe.

L’image partagée par l’équipe du statut du client reste à jour. Étant donné que les éléments d'action sont extraits des fils de discussion ainsi que des appels, les membres de l'équipe qui ont généré des engagements dans les fils de discussion de courrier électronique auxquels le propriétaire ne participait pas sont toujours visibles dans le projet du client. Le propriétaire peut voir l’état complet de chaque engagement avant tout appel sans demander à l’équipe de le briefer.