Conseillère préparant la reprise d’un dossier fictif

Opérations et assistance

Service après-vente voyage : préparer les changements avant l’incident

Le parcours après réservation décide souvent de la confiance du client. Un dossier utile relie les références, les conditions, les responsabilités et les actions possibles même lorsque plusieurs fournisseurs interviennent.

Réponse directe

Une réservation doit rester exploitable après l’achat

Le client ne sépare pas le transporteur, l’hôtel, la plateforme et l’agence lorsqu’un trajet change. Il attend une réponse compréhensible. Pour la fournir, le vendeur doit retrouver la version de l’offre achetée, les références de chaque prestation, les règles applicables, les paiements et les échanges déjà réalisés. Une interface de vente qui ne montre pas ces éléments déplace la charge vers les équipes et allonge les délais.

À cadrer avant le lancement

Pour chaque produit, notez qui reçoit la demande, qui peut agir, qui décide, qui rembourse et qui informe le voyageur.

Constituez un dossier unique, même avec plusieurs fournisseurs

Le dossier contient un identifiant interne, les références fournisseurs, les voyageurs concernés, les prestations, les échéances et un historique horodaté. Il doit distinguer la demande du client, la réponse du fournisseur et la décision finale. Une modification partielle ne doit pas écraser le dossier initial : l’équipe doit pouvoir expliquer ce qui a changé et à quel prix.

SituationInformation nécessaireAction attendue
Changement de dateDisponibilité, différence tarifaire, fraisPrésenter et confirmer la nouvelle proposition
Annulation partielleVoyageurs et prestations concernésCalculer les conséquences dossier par dossier
Retard ou suppressionStatut, correspondances, contact utilePrioriser et proposer une suite réaliste
RemboursementMontants encaissés, mode de paiement, décisionSuivre l’état jusqu’à la clôture

Triez les demandes selon leur urgence réelle

Une question sur une facture future et un voyageur bloqué aujourd’hui ne doivent pas entrer dans la même file. Définissez des seuils simples : départ imminent, voyage en cours, risque de correspondance, besoin d’accessibilité, groupe impacté. Associez à chaque niveau un canal, un délai de prise en charge et une règle d’escalade. Les messages automatiques peuvent confirmer la réception, mais ne doivent pas donner l’impression qu’une solution est déjà trouvée.

Préparez un fonctionnement dégradé : numéros et portails alternatifs, liste des dossiers concernés, personne habilitée à décider et modèle de communication clair. Testez-le lors d’un exercice, sans attendre une panne.

Testez les opérations après réservation une par une

  1. Créer. Réservez un dossier avec deux voyageurs et plusieurs prestations.
  2. Modifier. Changez un segment sans toucher aux autres.
  3. Annuler. Annulez un seul voyageur et vérifiez les frais.
  4. Rembourser. Rapprochez le montant décidé du mouvement de paiement.
  5. Informer. Vérifiez ce que voient le conseiller et le client à chaque étape.

Notez les actions disponibles dans l’interface, celles qui exigent un portail fournisseur et celles qui restent manuelles. Cette distinction doit figurer dans le choix de la solution.

Mesurez la résolution, pas seulement le volume de tickets

Regardez le délai jusqu’à une première réponse utile, le temps de résolution, les demandes rouvertes, les dossiers sans propriétaire et les montants en attente. Analysez les motifs récurrents : conditions mal expliquées, références absentes, erreurs de prix ou dépendance à un fournisseur. Un bon suivi transforme les incidents en améliorations du catalogue et du parcours de vente.

Suivre les changements de vol par étapes vérifiables

Pour un changement d’horaire, séparez alerte reçue, client informé, décision obtenue et action réalisée. Conservez l’ancien itinéraire : il permet de comprendre effets sur correspondances, transfert, nuit d’hôtel et rendez-vous. Le récapitulatif doit signaler les contrats indépendants dont la modification n’est pas automatiquement liée à celle du vol.

Un ticket de support peut se fermer après une réponse, alors qu’un document ou un service reste à actualiser. Le bilan du dossier suit ces tâches séparément avec responsable et prochaine action. Le guide consacré aux changements aériens donne une matrice de comparaison et des contrôles de clôture adaptés à cette situation.

