Une mission peut être marquée « terminée » par le prestataire alors que le client signale une absence, un livrable incomplet ou une réserve. Si ce statut déclenche immédiatement facture et reversement, la marketplace doit ensuite choisir entre deux récits sans chronologie partagée. Une capture d’écran arrive par email, l’agenda affiche un créneau et le support corrige le dossier à la main.
Le symptôme concret apparaît dans les factures annulées, les paiements bloqués, les no-shows contestés et les relances support. Le coût ne vient pas seulement de la fraude : un workflow mal conçu pénalise aussi le prestataire légitime qui a exécuté la mission mais ne possède pas la bonne preuve.
Le vrai enjeu d’une marketplace opérateur consiste à distinguer réalisation, acceptation, facturation et fin de réclamation. Contre-intuitivement, demander davantage de documents à chaque mission ne renforce pas toujours la preuve : cela augmente les données sensibles et le bruit, sans garantir que la pièce répond au désaccord réel.
La méthode suivante construit une chronologie opposable et proportionnée au type de service. Elle attribue chaque fait, prévoit les exceptions et relie les jalons au ledger. Le dossier peut donc fermer la mission tout en conservant une réserve ou une réclamation, sans réécrire l’histoire ni déclencher deux fois le même effet financier.
Définir ce qui termine réellement la mission
Décomposer la promesse en jalons
Le contrat sépare réservation, acceptation, démarrage, exécution, livrable, réception et clôture. Une prestation de conseil, une intervention à domicile et une location avec service n’utilisent pas la même preuve. Chaque jalon nomme donnée, auteur, délai et effet autorisé.
Le statut synthétique reste une projection. Le support doit retrouver les jalons sous-jacents. Une mission « clôturée avec réserve » n’équivaut ni à un échec total ni à une acceptation sans réserve. Cette nuance protège facturation partielle et médiation.
Choisir une preuve proportionnée au risque
Une prestation courte peut utiliser confirmation croisée ou code de présence ; un livrable complexe demande version, remise et acceptation. La valeur, l’irréversibilité, le risque de litige et les obligations applicables déterminent la robustesse. Le même dispositif n’est pas imposé à tous les services.
Le contrat indique aussi ce que la preuve ne démontre pas. Un GPS montre un passage, pas la qualité du travail. Une signature confirme une réception, pas nécessairement l’absence de défaut. Cette limite évite de promettre au support un verdict automatique impossible.
Attribuer les sources et responsabilités
Distinguer déclarant, témoin et décideur
Le prestataire déclare l’exécution, le client accepte ou réserve, un système tiers peut confirmer un rendez-vous, et l’opérateur arbitre certaines exceptions. Le journal conserve ces rôles. Une donnée fournie par une partie intéressée n’est pas rejetée, mais sa portée reste visible.
Le responsable de l’offre définit les règles, la finance contrôle l’effet et le support applique le runbook. L’administrateur technique ne décide pas du fond en modifiant un statut. Chaque correction passe par une commande métier attribuée.
Publier une matrice d’autorité
L’agenda fait foi pour le créneau prévu, le journal de mission pour les jalons, le PSP pour ses mouvements et le ledger pour la position financière. Un outil peut afficher une donnée sans devenir son maître. Cette matrice empêche les écrasements lors d’une réconciliation.
Les preuves externes portent identifiant, source, date d’occurrence et date de réception. Une réponse tardive enrichit le dossier sans annuler une décision plus récente. L’opérateur sait quelle source relire avant un remboursement ou un reversement.
Prouver acceptation et planification
Garder offre, créneau et version
L’acceptation lie prestataire, client, service, prix, conditions, lieu ou canal, créneau et version de l’offre. Une modification ultérieure ne réécrit pas la mission signée. Les changements produisent un avenant ou une nouvelle version acceptée.
Les deux parties voient la date limite d’annulation et les conséquences. Une réservation en attente n’engage pas le prestataire comme une acceptation ferme. Le moteur de disponibilité ne vend pas le même créneau lorsque l’engagement devient exclusif.
Traiter replanification et chevauchement
Une replanification conserve ancien créneau, demandeur, motif et nouvelle acceptation. Elle ne supprime pas la première réservation, utile pour comprendre retard ou no-show. Les agendas concurrents sont vérifiés au moment de la confirmation.
Cas concret : un prestataire accepte deux missions éloignées de trente minutes. Le contrôle détecte l’incompatibilité avant le second engagement et propose un autre créneau. S’il apparaît après synchronisation, la file attribue la décision et informe les parties sans choisir silencieusement l’une des missions.
Tracer le début et la fin d’exécution
Combiner plusieurs signaux faibles
Heure de connexion, code ponctuel, confirmation client, journal de tâche ou équipement peuvent confirmer une exécution. Aucun signal n’est universel. Le workflow combine ceux qui répondent au risque sans transformer la plateforme en outil de surveillance permanente.
Les horodatages séparent événement et réception. Un mode hors ligne peut transmettre plus tard. La règle accepte ce retard si l’intégrité est préservée, mais signale une preuve arrivée après l’ouverture d’un litige.
Empêcher une clôture unilatérale trompeuse
Le prestataire peut déclarer terminé, mais cette déclaration n’est pas forcément l’acceptation client. Le dossier passe dans une fenêtre de revue ou attend un signal complémentaire. L’interface nomme « déclaré terminé » au lieu de « validé ».
Si le client ne répond pas, une acceptation tacite peut exister seulement si le contrat et le contexte le prévoient. La date, les notifications et la possibilité de réserve sont prouvées. Le support ne fabrique pas une réponse manquante.
Faire accepter livrables et réserves
Versionner ce qui a été remis
Le livrable porte identifiant, version, empreinte, date et canal. Un lien modifiable sans historique ne prouve pas ce que le client a reçu. Le stockage applique les droits et durées adaptés ; la marketplace peut conserver une empreinte et une référence plutôt que tout le contenu.
Les critères d’acceptation sont définis avant l’exécution. Le client peut accepter, accepter avec réserves ou refuser avec motif structuré. Une réserve indique correction attendue et échéance. Elle n’annule pas automatiquement toute la mission.
Fermer les corrections successives
Chaque correction crée une nouvelle version reliée à la réserve. Le workflow évite les échanges parallèles par email dont personne ne connaît le dernier état. Le prestataire voit la liste fermée des points attendus.
Un plafond de cycles ou une étape de médiation évite une boucle infinie. Si trois remises échouent sur le même critère, alors le dossier passe à un responsable au lieu de prolonger automatiquement le délai de paiement.
Traiter annulation, retard et no-show
Qualifier l’événement avant la compensation
Annulation client, indisponibilité prestataire, retard, impossibilité technique et absence ne produisent pas la même responsabilité. Le dossier conserve déclarations, notifications, créneau et signaux. La règle versionnée calcule frais ou geste après qualification.
Le no-show n’est pas déduit d’un bouton unique. Le prestataire peut avoir oublié de démarrer le suivi, ou le client être présent sur un autre canal. Les signaux contradictoires créent une revue avec délai et pièces attendues.
Libérer capacité et prévenir les parties
Une annulation confirmée libère le créneau une seule fois et met à jour les disponibilités. Elle informe les parties avec le motif autorisé, sans exposer une donnée privée. La compensation financière suit ensuite son propre état.
Le signal faible est une hausse de créneaux bloqués après annulation ou de missions rouvertes après facturation. Le monitoring rapproche agenda et workflow. Une divergence au-delà de quinze minutes déclenche une action avant de dégrader le matching.
Déclencher une facture au bon jalon
Séparer exigibilité et émission
La mission atteint un jalon facturable selon contrat : acceptation, fin de fenêtre de réserve ou étape partielle. Le moteur produit une commande de facturation avec base, quantité, taxes, commission et référence de mission. L’émission ne dépend pas d’un statut librement modifiable.
Une mission partielle peut générer plusieurs lignes ou échéances. Les montants sont calculés depuis les versions acceptées. Un geste commercial devient un mouvement distinct, pas une altération opaque du prix historique.
Rendre l’effet financier idempotent
La clé associe mission, jalon, bénéficiaire et type d’effet. Un retry après timeout ne crée pas une seconde facture ni un second reversement. Le service relit l’opération avant de recommencer.
Une annulation de facture ou un avoir compense l’écriture précédente et conserve le lien. Le support n’efface pas une facture pour refermer un litige. Ledger, facture et PSP peuvent ainsi être rapprochés.
Ouvrir une réclamation sans réécrire les faits
Créer un dossier lié à la mission
La réclamation possède motif, demande, pièces, échéances et périmètre financier. Elle référence les jalons sans les modifier. Une contestation sur la qualité n’efface pas la présence ; une contestation de no-show ne change pas directement l’agenda.
Le dossier distingue fait admis, fait contesté et décision provisoire. Les parties connaissent les preuves attendues et la date. Le support évite les demandes successives de documents déjà reçus.
Geler seulement l’effet nécessaire
Une réclamation peut suspendre un reversement, réserver une somme ou laisser payer la partie non contestée. Le gel total n’est pas automatique. La règle dépend du montant et du risque, avec owner et condition de sortie.
La décision finale produit remboursement, complément, avoir ou maintien. Elle cite les faits et la version de politique. Une voie de recours éventuelle crée un nouvel état ; elle ne remplace pas le premier verdict.
Minimiser les preuves et leurs accès
Collecter ce qui répond au désaccord
Une photo, une localisation ou un document d’identité n’est pas requis par défaut. La finalité, le risque et le type de prestation commandent la preuve. Une confirmation ou une empreinte peut suffire là où le contenu intégral n’apporte rien.
Les champs libres sont limités et les pièces contrôlées. Le prestataire ne doit pas téléverser des données client inutiles pour se protéger. L’interface explique ce qui sera partagé avec l’autre partie et avec l’opérateur.
Définir accès, durée et purge
Chaque catégorie possède une durée liée au contrat, à la réclamation et aux obligations applicables. Une purge automatique retire le contenu, tout en conservant la preuve minimale autorisée si nécessaire. Les journaux de purge sont eux-mêmes bornés.
Les rôles séparent support, finance et administrateurs. Une pièce de litige n’est pas visible à tous les seller managers. Les accès sensibles sont journalisés et revus, avec une procédure d’export encadrée.
Ordonner événements et effets idempotents
Accepter doublons et ordre imparfait
Agenda, application mobile, facturation et PSP livrent leurs événements à des rythmes différents. Chaque message conserve identifiant, occurrence, réception et corrélation. Le consommateur déduplique l’effet et relit l’état avant une transition incompatible.
Une acceptation tardive peut enrichir le dossier après facturation sans créer une nouvelle facture. Une annulation reçue après exécution part en revue. La chronologie garde le fait tout en protégeant l’état courant.
Utiliser des compensations explicites
Mission, facture et paiement ne partagent pas une transaction technique. Le workflow commande chaque effet et mémorise son résultat. En cas d’échec partiel, le dossier indique exactement l’étape en attente.
Le rollback arrête les nouveaux effets et emploie avoir, remboursement ou mouvement inverse selon le cas. Il ne supprime pas les événements. L’équipe peut alors reprendre depuis la dernière décision confirmée.
Réconcilier mission, paiement et comptabilité
Construire une balance par jalon
Le rapprochement compare missions facturables, factures émises, paiements capturés, reversements, remboursements et réclamations. Il retrouve chaque identifiant, pas seulement les totaux. Les états « attendu », « en attente », « différent » et « exclu » sont distingués.
Un dossier fermé doit avoir un résultat pour chaque jalon obligatoire et chaque effet financier. Une exception ouverte possède owner et échéance. La balance quotidienne détecte les pertes silencieuses avant la clôture comptable.
Prioriser les écarts irréversibles
Un double reversement passe avant une preuve manquante sur une mission non facturée. La file combine montant, risque client, ancienneté et capacité de compensation. Elle rend la priorité visible au support et à la finance.
Exemple concret : sur 500 missions, 7 factures manquent, 3 reversements n’ont pas de mission acceptée et 1 remboursement semble doublé. La finance bloque le doublon, examine les trois expositions puis réémet les sept commandes idempotentes.
Éviter les erreurs fréquentes
Faire du bouton terminé une preuve
Une déclaration unilatérale ne démontre ni présence, ni qualité, ni acceptation. Elle constitue un jalon parmi d’autres. Le workflow la combine avec les preuves proportionnées au service et laisse une fenêtre de réserve.
Autre erreur : demander la même photo ou signature partout. Cette collecte augmente exposition et charge sans améliorer les arbitrages. Le contrat doit préciser la question à laquelle chaque donnée répond.
Confondre clôture et absence de recours
Une mission peut être administrativement terminée tout en gardant une réclamation ouverte. Réouvrir le statut principal perturbe facturation, agenda et reporting. Les axes restent séparés jusqu’à leurs résultats propres.
Enfin, corriger directement facture et statut détruit la causalité. Toute action produit un événement, une compensation et une trace. Le prochain rapprochement ne doit pas annuler une correction invisible.
Plan d’action pour une première prestation
Fermer le contrat de preuve
L’équipe choisit un service, une valeur et un mode d’exécution. Elle décrit entrées, sorties, responsabilités, dépendances, jalons, preuves, seuils et effets financiers. Dix missions anonymisées couvrent réussite, réserve, annulation, no-show et livrable corrigé. Le responsable offre valide ce que chaque signal démontre. Pour chaque scénario, une fiche précise l’auteur autorisé, l’horodatage de référence, la preuve attendue, la durée de contestation et l’effet interdit tant que le dossier reste ambigu. Cette fiche devient le contrat commun du produit, du support, de la finance et des prestataires pilotes.
La mise en œuvre prépare journalisation, file d’événements, idempotence, monitoring et rollback. Le back-office affiche chronologie, source, pièce, statut de réclamation et prochaine action. Les règles d’accès, conservation et purge sont testées avant l’ouverture. Un export de contrôle doit reconstituer chaque transition sans consulter une boîte email ni demander une explication au développeur. Le responsable financier rapproche ensuite les identifiants de mission, facture, paiement et reversement sur les mêmes dossiers, tandis que le support mesure le temps réellement nécessaire pour conclure chaque exception.
Tester le repli puis étendre
La recette provoque doublon, événement tardif, facture en timeout, annulation après démarrage et preuve contradictoire. Elle vérifie qu’une mission, une facture et un mouvement financier restent explicables. Le support traite un dossier sans aide orale. Une seconde personne reprend le même dossier depuis la seule chronologie et doit parvenir à la même décision ; tout écart révèle une règle implicite à documenter avant le pilote.
Le canary limite prestataires et volume pendant deux cycles. Si un double effet apparaît ou si plus de 2 % des missions exigent une correction directe, alors les nouveaux effets financiers reviennent au flux précédent. Les preuves restent collectées pour corriger la cause. Une revue quotidienne classe les écarts par service, motif et source, puis attribue chaque correction à un propriétaire et à une échéance. L’extension n’est autorisée qu’après un cycle complet sans mouvement orphelin, pièce inaccessible ni dossier bloqué au-delà du délai convenu.
- À faire d’abord : séparer exécution, acceptation, facture et réclamation.
- À tester ensuite : no-show, réserve, événement tardif et timeout financier.
- À différer : l’automatisation des services dont la preuve reste subjective.
- À refuser : toute pièce collectée sans finalité, durée ni accès définis.
Guides complémentaires pour l’opérateur
Relier service et socle marketplace
Le MVP marketplace à livrer avant l’ouverture aide à borner les premières catégories et leurs preuves. L’opérateur ne doit pas ouvrir un service sans chemin de clôture.
Le cadre de marketplace de services complète agenda, qualification, matching et paiement. La preuve se construit depuis cette promesse, pas après les premiers litiges.
Outiller support et exceptions
Les écrans indispensables du back-office donnent une base pour chronologie, preuves, réclamations et compensations.
Le dossier sur la première catégorie marketplace aide à choisir un canary représentatif et réversible avant l’extension des prestations.
Conclusion : fermer sans effacer le désaccord
La preuve de service rendu n’est pas un document universel. Elle assemble des jalons, des auteurs et des signaux proportionnés à la prestation et au risque.
Mission, acceptation, facture et réclamation gardent des états distincts. Les événements idempotents et les compensations protègent la finance sans masquer les réserves ou les contestations.
Un pilote réduit permet de tester no-show, retard et contradiction avant l’ouverture. Le support peut alors expliquer chaque décision, reprendre un effet et conserver seulement les données utiles.
Pour concevoir le workflow, intégrer agenda, facturation et paiement, Dawap peut vous accompagner dans votre projet de marketplace opérateur, du premier créneau à la réconciliation comptable.
