B2B / logiciel
Une application multilingue qui collecte les profils et les demandes de produits, conserve le statut et l'historique, organise les évaluations, rend le travail en cours visible et prépare le transfert commercial vers Sales. La couche commerciale se trouve entièrement dans l'Ambassador Journey, mais une demande, une approbation et un handoff définitif restent des étapes distinctes avec des pouvoirs de décision distincts.
La situation
Un programme d'ambassadeurs vit, dans la pratique, dispersé entre boîtes mail, tableurs et conversations. Quelqu'un s'inscrit, envoie un profil, demande des produits, reçoit une réponse d'un collègue et une question d'un autre. Qui veut connaître le statut doit chercher. Qui doit évaluer ne sait pas toujours que quelque chose l'attend. Et quand une demande arrive enfin chez Sales, on ne peut pas toujours retracer qui a approuvé quoi, et quand.
L’enjeu commercial
La question était double. Comment rassembler ce flux en un seul endroit, avec un statut qui soit juste. Et quelles étapes une application peut-elle y franchir seule, même quand elle en est techniquement capable.
Les choix
L'Ambassador Journey est une application multilingue développée au sein de Simply Dom. Un ambassadeur y suit un parcours structuré : transmettre son profil, introduire ses demandes de produits, suivre l'avancement. De l'autre côté, les personnes qui doivent évaluer et approuver voient ce qu'on attend d'elles et ce qui a déjà été fait.
La couche commerciale se trouve entièrement dans cette même application. L'évaluation, les choix de produits, l'approbation et le transfert définitif vers Sales ne forment pas un circuit à part ; ce sont des étapes du même parcours, avec le même statut et le même historique. C'était un choix délibéré.
Dans ce parcours, quatre transitions ont été délibérément tenues séparées.
Une demande est le moment où un ambassadeur introduit quelque chose. L'application l'enregistre, vérifie qu'elle est complète et la met en file. Rien de plus.
Une évaluation est le moment où quelqu'un qui connaît la relation et le marché examine cette demande. L'application montre que l'évaluation est nécessaire et à qui elle revient. Elle ne fait pas l'évaluation.
Une approbation est une étape distincte, avec un autre propriétaire que l'évaluation. Qu'une évaluation soit positive ne veut pas dire que l'approbation est donnée. L'application garde les deux séparées, y compris dans le statut.
Et le transfert définitif vers Sales est encore autre chose. Il n'existe que lorsque quelqu'un disposant de l'habilitation requise franchit explicitement cette étape. À partir de là, le handoff est fixé et le dossier poursuit son chemin dans le circuit commercial. Le parcours prépare ce transfert. Il ne l'exécute pas.
Aucune demande ne devient donc d'elle-même une commande, un contrat ou un engagement. Ce n'est pas parce que l'application ne le pourrait pas. Techniquement, une transition de statut est une petite opération. Être habilité à prendre une décision commerciale est autre chose, et cela n'a pas été confié au logiciel.
Mon rôle
L'IA et les agents ont eu une large part dans le développement : recherche, architecture, code, tests, relecture et préparation de la mise en production.
Ils n'ont jamais fixé les règles de gestion. Quels statuts existent, qui peut poser quelle transition et ce qu'une approbation signifie exactement, cela a été défini par des personnes qui connaissent le programme. L'IA a aidé à le construire correctement et de manière vérifiable. La fiabilité des accès et des transitions de statut a été testée et documentée. La propriété du produit, et des décisions qu'il contient, est restée là où elle doit être.
L’exécution
Elle collecte les profils et les demandes de produits et vérifie que tout est présent avant que quoi que ce soit ne puisse avancer. Elle conserve le statut et l'historique, de sorte qu'on voit à tout moment où en est un dossier. Elle organise les évaluations : qui doit agir maintenant, ce qui attend, ce qui est réglé. Un aperçu opérationnel quotidien rend le travail en cours visible sans que personne ne doive le chercher. Et une fois une étape terminée, elle prépare la suivante, jusqu'à mettre une sélection approuvée prête pour le transfert.
Une bonne partie de ce qui était autrefois suivi, transmis et relancé à la main, l'application le fait désormais elle-même.
Délibérément écarté
La tentation existe de laisser tourner aussi les dernières étapes. Si les données sont complètes et l'évaluation positive, pourquoi l'application ne poserait-elle pas l'approbation elle-même ? Parce que dans ce programme, une approbation contient plus que ce qui figure dans les champs : la relation avec l'ambassadeur, l'arbitrage commercial du moment, parfois une exception que personne n'avait décrite à l'avance. Cette décision revient à quelqu'un qui en répond ensuite. Cela vaut encore davantage pour le transfert vers Sales, qui a une conséquence en dehors du parcours.
L'application peut donc tout préparer et ne rien décider de ce qui a un poids commercial. Cette distinction était dans la conception dès le départ.
Résultat / impact
Il y a un seul endroit où vit le programme, avec un statut juste et un historique consultable. Les évaluateurs voient ce qui les attend. Sales reçoit un transfert préparé et approuvé par qui y est habilité, et n'a plus à reconstituer ce qui a précédé. Et l'ambassadeur sait où en est sa demande. Ce qui se passe après le transfert, le travail contractuel lui-même, c'est un autre outil et une autre histoire.
Ce parcours est aussi la raison pour laquelle j'en ai parlé dans Un système d'IA peut avoir raison sans être habilité à décider. Une application peut techniquement attribuer un statut suivant à la perfection. Savoir si elle en a le droit est une autre question, et ici, on y a répondu délibérément en la laissant aux personnes.