Lire aussi : changements d’horaires aériens : de l’alerte au dossier utilisable.

Relier la demande du voyageur à l’état financier observé

Stripe documente des remboursements en attente et des cas d’échec ; une demande ne prouve donc pas sa réalisation.

Scénario fictif : une réservation est annulée mais le remboursement reste en attente. Le support doit retrouver la demande initiale, la réponse du fournisseur de voyage et l’objet de paiement. Préparez des messages qui expliquent l’état connu et la prochaine action sans promettre une date non confirmée. Si un second canal reçoit la même réclamation, rattachez-la au suivi existant avant d’engager une nouvelle opération.

Contrôles proposés pour ce scénario ; résultats à observer sur votre périmètre.
PointPreuve à conserverContrôle à effectuer
DemandeDossier, motif et canal.Rattacher deux contacts à la même affaire.
OpérationMontant, référence et état fournisseur.Séparer annulation de prestation et mouvement financier.
SuiteAction attendue et responsable.Garder ouverte une attente avec prochaine vérification.

Clôturez selon les preuves convenues et l’information transmise au client. Une réponse du support ne remplace pas un état de réservation ou de paiement.

Lecture d’une journée · demandes fictives

Sept clôtures peuvent accompagner une file qui augmente.

Une équipe commence la journée avec dix dossiers ouverts. Huit nouveaux dossiers arrivent et deux dossiers clôturés avant cette journée sont réouverts. Sept dossiers sont ensuite résolus et clôturés. Dans cet exercice, les huit nouveaux dossiers et les deux réouvertures correspondent à des références distinctes.

Rapprocher le stock de départ, les entrées et les sorties
ÉvénementVariationDossiers ouverts après l’événement
Début de journéePoint de départ10
Nouvelles demandes+818
Réouvertures de dossiers antérieurs+220
Résolutions et clôtures−713

Le volume traité ne décrit pas seul la situation des voyageurs.

La file passe de dix à treize dossiers ouverts, soit trois de plus, malgré les sept clôtures. Une clôture d’écran doit être rapprochée de l’issue métier : modification confirmée, prestation utilisable, remboursement expliqué ou autre résolution explicitement définie pour le dossier.

Comment lire l’ancienneté des treize dossiers ?

Supposons que cinq soient ouverts depuis moins de vingt-quatre heures, six depuis vingt-quatre à soixante-douze heures et deux depuis plus de soixante-douze heures. Ces groupes totalisent treize et ne se chevauchent pas. Ils décrivent l’âge, pas l’urgence : un départ imminent peut rendre prioritaire un dossier très récent.

Faut-il retirer les dossiers en attente du fournisseur ?

Gardez-les dans le suivi des dossiers ouverts et distinguez leur état d’attente du temps de travail actif. Précisez le responsable de la relance, la prochaine échéance et l’information destinée au voyageur. Déplacer un dossier dans une autre équipe ne constitue pas une résolution et ne doit pas le faire disparaître du rapprochement global.

Calcul de contrôle : ouverts en fin = ouverts au début + nouvelles demandes + réouvertures − clôtures, avec les mêmes règles de comptage. Si un dossier peut être clôturé puis réouvert dans la journée, suivez les événements et les références pour expliquer le solde sans confondre mouvements et dossiers uniques. Examiner le temps de traitement disponible · Définir les indicateurs de service.

Zendesk : une réponse après fermeture crée un autre ticket

Dans un service après-vente, une nouvelle demande peut reprendre une conversation ancienne sans conserver tous ses champs. Le parcours Zendesk fournit un exemple précis à contrôler.

