# Dossier client incohérent : vérifier une livraison et un paiement avant de répondre

Un exemple construit pour répondre avec prudence lorsque les vues de livraison et de paiement sont anciennes ou contradictoires.

- URL canonique: https://www.harmate.com/fr/blog/dossier-client-incohérent-vérifier-une-livraison-et-un-paiement-avant-de-répondre
- Auteur: Harmate Team
- Publié le: 2026-11-15
- Mise à jour: 2026-11-15T01:49:42.104696+00:00
- Langue: fr

## Contenu

# Dossier client incohérent : vérifier une livraison et un paiement avant de répondre

Un écran affiche « livré », un autre « remboursement en attente », et le client conteste les deux informations. Avant de répondre, séparez chaque source, son heure de mise à jour et ce qu’elle permet réellement d’affirmer. Le cas ci-dessous est entièrement fictif ; il sert à travailler une réponse prudente, pas à décrire le comportement général d’un transporteur ou d’un moyen de paiement.

## Construire une chronologie vérifiable

Noor demande pourquoi sa commande de 84,50 € est à la fois indiquée comme livrée et associée à un remboursement en attente. Dans le scénario, le dossier de commande a été créé le 14 novembre à 16 h 02. Le suivi du transporteur indique « livré » le lendemain à 9 h 41, sans photo accessible à l’équipe support. Le registre des encaissements affiche une opération de 84,50 € à 9 h 46. Enfin, une vue de dossier indique « remboursement en attente », mais sa dernière synchronisation date de la veille à 18 h.

À 10 h 11, une recherche distincte dans le registre des remboursements ne renvoie aucun événement pour ce paiement. Cela permet une affirmation limitée : aucun remboursement n’apparaît dans cette vue à cette heure-là. Cela ne prouve pas qu’aucune demande n’existe dans une file de revue distincte, que l’équipe n’a pas encore vérifiée.

Une chronologie de travail rend les limites visibles :

| Source | Observation | Limite |
|---|---|---|
| Suivi transporteur, 9 h 41 | Statut « livré » | Le destinataire et le lieu ne sont pas confirmés |
| Registre des encaissements, 9 h 46 | Opération de 84,50 € | Établit l’encaissement ; cette source ne renseigne pas sur un remboursement ultérieur |
| Recherche du registre des remboursements, 10 h 11 | Aucun événement trouvé pour ce paiement | Résultat limité à cette source et à l’heure de recherche |
| Vue de dossier, synchronisée la veille | « Remboursement en attente » | État potentiellement ancien ; source et date doivent être vérifiées |



## Répondre avec ce qui est établi

Une réponse utile attribue chaque information à sa source et distingue l’inconnu :

> Le transporteur indique que le colis TR-550 a été livré à 9 h 41 aujourd’hui. La photo n’est pas disponible dans notre vue, donc je ne peux pas confirmer où il a été déposé. Le registre des encaissements montre une opération de 84,50 €. Une recherche distincte du registre des remboursements n’a trouvé aucun événement à 10 h 11. L’étiquette « remboursement en attente » de votre dossier date de la dernière synchronisation d’hier. Je vérifie s’il existe une demande en cours dans une autre file et je demande à l’équipe Livraison d’examiner les détails. Je vous tiens informée avant midi.

Dans cet exemple, midi est un engagement fictif que l’équipe du scénario peut tenir. Il ne faut pas le reprendre si l’équipe réelle ne peut pas respecter ce délai.

## Attribuer les vérifications

L’agent support vérifie la file de revue du remboursement et relie toute demande au paiement concerné. L’équipe Livraison recherche les détails disponibles et suit la procédure interne prévue. Chaque nouvelle information est ajoutée à la chronologie avec sa source et son heure de consultation. Le client reçoit ensuite un point d’étape, même si la réponse finale dépend encore d’une vérification.

Avant d’envoyer votre message, marquez chaque phrase comme confirmée, ancienne ou inconnue. Dites « le suivi indique livré », pas « vous avez reçu votre colis ». Dites « la recherche du registre des remboursements n’a trouvé aucun événement à 10 h 11 », pas « aucun remboursement n’existe ». N’effacez pas le désaccord en choisissant simplement l’écran qui semble le plus récent.

Ce cas utilise des systèmes et des données inventés. Il ne démontre pas une pratique de marché, un résultat client ou une intégration produit. Adaptez les propriétaires et les engagements aux procédures en vigueur et vérifiez les enregistrements autorisés avant de faire une promesse. Pour un exercice de dialogue sur la livraison contestée, voir [Jeu de rôle en service client : traiter une livraison contestée](https://www.harmate.com/fr/blog/jeu-de-r%C3%B4le-en-service-client-traiter-une-livraison-contest%C3%A9e).

Vérifiez aussi le moment où chaque renseignement est communiqué. Les [cas de test sur plusieurs tours](https://www.harmate.com/fr/blog/tester-un-chatbot-sur-plusieurs-tours) montrent comment distinguer une information reçue du projet d’action qui en découle.