À 14 h 12, un prestataire marque l’acheteur absent et réclame ses frais. L’acheteur affirme attendre depuis 13 h 50 devant le bâtiment. Le rendez-vous indiquait « 14 h », sans durée de tolérance ni point précis. Un appel a été tenté, mais aucun système ne conserve son résultat.
Le problème déclenche deux compensations incompatibles : le support rembourse l’acheteur pendant que Finance crédite le prestataire. Le créneau reste bloqué jusqu’au soir, une nouvelle mission est refusée et chacun apprend qu’il suffit d’une capture d’écran pour imposer sa version.
Le vrai enjeu du no-show dans une marketplace opérateur est de distinguer absence, retard, annulation et impossibilité d’accès depuis des preuves équitables. Contre-intuitivement, automatiser la sanction sur la géolocalisation seule favorise le signal le plus facile à collecter, pas forcément le fait le plus juste.
Vous allez comprendre comment contractualiser le rendez-vous, collecter présence et communication, qualifier la cause, attribuer responsabilité, calculer compensation et remettre la capacité en circulation. Entrées, sorties, owners, délais, seuils, instrumentation, monitoring, file, retry et rollback encadrent chaque verdict.
Définir le no-show
Poser une définition observable
Un no-show survient lorsqu’une partie ne se présente pas dans la fenêtre et au lieu convenus, sans annulation recevable, après les tentatives de contact prévues. La définition contient début, fin, tolérance, canal et conditions d’accès.
Le statut n’est jamais sélectionné dès l’heure exacte. Une mission peut être en retard, bloquée ou impossible. Le workflow attend les événements et ouvre une qualification lorsqu’ils se contredisent.
Adapter l’unité au service
Une consultation vidéo, une intervention à domicile, une collecte et une réservation de matériel n’ont pas le même point de présence. Le contrat décrit le geste attendu : rejoindre une salle, sonner, scanner un code ou remettre un objet.
La durée de tolérance dépend du service, de la valeur et de la capacité perdue. Elle est annoncée avant la réservation. Le support ne l’invente pas après le conflit selon la partie la plus insistante.
Le protocole précise également la sortie de la fenêtre. Une partie ne peut pas déclarer l’absence puis quitter immédiatement si deux tentatives de contact et quinze minutes d’attente sont requises. Inversement, l’attente ne se prolonge pas sans limite. À l’heure de fin, le système ferme la collecte ordinaire, qualifie les événements disponibles et donne un délai déterminé pour joindre une pièce complémentaire.
Contractualiser le rendez-vous
Figer temps, lieu et prérequis
La réservation snapshotte timezone, fenêtre, adresse normalisée, point de rencontre, contact masqué et prérequis. Une modification produit un événement accepté par les parties. La fiche actuelle du prestataire ne réécrit pas la mission.
Les instructions décrivent accès, équipement et document à préparer. Une condition ajoutée dans un message la veille n’est pas automatiquement contractuelle. Le dossier distingue proposition et avenant accepté.
Le point de rencontre utilise un identifiant stable et des coordonnées vérifiées. « Devant la gare » ou « entrée principale » peut désigner plusieurs lieux. Le parcours montre photo ou repère commun lorsque nécessaire, sans exposer une adresse privée au-delà du besoin. Une modification initiée par le prestataire est envoyée à l’acheteur et ne devient active qu’après acceptation enregistrée ou règle de repli connue.
Rappeler sans fabriquer une réception
Les rappels indiquent date, lieu, tolérance et méthode d’annulation. Leur délivrabilité est conservée. Un SMS envoyé n’est pas nécessairement reçu, mais une erreur connue déclenche un autre canal selon policy.
Les contacts restent protégés par relay lorsque possible. La confirmation invite chaque partie à signaler une incohérence avant le créneau. Les changements tardifs rejoignent un workflow plutôt qu’une note libre.
Collecter des preuves symétriques
Enregistrer arrivée et attente
Chaque partie peut check-in avec booking_id, instant, méthode et contexte. GPS, QR, code de salle ou action web sont des indices dont la précision est connue. Aucun n’est obligatoire si le service ne le permet pas.
La preuve conserve valeur source, score et version. La géolocalisation est minimisée et contrôlée. Un point à cinquante mètres peut être compatible avec un immeuble, tandis qu’un GPS précis ne prouve pas qu’une personne a sonné.
Le check-in doit fonctionner avec réseau faible. L’application peut signer localement l’événement, afficher sa mise en attente puis le transmettre avec occurred_at et received_at. Un retry conserve event_id. Le serveur contrôle fenêtre et cohérence sans rejeter automatiquement un envoi tardif. Les événements impossibles ou dupliqués rejoignent une revue ; ils ne déplacent pas silencieusement l’heure d’arrivée vers celle de réception.
Tracer les tentatives de contact
Le relay journalise appel initié, connecté, durée et résultat, sans exposer le numéro. Un message garde délivrabilité et heure. Une tentative d’une seconde ne satisfait pas nécessairement le protocole.
Les entrées sont booking, parties, événements et tolérance ; les sorties sont présence confirmée, absence présumée ou preuve insuffisante. Trust Operations est owner. Instrumentation, dépendances et runbook protègent le workflow.
Séparer annulation et absence
Appliquer la fenêtre d’annulation
Une annulation possède auteur, occurrence, motif et canal. Sa politique dépend du temps restant et de la capacité récupérable. Une demande envoyée avant le cut-off mais reçue tard à cause de la plateforme conserve son occurrence.
Le parcours affiche frais ou remboursement avant confirmation. Un timeout ne doit pas produire une annulation incertaine. L’idempotency key permet de rejouer sans débiter deux fois.
La fenêtre est conçue avec l’économie du service. À quarante-huit heures, un prestataire peut encore revendre le créneau ; à dix minutes, déplacement et préparation sont consommés. Le barème relie donc temps restant, coût évitable et capacité récupérée. Il ne transforme pas les frais en revenu automatique : si le slot est revendu, la policy peut réduire la compensation ou financer un geste acheteur.
Traiter report et modification
Proposer un nouveau créneau ne libère pas l’ancien tant que l’autre partie n’a pas accepté, sauf règle explicite. Le hold protège la nouvelle capacité pendant la réponse. L’expiration revient à la réservation initiale.
Une modification d’adresse peut rendre le prestataire indisponible. Le moteur recalcule éligibilité et coût avant avenant. Le refus ne devient pas un no-show du prestataire lorsque la destination a changé hors contrat.
Qualifier la cause
Distinguer retard, accès et absence
Le dossier reconstitue fenêtre, check-in, contact, instructions et événements. Il qualifie présent, retard, mauvais lieu, accès impossible, annulation non transmise ou absence. Les faits peuvent rester insuffisants.
Une preuve contradictoire ouvre une revue humaine. Le système ne choisit pas automatiquement le signal le plus précis. Il indique quelles données manquent et leur possibilité de collecte.
Isoler cause externe
Transport interrompu, urgence, météo ou panne de plateforme peuvent empêcher les deux parties. La policy définit force majeure et justificatifs selon le contexte validé. Le motif ne supprime pas les faits.
Par exemple, une panne de visioconférence confirmée sur 120 sessions ne crée pas 120 no-shows utilisateurs. L’incident parent annule les sanctions, déclenche report ou remboursement et conserve l’impact par booking.
Attribuer la responsabilité
Comparer obligations des parties
Le reviewer vérifie ce que chacun devait faire : arriver, attendre, contacter, fournir l’accès ou préparer une ressource. Il compare preuve et fenêtre. Une faute partagée est possible si le prestataire est en retard et l’acheteur quitte avant la tolérance.
La décision cite faits retenus, obligations, exceptions et version de policy. Elle ne déduit pas la responsabilité de l’identité seller ou buyer. Les mêmes exigences de preuve s’appliquent aux deux côtés.
Une responsabilité partagée reçoit une explication, pas un arrondi par défaut à 50/50. Le reviewer peut retenir 70 % de perte côté prestataire lorsqu’il arrive hors tolérance et 30 % côté acheteur lorsqu’il quitte sans utiliser le canal prévu. La clé influence uniquement les effets autorisés par la policy ; elle ne produit pas une note morale ni un score durable sans base distincte.
Gérer preuve insuffisante
L’absence de preuve ne vaut pas automatiquement faute de l’autre partie. Le verdict peut être indéterminé avec une répartition prévue. La marketplace assume le coût de son instrumentation insuffisante selon policy.
Les cas indéterminés alimentent la roadmap : point de rencontre ambigu, relay non instrumenté ou check-in inaccessible. Leur taux est suivi. Une correction produit une meilleure preuve future, pas une requalification du passé.
Construire la matrice de décision
Relier cause et effet
La matrice combine responsable, délai, capacité perdue, récidive et preuve. Elle renvoie remboursement, frais, compensation, report et signal de confiance. Une sanction de compte reste séparée du règlement d’une mission.
Les premiers cas ou faibles montants peuvent recevoir une mesure éducative. La récidive augmente la revue, pas automatiquement la sanction. Les erreurs de la plateforme restent à la charge de l’opérateur.
Un exemple concret teste la matrice : rendez-vous de 100 euros, acheteur absent, prestataire arrivé et deux appels connectés sans réponse. Le barème peut rembourser zéro, créditer 60 euros de capacité perdue et conserver 40 euros pour les frais prévus. Si le prestataire n’a effectué aucune tentative, alors le dossier quitte l’automation et le reviewer décide depuis les autres preuves.
Poser des seuils proportionnés
Le montant maximal est lié au service réservé et au coût évitable, pas à un forfait arbitraire. Les seuils d’automatisation sont plus bas que les droits humains. Un cas sensible ou contradictoire reste revu.
Si plus de 3 % des décisions automatiques sont infirmées sur cinquante cas ou si une catégorie dépasse 8 % d’indéterminés, alors l’automation s’arrête. L’owner audite règle, données et interface avant réactivation.
Appliquer la compensation
Séparer mouvements financiers
Remboursement acheteur, crédit prestataire, frais et geste opérateur sont des mouvements distincts. Chacun cite decision_id et booking_id. Le ledger empêche double remboursement et double compensation.
Le montant settled est distingué de la commande envoyée au PSP. Un timeout rejoint une file de statut. Le support ne confirme pas l’argent avant une référence de mouvement stable.
La base fiscale et le bénéficiaire sont conservés par mouvement. Un remboursement du service, une compensation opérateur et des frais d’annulation ne partagent pas nécessairement la même nature comptable. Finance valide les codes et les expose dans la facture seller. Toute correction passe par une écriture compensatoire liée au verdict ; l’agent support ne modifie jamais directement le solde pour calmer un échange.
Informer chaque partie
La notification décrit faits retenus, effet, calendrier et recours. Elle protège les données de l’autre partie. Une raison générique « policy appliquée » ne permet pas de comprendre ni de corriger.
Le prestataire voit la capacité compensée et son impact sur payout ; l’acheteur voit remboursement ou frais. Les montants, taxes et devises sont explicites. Les communications restent reliées au verdict.
Remettre la capacité en circulation
Libérer le créneau au bon moment
À l’annulation ou au no-show confirmé, la ressource devient disponible selon le temps restant. Une mission déjà commencée ne libère pas automatiquement toute sa durée. Le calendrier reçoit un événement idempotent.
Le moteur peut proposer une liste d’attente ou une mission courte. Il ne surbooke pas la ressource pendant la qualification si une arrivée tardive reste possible. La tolérance protège les deux engagements.
Proposer un report contrôlé
Un report conserve lien avec la mission, motif, prix et compensation. Il réserve un nouveau slot après accord. Les tentatives sont bornées pour ne pas bloquer indéfiniment de la capacité gratuite.
Operations mesure temps de remise en vente, taux de report et réalisation suivante. Une reprise réussie ne supprime pas le no-show initial, mais réduit son impact économique et relationnel.
Organiser le recours
Ouvrir un dossier contradictoire
La partie conteste dans une fenêtre avec motif et pièces. Le reviewer voit réservation, événements, communications, verdict et mouvements. Il ne demande pas de reconstruire les informations déjà détenues.
L’autre partie peut répondre lorsque nécessaire. Les délais et accès sont proportionnés. Un recours n’annule pas tous les effets par défaut ; la policy définit ce qui reste en suspens.
Corriger sans effacer
Le verdict d’appel confirme, modifie ou annule. Il ajoute des mouvements compensatoires et corrige les signaux de confiance. L’historique initial reste visible avec sa version de preuve.
Le taux d’infirmation est segmenté par motif, catégorie et reviewer. Une hausse signale une matrice ou une instrumentation fragile. Les apprentissages modifient la prochaine version, pas les dossiers clos sans recours.
Prévenir récidive et abus
Mesurer le funnel du rendez-vous
Le dashboard suit confirmations, annulations, retards, no-shows, indéterminés, reports, recours et compensation. Il segmente service, vendeur, zone, créneau et canal. Un taux global masque un point de rencontre défectueux.
La mesure rapproche aussi délivrabilité, check-in et incidents. Une baisse après rappel peut indiquer efficacité, ou seulement une sélection de clients. Les cohortes et coûts permettent de distinguer.
La revue hebdomadaire prélève les services aux taux extrêmes et relit dix dossiers. Elle cherche instructions ambiguës, créneaux irréalistes, durée de trajet, utilisateurs nouveaux ou défaut de notification. Un taux élevé chez un seller n’entraîne pas automatiquement une sanction : il peut révéler un point de rencontre fermé ou une zone trop large. L’action cible la cause avant le compte.
Détecter stratégie et biais
Des déclarations systématiques à la fin de la tolérance, coordonnées identiques ou compensations concentrées peuvent signaler abus. Le contrôle ouvre une enquête ; il ne sanctionne pas sur un score opaque.
Le monitoring détecte décisions sans preuve, mouvement orphelin, créneau non libéré et signal de confiance divergent. Chaque alerte possède owner, seuil et runbook. La réconciliation quotidienne descend au booking.
Adapter la méthode et éviter les erreurs
Pour qui le workflow no-show convient
Il concerne services sur rendez-vous, location, collecte, réservation et visioconférence. Une petite marketplace peut commencer avec fenêtre, contacts, revue humaine et ledger avant d’ajouter check-in ou automatisation.
Service Operations possède la policy, Trust la décision sensible, Finance les mouvements, Produit le parcours et Platform les événements. Chaque catégorie possède une définition et une tolérance validées.
Erreurs fréquentes du no-show
Laisser une partie déclarer seule, utiliser GPS comme verdict, ignorer la tolérance, confondre annulation et absence, compenser hors ledger et sanctionner sans recours sont les erreurs majeures.
Une autre erreur consiste à oublier la capacité bloquée. Enfin, une matrice identique pour tous les services ignore leurs preuves et coûts. La symétrie du processus compte autant que sa vitesse.
Plan d’action pour traiter les no-shows
Semaines 1 à 4 : définition et preuve
La première semaine analyse cinquante absences contestées. La deuxième définit rendez-vous, tolérance, contact, annulation et faits par service. La troisième instrumente événements ; la quatrième crée timeline et codes raison.
Les tests jouent acheteur absent, prestataire absent, retard partagé, mauvais lieu, accès fermé, panne plateforme et preuve contradictoire. Chaque cas produit une population, une responsabilité ou un statut indéterminé.
Semaines 5 à 8 : décision et reprise
La cinquième semaine construit matrice et ledger ; la sixième ajoute recours, capacité et communications. L’instrumentation suit décisions, mouvements, créneaux, recours et récidives avec seuils, owners et runbooks.
Les semaines sept et huit ouvrent une catégorie, testent timeout paiement, relay indisponible et rollback d’automation. Le go exige vingt dossiers reproductibles, aucun double mouvement et chaque créneau rapproché.
Le paquet de run conserve definitions, policies, fixtures, modèles de message, droits, seuils et procédures d’incident. Une personne extérieure au projet doit retrouver un booking, expliquer le verdict et reprendre une compensation en échec. L’exercice chronométré vérifie que la preuve n’existe pas seulement dans la mémoire de l’agent.
La décision d’extension compare aussi taux d’indéterminés, temps de revue et capacité regagnée. Si la preuve devient plus complète mais que le support met deux fois plus de temps, alors l’owner simplifie l’interface ou limite l’automation à un cas mieux borné. En revanche, un faible volume ne justifie pas l’abandon des événements fondamentaux : rendez-vous, contact, verdict et mouvement restent obligatoires dès le pilote.
- À faire d’abord : définir rendez-vous, tolérance, contacts, preuves et responsabilités.
- À tester ensuite : retard, contradiction, compensation, recours, reprise et rollback.
- À différer : la sanction automatique tant que les indéterminés restent élevés.
- À refuser : tout verdict fondé sur une déclaration ou une géolocalisation isolée.
Ressources complémentaires pour l’opérateur
Borner les premiers rendez-vous
Le MVP marketplace avant ouverture aide à choisir événements et compensations initiales.
La méthode pour ouvrir une première catégorie fournit une cohorte observable.
Structurer service et décision
Le catalogue PIM marketplace porte les prérequis du service.
Les écrans du back-office opérateur outillent timeline, verdict et action.
Conclusion : décider depuis les faits
Un no-show fiable se définit par une fenêtre, un lieu, des obligations et des preuves accessibles aux deux parties.
Qualification, matrice et recours distinguent absence, retard, annulation et incident sans automatiser le biais.
Compensation, ledger et remise en capacité ferment les effets financiers comme opérationnels.
Dawap peut vous accompagner pour fiabiliser les rendez-vous et leurs preuves dans votre marketplace opérateur.