Zendesk : une réponse après fermeture crée un autre ticket
Point documentéCe que la source préciseConséquence pour votre contrôle
Nouvelle référenceUne réponse à un ticket fermé crée un ticket de suivi qui référence le ticket initial.Conservez les deux références dans le dossier voyage ; ne comptez pas automatiquement ce mouvement comme la réouverture du même ticket.
Données non recopiéesCommentaires, priorité, type, organisation et external ID ne sont notamment pas repris.Requalifiez l’urgence et rétablissez le lien avec la réservation au lieu de supposer une transmission complète.
AffectationGroupe et agent ne sont pas repris par défaut ; un réglage administrateur peut les inclure. Les compétences suivent les règles de routage.Testez le paramétrage réellement actif avant de promettre le même interlocuteur.
Étiquettes conservéesLes étiquettes du ticket initial sont héritées ; un déclencheur peut les réinitialiser.Une ancienne étiquette d’escalade peut survivre au nouveau ticket : vérifiez sa pertinence pour la demande actuelle.

Reprendre la conversation sans perdre le dossier

Scénarios fictifs ; aucun ticket n’est créé ni modifié ici.

Une nouvelle urgence reprend un ancien ticket sans external ID

Le voyageur répond après la fermeture pour signaler un problème pendant son séjour.

Ticket initial : fermé
Ticket de suivi : nouvelle référence
external ID repris : non

Lecture du cas. Retrouvez le dossier à partir des références disponibles puis rattachez le nouveau ticket. L’ancienne priorité ne doit pas être considérée comme la qualification de cette urgence.

Le ticket de suivi n’arrive pas chez l’agent précédent

L’équipe pensait que toute réponse revenait au même conseiller.

Reprise du groupe et de l’agent : non configurée
Ticket : suivi d’un ticket fermé

Lecture du cas. Examinez la règle de routage et la prise en charge effective. Le lien vers l’ancien ticket ne signifie pas que le nouvel objet a conservé son affectation.

Exemple Zendesk consulté le 23 octobre 2026. Il décrit le ticket de suivi d’un ticket fermé, avec des réglages propres au compte ; il ne fixe pas le fonctionnement de tous les outils de support.

Zendesk — Understanding follow-up tickets · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.

Délai de première réponse : nommer la mesure avant de comparer

Deux durées affichées pour le même ticket peuvent mesurer des règles différentes. Le délai standard de première réponse et la cible de SLA doivent être distingués.

Délai de première réponse : nommer la mesure avant de comparer
Point documentéCe que la source préciseConséquence pour votre contrôle
Mesure standardFirst reply time mesure la durée entre création du ticket et premier commentaire public d’un agent.Une note interne n’est pas cette réponse publique ; conservez les événements qui définissent le début et la fin.
Deux calendriersAprès la première réponse, Zendesk conserve la mesure en heures calendaires et en heures ouvrées.Comparez les mêmes unités et horaires de service, sans mélanger deux colonnes portant des durées différentes.
SLA et résolutionLa cible SLA de première réponse peut être satisfaite lorsque le ticket est résolu, même sans commentaire public d’agent.Un objectif SLA satisfait ne suffit donc pas à démontrer qu’une réponse publique a été envoyée.
Horaires de la cibleUne cible SLA fonctionne en heures calendaires ou ouvrées. En heures ouvrées, le compteur s’interrompt hors des horaires de service.Examinez le calendrier et la politique appliqués au ticket avant d’annoncer un dépassement.

Lire le compteur avec son calendrier

Durées fictives destinées à expliquer la mesure ; aucun engagement fournisseur n’est calculé.

Un ticket arrive le vendredi avant la fermeture

Service fictif du lundi au vendredi, de 9 h à 18 h, sans jour férié ni changement d’heure dans ce scénario.

Création : vendredi 17 h 30
Première réponse publique : lundi 9 h 30
Durée calendaire : 64 h
Durée ouvrée : 1 h

Lecture du cas. Les deux durées décrivent le même intervalle avec des calendriers différents. Choisissez la mesure et la cible applicables avant de conclure à un retard.

Le ticket est résolu après une note interne

Le dossier ne contient aucune réponse publique d’agent.

Note interne : présente
Réponse publique : absente
Cible SLA : indiquée satisfaite à la résolution

Lecture du cas. Le résultat SLA peut correspondre à la règle documentée. Il ne prouve pas l’envoi d’une explication au voyageur ; contrôlez séparément la communication et le résultat métier.

Exemple Zendesk consulté le 23 octobre 2026. Les réglages SLA avancés et les canaux de conversation ont des règles propres ; cette lecture ne mesure pas la résolution opérationnelle du voyage.

