À retenir
Reconnecter l’agent ne valide pas la migration. Il faut vérifier que les informations utilisées gardent leur sens, que les relations entre contacts et affaires sont conservées et qu’aucune ancienne action ne devient indûment exécutable. Faites valider les correspondances par le métier, puis testez en lecture et en brouillon avant de rendre les écritures possibles.
Inventoriez les champs qui déclenchent une décision
Exemple fictif : dans l’ancien CRM, « qualifié » signifie qu’un commercial a confirmé le besoin. Dans le nouveau, cette étape est attribuée dès qu’un formulaire contient un téléphone. Si l’agent reprend la même règle de relance, il peut traiter une simple inscription comme une opportunité validée.
Une correspondance de noms ne résout pas ce problème. Demandez au responsable commercial de décrire le sens de chaque champ utilisé par l’agent : qui le remplit, à quel événement et avec quelles exceptions. Les champs qui déclenchent un message, une affectation ou une priorité passent avant les informations purement descriptives.
Pour chaque règle, consignez l’ancienne donnée, sa nouvelle source, sa signification et la personne qui accepte la correspondance. Si aucune équivalence fiable n’existe, suspendez la règle concernée. Inventer une valeur par défaut peut transformer une lacune de migration en décision commerciale silencieuse.
Contrôlez les relations, pas seulement le nombre de fiches
Retrouver autant de contacts après import ne prouve pas que les dossiers sont utilisables. Un contact peut être relié à la mauvaise entreprise ; deux affaires peuvent partager un nom sans partager leur échéance. L’agent risque alors de préparer une réponse exacte pour le mauvais dossier.
Conservez une table reliant les anciens identifiants aux nouveaux, avec les fusions et les rejets. Choisissez des cas représentant vos relations réelles : plusieurs contacts dans une entreprise, plusieurs affaires pour un client, dossier sans propriétaire et fiche fusionnée. Vérifiez que l’historique utile rejoint la bonne affaire.
Le guide sur l’agent IA CRM et le pipeline commercial décrit le travail visé. La migration pose une question préalable : les données nécessaires à ce travail désignent-elles toujours les mêmes personnes et les mêmes affaires ?
Requalifiez les actions préparées avant la bascule
Un brouillon prévu hier peut contenir un lien vers l’ancienne fiche ou viser un dossier désormais fusionné. Un rappel peut rester actif dans l’ancien système alors que le nouveau en crée un autre. Avant de réautoriser l’agent, recensez les messages, tâches et traitements en attente.
Attribuez à chaque élément une décision : conserver après contrôle, reconstruire dans le nouveau CRM ou annuler. Un statut « migré » ne dit pas si l’action demeure utile. Le commercial responsable doit confirmer les cas où une nouvelle information change le prochain pas.
Désignez également le système autorisé à déclencher les actions pendant la transition. Si le CRM sortant reste consultable pour l’historique, retirez-lui les déclenchements devenus inutiles selon un plan validé. La possibilité de revenir en arrière doit inclure les modifications réalisées après la bascule, pas seulement la restauration d’un export ancien.
Changer de CRM sans perdre les règles commerciales
Apportez une règle de relance et quelques dossiers représentatifs pour cadrer les dépendances de votre agent avec Amplify. Les écarts de sens doivent être visibles avant de réouvrir les actions.
Rejouez les mêmes dossiers sans envoyer aux clients
Sur un environnement ou un périmètre de test autorisé, demandez à l’agent de préparer le prochain pas pour des dossiers comparables avant et après migration. Comparez le destinataire, l’étape comprise, le propriétaire, la justification et l’action proposée. Les données utilisées doivent être autorisées et minimisées.
Une différence n’est pas toujours une erreur : le nouveau CRM peut corriger une ancienne règle. Faites alors approuver ce changement explicitement. Sans cette distinction, la recette risque de reproduire des défauts historiques ou d’accepter une régression en la présentant comme une amélioration.
Ajoutez un cas incomplet et un cas ambigu. L’agent doit demander l’information manquante ou transmettre le dossier, plutôt que fabriquer une équivalence. Conservez le résultat attendu et l’écart observé dans la recette avant production.
Autorisez la reprise par capacité
Commencez par la lecture des fiches, puis la préparation des brouillons, avant les modifications ou les envois lorsque ces actions font partie du service. Chaque autorisation doit avoir un responsable et des critères de contrôle. Il n’est pas nécessaire de réactiver toutes les capacités au même moment.
Demandez un dossier de reprise contenant les correspondances validées, les règles suspendues, le sort des éléments en attente et les limites du retour arrière. Une migration peut alors se terminer par une décision métier explicite. Le message « connexion réussie » retrouve sa juste place : une vérification technique utile, mais insuffisante pour autoriser l’agent à relancer vos clients.
Passer du besoin au premier périmètre
Définissez avec Amplify le travail à confier, les validations et les preuves attendues.
Découvrir First Contact