Un appel client peut changer le projet en cinq minutes.
La portée change. Un bloqueur apparaît. Le client approuve une option et en rejette une autre. Une date limite bouge. Quelqu'un promet d'envoyer l'accès. Un coéquipier qui n’était pas à l’appel a quand même besoin de savoir ce qui a changé.
C’est là que tombent la plupart des notes d’appel.
Ils préservent la conversation, mais ne deviennent pas une mise à jour du projet.
La version utile n’est pas « nous avons eu un appel avec le client ». La version utile est la suivante : voici le nouveau statut, voici ce qui a changé, voici à qui appartient la prochaine étape et voici ce que l'équipe doit faire ensuite.
Quand les appels changent le travail du projet
Transformez les appels clients en mises à jour de projets examinés
Superscribe Phone permet de transformer les appels professionnels en résumés, mises à jour de projet, suivis, contexte CRM, tâches, tickets et détails facturables pendant que la conversation est encore fraîche.
La version courte
Un bon workflow de notes d'appel pour la mise à jour du projet doit capturer :
- l'état actuel du projet
- ce qui a changé pendant l'appel
- ce qui a été décidé
- ce qui est bloqué
- à qui appartient chaque prochaine étape
- ce que le client doit
- ce que votre équipe doit
- toute date limite ou signal de timing
- où la mise à jour devrait vivre
Le test est simple.
Un coéquipier qui a raté l’appel pourrait-il comprendre ce qui a changé et que faire ensuite ?
Dans le cas contraire, la note constitue toujours un élément source. Ce n’est pas devenu une mise à jour du projet.
Les mises à jour du projet ne sont pas des transcriptions
Une transcription est classée par temps.
Une mise à jour du projet est classée par utilité.
Lors d’un véritable appel client, les éléments importants arrivent rarement dans un ordre ordonné. Le client peut mentionner un bloqueur plus tôt, approuver la solution plus tard, modifier le timing vers la fin et ajouter la personne responsable pendant que tout le monde termine.
La transcription peut contenir tout cela tout en restant difficile à utiliser.
Une mise à jour du projet doit remodeler la conversation sous une forme sur laquelle l'équipe peut agir :
Statut : l'importation d'intégration est retardée en raison d'erreurs de mappage de champs. Décision : conserver le formulaire d'inscription actuel et corriger d'abord le mappage d'importation. Le client doit l'ancienne politique d'exportation CSV d'ici mercredi. L'équipe dispose de deux options de nettoyage d'ici jeudi. Risque : la date de la démo peut être déplacée si le service juridique n'a pas examiné la clause relative aux données.
Ce n’est pas une plus jolie transcription.
C'est une mise à jour fonctionnelle.
C'est le même écart derrière appeler des notes sur des tâches. L’appel crée du travail, mais le travail ne devient utile que lorsqu’il a une forme, des propriétaires et une destination.
Ce dont une mise à jour de projet a besoin
Une mise à jour du projet doit répondre à des questions différentes d'un e-mail récapitulatif.
Le récapitulatif destiné au client demande : « Que devrait voir le client ?
La mise à jour du projet demande : « Que doit savoir l’équipe ? »
Ces éléments sont liés, mais ce n’est pas la même chose.
1. Statut
Commencez par l’état actuel du projet.
Bien:
Le nettoyage de l'importation est toujours bloqué par le mappage de champs, mais le formulaire d'inscription n'est plus considéré comme la cause.
Faible :
Nous avons discuté du nettoyage des importations.
« Discuté » ne dit presque rien à l’équipe. Une ligne d'état doit indiquer ce qui a changé ou où en est le travail actuellement.
2. Décisions
Écrivez les décisions sous forme de faits.
Bien:
Le client a approuvé l’option B si l’estimation reste inférieure à quatre heures.
Faible :
Le client semblait intéressé par l'option B.
Si l’appel n’a pas abouti à une décision, gardez-le également clair.
Aucune décision pour l'instant. Le client souhaite un examen juridique avant d’approuver l’option B.
Cela empêche l’équipe de traiter un peut-être comme un oui.
3. Bloqueurs
Les bloqueurs doivent être visibles.
Ils ne doivent pas se cacher dans un paragraphe de notes générales.
Bien:
Bloqueur : le client n'a pas confirmé si les anciennes exportations CSV doivent être conservées.
Cette ligne indique à l’équipe pourquoi le projet ne peut pas encore avancer proprement.
4. Propriétaires
Chaque étape suivante a besoin d'un propriétaire.
Si la propriété n’est pas claire, dites-le.
Il vaut mieux avoir un « propriétaire peu clair » honnête que de deviner et d’envoyer la tâche à la mauvaise personne.
Les lignes de propriétaire utiles ressemblent à :
- Maria enverra une liste de contrôle d'intégration révisée d'ici jeudi.
- Le client doit confirmer les exigences de rétention des exportations avant la réussite de la migration.
- Le propriétaire du support n'est pas clair concernant le ticket d'autorisations.
5. Destination
La mise à jour doit indiquer à quelle place appartient chaque sortie.
Certains détails appartiennent au tableau de bord du projet. Certains appartiennent au CRM. Certains appartiennent à un ticket de support. Certains appartiennent à l’e-mail de suivi client. Certains devraient rester internes.
C'est pourquoi notes d'appel pour envoyer un e-mail de suivi et les mises à jour du projet ne doivent pas être le même document. Le même appel peut alimenter les deux, mais chaque sortie nécessite une formulation différente.
Un format simple de mise à jour du projet
Utilisez cette structure lorsque vous transformez manuellement des notes d’appel en une mise à jour de projet.
Projet:
Nom du client, du compte, du ticket ou du projet.
Statut:
Qu’est-ce qui a changé ou où en est le projet maintenant.
Décisions :
Ce qui a été approuvé, rejeté, retardé ou laissé ouvert.
Bloqueurs :
Qu'est-ce qui arrête le progrès.
Prochaines étapes :
Propriétaire, tâche, destination et timing.
Suivi clients :
Ce qui doit être renvoyé au client, le cas échéant.
Contexte interne :
Tout ce que l'équipe a besoin de savoir et qui ne doit pas figurer dans l'e-mail du client.
Cette structure est volontairement ennuyeuse.
Les mises à jour de projets ennuyeux sont faciles à analyser. Ils empêchent les retouches. Ils laissent quelqu'un se joindre au travail sans demander un récit privé de l'appel.
Réviser avant de partager
L’IA peut aider à transformer les notes d’appel en une ébauche de mise à jour du projet.
L’étape de révision est toujours importante.
Les mises à jour du projet peuvent causer de réels dégâts lorsqu’elles sont erronées. Une suggestion peut devenir une décision. Un délai souple peut devenir un délai ferme. Une préoccupation interne peut accidentellement se retrouver face au client. Une tâche peut être confiée à quelqu’un qui n’a jamais accepté d’en être propriétaire.
Le meilleur flux est :
- Enregistrez l'appel.
- Structurez les parties utiles en statuts, décisions, bloqueurs, propriétaires et destinations.
- Révisez pendant que l'appel est encore frais.
- Envoyez la mise à jour du projet au bon endroit.
Cela donne de la vitesse sans remplir le tableau de bord du projet avec des notes à moitié vraies.
Où Superscribe s'intègre
Superscribe Phone est conçu pour la couche après l'appel professionnel.
Il permet aux appels de devenir des résumés révisés, des mises à jour de projet, des suivis, du contexte CRM, des tâches, des tickets et des détails facturables au lieu d'un autre travail de nettoyage.
L’important n’est pas de sauvegarder chaque mot.
L'important est de s'assurer que le travail créé par l'appel atterrit dans un endroit utile avant que le prochain appel ne le remplace en mémoire.
Pour les appels qui changent le travail du projet
Conservez le statut, les bloqueurs et les prochaines étapes ensemble
Utilisez Superscribe pour transformer les appels professionnels en mises à jour de projet révisées, suivis, notes CRM, tâches, tickets et contexte facturable.
La règle pratique
Ne demandez pas à votre équipe de lire l’appel.
Dites-leur ce qui a changé à cause de l'appel.
C'est la différence entre une note enregistrée et une mise à jour utile du projet.