Zendesk — Understanding ticket reply time · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.

Remboursement Stripe : retrouver la référence utile à la banque

Le service après-vente peut devoir aider un client dont le remboursement n’apparaît pas encore. Une référence de traçage et un identifiant de dossier ont des fonctions différentes.

Remboursement Stripe : retrouver la référence utile à la banque
Point documentéCe que la source préciseConséquence pour votre contrôle
Référence à transmettreStripe décrit ARN, STAN et RRN pour le traçage bancaire ; une seule de ces références suffit pour effectuer la recherche.Retrouvez la référence du remboursement concerné, avec le paiement et le montant, plutôt que d’envoyer seulement le numéro du dossier voyage.
ARN disponible ou nonL’ARN dépend des réseaux pris en charge ; son état peut être disponible, en traitement ou indisponible.L’absence d’ARN n’est pas, à elle seule, la preuve d’un remboursement échoué.
STANLe STAN est un code à six chiffres qui n’est pas véritablement unique, sa numérotation étant réutilisée.Gardez son contexte de paiement ; n’en faites pas la clé unique du registre des remboursements.
RRNLe RRN comporte douze caractères et peut être fourni pour certains réseaux ne prenant pas en charge l’ARN.Conservez le type exact de référence reçu ; ne renommez pas tout numéro de traçage en ARN.

Rapprocher la référence et le remboursement

Références et situations fictives ; aucune donnée bancaire réelle n’est saisie.

Deux lignes portent le même STAN fictif

Le registre cherche à identifier des remboursements à partir du seul code court.

STAN fictif : 004217
Paiements d’origine : différents
Clé interne envisagée : STAN seul

Lecture du cas. Ce code à six chiffres n’est pas une identité universelle. Conservez les identifiants du prestataire et le contexte de chaque paiement au lieu de fusionner les deux lignes.

Le tableau indique ARN indisponible

L’agent ne voit pas encore de référence ARN pour le remboursement.

État du remboursement : à relire
ARN : indisponible
Autre référence éventuelle : à rechercher

Lecture du cas. Relisez l’état et les références proposées pour le moyen de paiement. Ne transformez pas l’absence d’ARN en échec et ne promettez pas non plus un crédit bancaire déjà reçu.

Aide Stripe consultée le 23 octobre 2026. La présence d’une référence aide à tracer un remboursement ; elle ne prouve pas à elle seule que le crédit est déjà visible sur le compte du client.

Stripe Support — How to trace a refund using reference numbers · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.

VoiceMap : retrouver un achat selon le compte et le canal utilisé

Une bibliothèque vide ne prouve pas que l’achat a échoué. L’aide VoiceMap distingue le compte de connexion, le code d’un distributeur et la validation d’un paiement intégré avant de proposer un dépannage.

VoiceMap : retrouver un achat selon le compte et le canal utilisé
Point documentéCe que la source préciseConséquence pour votre contrôle
Méthode de connexionUn achat sur le site avec courriel et mot de passe n’apparaît pas dans un autre compte ouvert par une connexion Apple.Retrouvez la méthode utilisée lors de l’achat avant de recommander un nouvel achat du même tour.
Identité du compteLes réglages de l’application et le profil du site permettent de vérifier l’adresse liée au compte ; une adresse relais Apple peut différer du courriel habituel.Comparez le compte d’achat et celui de l’application, sans demander au voyageur de communiquer son mot de passe.
Achat auprès d’un distributeurLes achats Viator ou TripAdvisor ne sont pas reliés automatiquement au compte VoiceMap. Un code ou une référence doit être utilisé pour ajouter le tour.Distinguez la confirmation reçue du distributeur et l’ajout effectif dans la bibliothèque VoiceMap.
Paiement intégré débité, tour absentSi l’App Store ou Google Play a débité un achat non validé côté VoiceMap, l’aide demande le reçu et le nom du tour pour l’assistance.Préparez ces éléments et suivez la réponse du support. Le dépannage ne consiste pas à multiplier les paiements.

Retrouver l’achat avant de le refaire

