Un client demande si ses dix pièces arriveront le 17 novembre pour une intervention prévue sur site. Le SI confirme cette date pour six pièces. Les quatre autres figurent au planning du 19, sans validation. Le risque est qu’un agent reprenne la première date et l’annonce pour toute la commande. Le client peut alors organiser son intervention alors qu’il lui manquera quatre pièces.
En pratique, une confirmation porte sur une quantité, une destination et une date de livraison que le service compétent autorise à communiquer. Le même dossier peut contenir plusieurs réponses valables, chacune limitée à sa tranche. Une date affichée dans le CRM ou une quantité disponible en stock n’apporte pas à elle seule cette preuve.
L’intégration de l’IA au système d’information permet de donner à l’agent une décision qu’il peut restituer sans élargir la promesse. Le scénario fictif suit une commande fractionnée et un changement d’adresse pour vérifier quand répondre, demander une précision ou transmettre à l’administration des ventes, l’ADV.
Dans quels cas l’agent peut répondre au client
Le premier périmètre couvre une commande déjà enregistrée et un client habilité à la consulter. L’agent restitue une confirmation existante. Une demande de livraison plus tôt, de regroupement ou de changement d’adresse ouvre un autre parcours. Elle demande un nouveau calcul et une validation par l’équipe ou le service qui engage la livraison.
Avant de lire l’état logistique, le service rapproche le demandeur, le compte et la commande. Si le client est identifié mais que plusieurs commandes correspondent à son message, demandez la référence de commande plutôt que de choisir le résultat le plus récent. Si l’accès est refusé, alors la réponse ne divulgue ni la date ni les détails du dossier. Orientez le demandeur vers le canal qui permet de vérifier son accès.
Le pilote peut commencer avec des réponses en lecture seule, sur un canal authentifié et pour une famille de commandes dont le SI expose la promesse. Le commerce conserve la responsabilité des exceptions. Cette séparation réduit le risque qu’une simple question de suivi déclenche une réservation ou une modification.
Reconnaître la date qui engage la commande
Distinguer la demande, le départ et la livraison
La date demandée vient du client. La date d’expédition correspond au départ. La date de livraison correspond à la réception prévue à destination. Chacune peut avoir un statut différent. Dans sa documentation du calcul de dates de livraison, Microsoft distingue les dates de départ et de réception confirmées par ligne. Selon le mode de calcul, les champs peuvent rester vides en attendant le planning. Vérifiez les champs et leur définition dans votre propre SI.
Un suivi transporteur peut apporter une estimation après le départ. Sa valeur dépend du colis auquel il se rapporte et de son statut. Si la question concerne la commande complète, il faut retrouver les colis et les quantités qu’ils couvrent. La dernière date lue sur un colis ne permet pas de répondre pour un autre.
Attribuer l’autorité à un service métier
Le stock, les créneaux de préparation et le calendrier du transport peuvent venir de logiciels différents. Choisissez avec la logistique le service qui décide de la date communicable et des conditions qui l’invalident. Une note CRM peut signaler une urgence ou un accord à vérifier. Le service de promesse doit dire si cet accord figure dans la version courante de la commande.
À l’entrée, le service reçoit la référence autorisée et la version de la commande. En sortie, il fournit la date de livraison, son statut, la quantité, la destination de référence et l’identifiant de la promesse. La journalisation permet de retrouver la décision utilisée pour le message. Dans le scénario, une prévision sert à orienter l’ADV et reste exclue du texte de confirmation.
Cas concret : six pièces confirmées sur dix
La commande fictive C-481 contient dix pièces pour le site Nord. Le client souhaite toutes les recevoir le 17 novembre. À la révision 12, le service de promesse renvoie deux tranches. La première est validée pour six pièces avec un départ le 16. La seconde dépend d’un réapprovisionnement. Le planning affiche un départ le 18 et une livraison estimée le 19.
| Tranche | Départ | Livraison | Décision |
|---|---|---|---|
| 6 pièces | 16 nov. | 17 nov. | Confirmée |
| 4 pièces | 18 nov. prévu | 19 nov. estimé | En prévision |
La réponse autorisée est « Je vous confirme la livraison de six pièces sur le site Nord le 17 novembre. La date des quatre pièces restantes est encore à confirmer. » Si les dix pièces sont nécessaires pour l’intervention, l’ADV reprend la demande de livraison complète. L’agent peut expliquer ce qui est déjà validé sans annoncer que l’intervention pourra avoir lieu.
Dans le journal du cas, la promesse P-N6 se rattache à C-481, révision 12, site Nord, six pièces et livraison du 17 novembre. Le message préparé reprend P-N6 pour cette seule phrase. La seconde tranche porte un identifiant de planning et un état estimé. Pour le support, cette différence explique pourquoi une date apparaît dans le dossier alors qu’elle ne peut pas être confirmée au client.
Paradoxalement, un service qui renvoie deux dates précises peut n’autoriser qu’une seule confirmation. Le dossier reste utile au client parce qu’il répond sur les six pièces et identifie la question ouverte. Si le canal ne permet pas de préciser le périmètre, alors l’agent passe la main plutôt que de publier un unique champ « livraison confirmée » pour toute la commande.
Vérifier la promesse juste avant l’envoi
Bloquer le brouillon lorsque la destination change
L’agent prépare sa réponse à partir de la révision 12. Avant l’envoi, l’ADV modifie la destination vers le site Sud. La révision 13 est enregistrée et le recalcul est en cours. Le brouillon du site Nord ne doit plus partir. L’adresse a changé le périmètre même si les six pièces sont toujours disponibles.
En révision 14, le service valide six pièces pour le 18 novembre et quatre pour le 20 au site Sud. La nouvelle réponse peut confirmer les deux dates avec leurs quantités. Par exemple « Au site Sud, six pièces sont confirmées pour le 18 novembre et quatre pour le 20 novembre. » Le dossier garde le brouillon invalidé et les nouvelles références de promesse pour expliquer la différence si le client demande pourquoi la date a changé.
Appliquer le contrôle au moment de décider l’envoi
Le service d’envoi reçoit la version et les références exactes du brouillon. Il vérifie leur validité au plus près de l’autorisation. Si l’envoi est asynchrone, effectuez le contrôle au moment de traiter la file et pas seulement lors de la rédaction. Une vérification dans un système séparé laisse un intervalle avant l’envoi. Pour garantir que les deux restent liés, utilisez le mécanisme de validité ou d’autorisation conditionnelle que le service métier expose effectivement. En son absence, gardez ce cas en validation humaine.
Pour un premier pilote, le service peut construire la phrase de confirmation à partir des champs validés, avec un modèle de message qui garde quantité, site et date ensemble. L’agent traite la question en langage naturel et demande les précisions utiles. Si vous lui confiez aussi la formulation, contrôlez la sortie avant l’envoi. Une phrase qui associe P-N6 aux dix pièces ou au site Sud doit être bloquée, même si elle cite la bonne référence de commande.
Conservez l’identifiant du message et la décision associée dans la journalisation. Si le service d’envoi ne répond pas, recherchez le résultat par référence avant de retenter. Si la promesse change après une communication confirmée, ouvrez une notification corrective liée au message déjà émis. La correction reste visible pour le support et pour le client.
Demander une précision ou transmettre à l’ADV
Une référence ambiguë appelle une question courte. Une date non validée malgré une commande identifiée appelle une revue métier. L’agent transmet alors la référence, la version, la destination, les quantités confirmées et l’urgence exprimée. Il indique au client que la date reste à vérifier. Il annonce la transmission seulement quand le dossier est effectivement créé et ne fixe un délai de réponse que si l’équipe en a prévu un.
Le dossier de transfert indique aussi ce que le client attend comme décision. Pour C-481, la question peut être « peut-on garantir les dix pièces avant l’intervention ? ». C’est différent de « quelle date figure au planning ? ». L’ADV peut alors arbitrer un regroupement, une autre destination ou une nouvelle échéance à partir de l’état actuel. Le retour de l’ADV produit une nouvelle décision communicable avant que l’agent reprenne la conversation.
Si la source est indisponible, conservez la dernière promesse comme information historique pour l’équipe. L’agent peut informer le client qu’il ne peut pas vérifier la date à cet instant. Le dossier sur les réponses d’un agent quand une API est indisponible aide à distinguer ce cas d’un refus d’accès et à prévoir une reprise.
Matrice de décision : vérifier les réponses réelles
| Situation | Réponse ou action attendue |
|---|---|
| Commande ambiguë | Demander la référence. Aucune date dans le message. |
| Demandeur non habilité | Refuser la communication des détails et proposer le canal d’accès prévu. |
| Révision 12 | Confirmer six pièces le 17 au site Nord. Présenter les quatre autres comme non confirmées. |
| Départ seul confirmé | Nommer l’expédition si cette information est autorisée. Aucune date de réception confirmée. |
| Passage à la révision 13 | Bloquer le brouillon Nord et attendre une décision pour le site Sud. |
| Révision 14 | Confirmer six pièces le 18 et quatre le 20 au site Sud. |
| Source indisponible | Signaler l’impossibilité de vérifier et ouvrir la revue si le transfert aboutit. |
Contrôlez la réponse réellement affichée, y compris les résumés de conversation. La recette échoue si l’agent lit correctement la révision 12, puis écrit que toute la commande arrive le 17. Vérifiez également la négation et le statut. « Prévue le 19 » et « confirmée le 19 » sont deux résultats différents même si le nombre extrait est identique.
Erreurs fréquentes : transformer une prévision en promesse
- Confirmer à partir du stock. Vérifiez la décision de livraison de la tranche et de sa destination.
- Fusionner deux dates dans le résumé. Gardez la quantité et le statut à côté de chaque date.
- Envoyer un brouillon devenu ancien. Revalidez la version au point d’envoi, après toute attente en file.
- Promettre un rappel automatique. Donnez le délai seulement si l’équipe a pris en charge le dossier avec cet engagement.
Plan d’action : ouvrir le parcours par étapes
Cadrer la décision sur une famille de commandes
Commencez par un canal, un type de livraison et un responsable ADV. Le métier approuve les formulations autorisées pour une confirmation partielle, une date estimée et une demande non résolue. Le SI associe chaque formulation aux preuves attendues et précise quel changement de version la rend caduque. Vérifiez que le support sait retrouver cette décision après l’envoi.
Préparez des commandes de recette avec deux tranches, un changement d’adresse, un refus d’accès et un résultat d’envoi inconnu. En entrée, figez les états de la commande et les droits du demandeur. En sortie, comparez la décision, le message et la journalisation des actions. Fixez à zéro le seuil de confirmations émises sans preuve sur le jeu de recette.
Ouvrir d’abord en validation humaine
Laissez l’agent préparer la réponse et faites contrôler les premières propositions par l’ADV. Comptez séparément les confirmations correctes, les précisions utiles et les transferts justifiés. Une réponse prudente peut rester inutile si elle envoie chaque question à l’équipe alors que le service dispose de la preuve.
Ouvrez ensuite la confirmation automatique pour les cas couverts et gardez un repli vers l’ADV pour les autres. Si l’équipe détecte une confirmation sans preuve, suspendez cette capacité sur le périmètre touché et rattachez les corrections aux messages d’origine. Le seuil de reprise dépend de la cause et du jeu de cas vérifiés après correction.
Guides complémentaires pour raccorder les sources
Le contrôle d’un contexte ERP périmé détaille le problème en amont, lorsqu’une disponibilité ou un prix change entre la préparation et la création d’un devis.
Le raccordement ERP et CRM d’un agent IA aide à attribuer à chaque logiciel son rôle et à isoler les actions réellement autorisées avant d’ouvrir une réponse client.
Conclusion : confirmer uniquement le périmètre validé
Une confirmation utile dit quelle quantité arrive, où et quand. Sur C-481, l’agent peut confirmer les six premières pièces tant que la promesse pour le site Nord est valide. Le changement d’adresse impose une nouvelle décision avant toute annonce pour le site Sud.
Faites décider le service métier et vérifiez le message qui part réellement. Le client reçoit alors une confirmation précise, une question utile ou un dossier transmis à la bonne équipe.
Dawap accompagne l’intégration IA au SI en reliant les réponses de l’agent aux données, aux droits et aux décisions de vos logiciels. Un atelier peut partir de vos commandes fractionnées et établir les cas où la confirmation peut être confiée à l’agent.