Ordre de contrôle proposé à partir de l’aide VoiceMap, sans accès au compte du voyageur.

  1. Comparer les comptes

    Identifiez la méthode de connexion et l’adresse liées à l’achat, puis celles utilisées dans l’application.

  2. Identifier le canal

    Pour un distributeur externe, retrouvez le code ou la référence et vérifiez son utilisation dans VoiceMap.

  3. Suivre un débit sans tour

    Pour un achat intégré débité mais absent, préparez le reçu et le nom du tour pour l’assistance, puis retrouvez son résultat.

Deux achats invisibles à diagnostiquer

Comptes et références fictifs pour comparer les étapes du dépannage.

L’achat sur le site et l’application utilisent deux connexions

Une voyageuse fictive achète avec son courriel et un mot de passe, puis ouvre l’application avec une connexion Apple correspondant à un autre compte.

Achat : courriel et mot de passe
Application : connexion Apple, autre compte
Bibliothèque de l’application : tour absent

Lecture du cas. La bibliothèque du second compte ne démontre pas l’échec de l’achat. Retrouvez la connexion utilisée à l’achat et le tour correspondant avant de refaire payer. Vérifiez ensuite son téléchargement et les consignes de départ.

La confirmation du distributeur est reçue, mais le code reste inutilisé

Un voyageur fictif possède la confirmation de son distributeur et le code d’un tour VoiceMap, mais ne l’a pas encore utilisé dans l’application.

Canal : distributeur externe
Code du tour : retrouvé
Utilisation du code : pas encore effectuée

Lecture du cas. La confirmation du distributeur n’ajoute pas automatiquement le tour au compte VoiceMap. Suivez le parcours d’utilisation du code, vérifiez l’apparition du bon tour, puis son téléchargement avant le départ.

Aide VoiceMap indiquant une révision en août 2026, consultée le 23 octobre 2026. Une fois l’achat retrouvé, vérifiez le titre et la langue du tour, puis son téléchargement et le déclenchement audio sur l’appareil qui sera utilisé pendant la visite.

VoiceMap — I can’t find my purchase · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.

Voyageuse préparant une visite audio sur son téléphone, avec un casque et une carte dans un café fictif

Duffel : confirmer une modification de vol et lire le montant réellement dû

Ce parcours concerne une modification volontaire d’une commande. Une proposition créée dans l’API ne prouve pas que le nouveau vol est confirmé auprès de la compagnie.

Duffel : confirmer une modification de vol et lire le montant réellement dû
Point documentéCe que la source préciseConséquence pour votre contrôle
Changement en attenteLa création d’un pending order change doit être suivie de sa confirmation ; confirmed_at indique quand elle a eu lieu.Rapprochez le changement et la commande avant de communiquer le nouvel itinéraire.
Échéanceexpires_at fixe la limite de confirmation du changement.Affichez une heure compréhensible et revérifiez l’état avant toute action après une interruption.
Montants distinctschange_total_amount est le montant facturé ou remboursé ; new_total_amount est le nouveau total de commande ; penalty_total_amount désigne la pénalité compagnie.Ne facturez pas le nouveau total une seconde fois et ne rajoutez pas automatiquement la pénalité au montant du changement.
Montant négatifLe remboursement suit refund_to ; la documentation distingue ensuite le remboursement du client.Retrouvez le mouvement reçu et le règlement client séparément dans le rapprochement.

Du choix du vol au rapprochement du changement

Contrôles éditoriaux pour suivre une modification volontaire sans confondre proposition et exécution.

  1. Choisir la proposition

    Rattacher le nouveau trajet au bon dossier et aux voyageurs concernés.

  2. Relire le changement

    Contrôler échéance, montants, devises et conditions avant validation.

  3. Vérifier la confirmation

    Retrouver la réponse de confirmation et relire la commande actualisée.

  4. Rapprocher les règlements

    Suivre ce qui a été facturé ou remboursé et ce qui reste à régler avec le client.

Deux lectures de changement de vol

Valeurs et réponses fictives, sans appel à une API de réservation.

Le nouveau total est pris pour le supplément à payer

Une réponse fictive affiche les trois montants ci-dessous en euros.

new_total_amount : 450.00 EUR
change_total_amount : 35.00 EUR
penalty_total_amount : 15.00 EUR

Lecture du cas. Le montant du changement est 35 euros. Ne réclamez ni 450 euros ni 50 euros par addition automatique ; rapprochez séparément les éventuels frais propres à l’agence.

La proposition existe, mais sa confirmation manque

Un dossier fictif contient un changement créé, sans date de confirmation, et l’échéance est dépassée.

confirmed_at : null
expires_at : échéance passée
Commande actualisée : non contrôlée

Lecture du cas. Ne présentez pas le nouveau trajet comme acquis. Relisez l’état du dossier et reprenez le parcours approprié avant une nouvelle proposition au client.

Documentation Duffel consultée le 23 octobre 2026. Vérifiez les devises, les conditions tarifaires et les possibilités du dossier. Ce parcours de modification volontaire ne décrit pas à lui seul le traitement d’un changement imposé par la compagnie.

Duffel — Order Changes · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.

Examiner le dossier et son périmètre.

WeTravel : changer de voyage demande de reconstruire les prestations et les documents

Pour transférer une réservation vers un autre voyage, WeTravel propose Rebook to Another Trip. Préparez la nouvelle formule et les documents avant de valider l’opération.

WeTravel : changer de voyage demande de reconstruire les prestations et les documents
Point documentéCe que la source préciseConséquence pour votre contrôle
Voyage sélectionnableUn voyage complet ou dans une autre devise apparaît grisé et ne peut pas être choisi dans ce parcours.Vérifiez le voyage cible et sa capacité avant de proposer ce traitement.
Réservation d’origineLa réservation d’origine et ses voyageurs sont annulés définitivement ; les montants déjà payés sont déplacés vers le nouveau voyage.Relisez l’ensemble du dossier avant validation et traitez le solde ou un éventuel remboursement séparément.
Éléments non recopiésFormules, options, documents signés ou téléversés et réponses de formulaire ne sont pas recopiés.Reconstituez les prestations choisies et demandez les éléments nécessaires au nouveau voyage.
Courriels et rappelsUn courriel de nouvelle réservation est envoyé, sans courriel d’annulation. Les anciens rappels déjà envoyés gardent leur lien vers l’ancien voyage ; les suivants visent le nouveau.Transmettez la référence actuelle et expliquez au client quel espace utiliser.

Préparer le transfert avant de confirmer la nouvelle réservation

Quatre étapes de travail proposées, sans action sur une réservation réelle.

  1. Relire l’original

    Identifier voyageurs, prestations, paiements et documents utiles.

  2. Vérifier le voyage cible

    Contrôler capacité, devise, formule et nouvelles conditions.

  3. Reconstruire le dossier

    Reprendre les options et préparer la collecte des réponses et signatures.

  4. Contrôler les deux dossiers

    Vérifier annulation d’origine, nouvelle réservation, mouvements et liens transmis.

Deux dossiers à relire après un transfert

Réservations et messages fictifs ; aucun transfert n’est effectué.

Le paiement est repris, mais les options sont oubliées

Une réservation fictive est transférée vers un nouveau voyage. L’équipe constate les montants déplacés et suppose que le transfert comprend aussi une excursion et un document signé.

Montants déplacés : oui
Excursion dans le nouveau dossier : non contrôlée
Document signé du nouveau voyage : non vérifié

Lecture du cas. Retrouvez séparément les prestations et documents exigés dans le nouveau dossier. Le mouvement de paiement ne confirme ni l’excursion ni une signature applicable au nouveau voyage.

Un ancien rappel est utilisé après le transfert

Un client fictif ouvre un rappel de paiement reçu avant le transfert et voit l’ancien voyage.

Date du rappel : avant transfert
Lien ouvert : ancien voyage
Nouvelle réservation : créée

Lecture du cas. Renvoyez vers la réservation actuelle et contrôlez le solde de ce dossier. Un ancien lien conservé dans un courriel ne prouve pas que le transfert a échoué.

Aide WeTravel consultée le 23 octobre 2026. Le changement de voyage et le changement de formule dans un même voyage sont deux parcours distincts. Le transfert ne doit pas être utilisé comme une simple correction d’un champ.

WeTravel — How to transfer travelers to a different trip · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.

Examiner le dossier et son périmètre.

Sources et périmètre des faits documentés

La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.

  • Stripe : remboursements : États de remboursement documentés par Stripe ; aucune règle générale de délai juridique ou bancaire déduite. (consultée le )
  • Zendesk — Understanding follow-up tickets : Exemple Zendesk consulté le 23 octobre 2026. Il décrit le ticket de suivi d’un ticket fermé, avec des réglages propres au compte ; il ne fixe pas le fonctionnement de tous les outils de support. (consultée le )
  • Zendesk — Understanding ticket reply time : Exemple Zendesk consulté le 23 octobre 2026. Les réglages SLA avancés et les canaux de conversation ont des règles propres ; cette lecture ne mesure pas la résolution opérationnelle du voyage. (consultée le )
  • Stripe Support — How to trace a refund using reference numbers : Aide Stripe consultée le 23 octobre 2026. La présence d’une référence aide à tracer un remboursement ; elle ne prouve pas à elle seule que le crédit est déjà visible sur le compte du client. (consultée le )
  • VoiceMap — I can’t find my purchase : Aide VoiceMap indiquant une révision en août 2026, consultée le 23 octobre 2026. Une fois l’achat retrouvé, vérifiez le titre et la langue du tour, puis son téléchargement et le déclenchement audio sur l’appareil qui sera utilisé pendant la visite. (consultée le )
  • Duffel — Order Changes : Documentation Duffel consultée le 23 octobre 2026. Vérifiez les devises, les conditions tarifaires et les possibilités du dossier. Ce parcours de modification volontaire ne décrit pas à lui seul le traitement d’un changement imposé par la compagnie. (consultée le )
  • WeTravel — How to transfer travelers to a different trip : Aide WeTravel consultée le 23 octobre 2026. Le changement de voyage et le changement de formule dans un même voyage sont deux parcours distincts. Le transfert ne doit pas être utilisé comme une simple correction d’un champ. (consultée le )

Questions fréquentes

Questions utiles avant de décider

Qui doit répondre au voyageur lors d’une perturbation ?

Le point de contact doit être défini avant la vente et rester visible dans la confirmation. Les responsabilités exactes dépendent du produit, du contrat et du rôle de chaque intervenant.

Une API de réservation couvre-t-elle forcément les modifications ?

Non. Recherche, vente, échange, annulation et remboursement peuvent avoir des couvertures différentes. Faites démontrer chaque opération avec un dossier réel ou de test.

Quel indicateur suivre en priorité ?

Suivez le délai de première réponse utile et le temps de résolution, en distinguant les demandes simples, les urgences pendant le voyage et les dossiers dépendant d’un fournisseur.

Peut-on clôturer dès qu’un remboursement est demandé ?

Conservez le suivi de son état et des éventuels échecs. La clôture dépend de la preuve attendue et de la communication au voyageur.

Une réponse à un ticket Zendesk fermé conserve-t-elle sa priorité et sa référence externe ?

Le ticket de suivi est un nouveau ticket lié à l’ancien. La documentation exclut notamment la priorité et external ID des champs repris. Requalifiez la demande et vérifiez son rattachement au dossier voyage.

Quel montant lire pour payer une modification de vol Duffel ?

Lisez change_total_amount et sa devise. new_total_amount décrit le nouveau total de la commande ; penalty_total_amount désigne la pénalité compagnie. Vérifiez le signe du montant et la confirmation du changement avant de clôturer le dossier.

Approfondir la méthode

Modèles et champs associés

Les modèles reprennent les documents cités dans cette méthode et ses guides associés. Consultez les informations à rapprocher et les contrôles proposés.

Passer à la vérification

Des fiches de contrôle pour ce sujet

Champs à collecter, tests, erreurs fréquentes et consignes de transmission pour travailler sur un dossier concret.

Toutes les fiches de contrôle →

Étape suivante

Appliquez cette méthode à des solutions concrètes.

Explorez les catégories du répertoire puis vérifiez les capacités et conditions auprès des sources officielles.

Explorer le répertoireParler du projet