Un acheteur accepte par email un devis de cent lignes après trois semaines d’échanges. Le vendeur modifie ensuite la livraison et la taxe dans son tableur, puis convertit la dernière copie en commande. À la réception, personne ne sait si l’accord portait sur la version signée, sur le fichier joint ou sur la ligne corrigée dans le back-office.
Le problème vient d’un devis traité comme un document final alors qu’il s’agit d’un workflow. Besoin, hypothèses, prix, commentaires, validations et durée changent. Sans versions immuables, chaque correction réécrit la preuve et le support reconstruit manuellement une chronologie incomplète.
Le vrai enjeu d’un workflow de devis sur une marketplace opérateur est de faire porter l’engagement sur une version complète et identifiable. Contre-intuitivement, multiplier les versions explicites simplifie la relation : chacun sait ce qui est proposé, comparé, accepté ou expiré.
Vous allez comprendre comment modéliser demande, lignes, versions, commentaires, validations et conversion. Les calculs conservent leurs entrées ; les changements produisent un diff, puis la commande reprend exactement la version acceptée ou demande un nouvel accord.
Définir le contrat du devis
Séparer estimation et offre ferme
Une estimation oriente avec hypothèses ; une proposition détaille un périmètre ; un devis accepté engage selon ses conditions. L’interface nomme le niveau. Un montant indicatif ne devient pas un prix garanti parce qu’il apparaît dans un PDF.
Le type de devis indique fournisseur, client, devise, taxes, validité et conditions. Les mentions et pièces nécessaires suivent la verticale. Produit et juridique valident ce contrat avant l’automatisation.
Définir la sortie attendue
Le devis peut ouvrir une commande, une visite, un acompte ou une négociation. Sa sortie est explicite. Un accord sur le prix ne vaut pas acceptation d’une date ou d’une exclusion cachée.
Les conditions de réussite nomment éléments obligatoires et réserves autorisées. Une version incomplète reste brouillon. Le vendeur ne peut pas envoyer un document dont le système ne sait pas calculer le total.
Le contrat précise aussi qui supporte un changement après acceptation. Une variation de quantité demandée par le client, une taxe nouvelle ou une erreur vendeur n’emportent pas la même responsabilité. Cette règle détermine nouvelle version, maintien éventuel du prix, besoin d’approbation et communication, sans laisser le commercial improviser au cas par cas.
Une convention de numérotation distingue dossier et version, puis suit tous les canaux. Le client cite une référence stable au téléphone, le CRM ouvre le même historique et la facture reprend la version engagée. Cette continuité réduit les rapprochements manuels et empêche qu’une pièce jointe isolée devienne une seconde source de vérité.
Modéliser versions et états
Créer une version immuable
Identité du devis, numéro de version, lignes, conditions, pièces et calculs forment un snapshot. Une modification crée une version suivante. L’ancienne reste lisible et ne reçoit plus d’écriture.
L’empreinte lie données structurées et rendu. Un PDF est une représentation, pas la source de vérité. L’audit peut prouver que le fichier correspond à la version acceptée.
Fermer la machine d’états
Brouillon, envoyé, vu, commenté, à valider, accepté, refusé, expiré et converti possèdent des transitions autorisées. Un événement porte acteur, heure et version. Les statuts ne changent pas par correction directe.
Une nouvelle version peut rendre la précédente remplacée sans effacer son historique. L’acceptation vise un identifiant précis. Deux versions ne restent pas simultanément acceptables sans règle.
Le stockage associe un identifiant de dossier durable à des snapshots immuables. Une table de transitions référence from, to, acteur, policy et idempotency key ; une outbox diffuse les changements vers notifications et CRM. Les projections se reconstruisent depuis les événements, tandis que le PDF est régénéré et comparé par empreinte.
Attribuer rôles et droits
Distinguer préparation et engagement
Commercial, expert, finance, approbateur et signataire n’ont pas les mêmes pouvoirs. L’auteur prépare ; un autre rôle peut valider marge ou conditions. Le droit dépend du montant, du compte et de la catégorie.
La policy vérifie le rôle à chaque transition. Une délégation expirée empêche l’acceptation. Les comptes techniques disposent de scopes limités aux imports ou calculs.
Limiter l’accès aux informations
Coût interne, marge, remise maximale et notes privées ne sont pas visibles de l’acheteur. Les commentaires publics restent séparés. Un export respecte la même projection.
Les accès sensibles sont audités. Support peut consulter l’historique sans modifier. Une élévation temporaire exige motif et expiration.
Les permissions sont évaluées côté serveur à la lecture, à l’export et à la transition. Une invitation révoquée ne conserve pas un ancien lien vers le devis. Le journal de sécurité suit consultation des coûts, téléchargement de pièces et élévation temporaire. Une revue trimestrielle retire les rôles sans activité ou sans manager responsable.
Qualifier la demande
Collecter des entrées complètes
Besoin, quantités, lieu, calendrier, contraintes, budget et pièces alimentent la proposition. Les champs dépendent de la verticale. Une information inconnue reste déclarée, elle n’est pas remplacée par zéro.
Le questionnaire distingue requis et complémentaire. L’acheteur peut sauvegarder, inviter un collègue et joindre des éléments. Le vendeur voit la confiance et la date des données.
Fermer les hypothèses
Chaque hypothèse relie une entrée manquante à une conséquence sur prix, délai ou périmètre. Le vendeur précise sa condition de validation. Le client comprend ce qui pourrait changer.
Si la donnée devient disponible, alors une nouvelle version calcule l’écart. Les hypothèses résolues sont marquées, pas simplement supprimées. Le support retrouve la raison d’une variation.
Par exemple, un chantier exige accès au site, puissance électrique et fenêtre d’intervention. Si l’acheteur ne confirme pas la puissance, alors le vendeur peut proposer une estimation avec fourchette mais pas une offre ferme. La sortie indique l’hypothèse bloquante, son owner et la date au-delà de laquelle le créneau sera libéré.
Construire prix et périmètre
Structurer les lignes
Produit, service, quantité, unité, prix, remise, taxe et période composent une ligne. Livraison, option et frais restent nommés. Un total global sans base ne permet ni comparaison ni correction.
Les dépendances de ligne précisent inclusion et exclusivité. Un bundle garde sa composition. Les arrondis s’appliquent selon une règle testée et versionnée.
Versionner le moteur de prix
Le calcul reçoit compte, catalogue, quantités, date, devise et règles ; il retourne lignes et explications. La version du moteur et les données tarifaires sont conservées. Un recalcul historique reproduit le résultat.
Les overrides possèdent motif, approbateur et plafond. Une remise manuelle ne se cache pas dans un prix unitaire. Le monitoring détecte marges et écarts anormaux.
Le moteur produit aussi une trace explicative : tarif choisi, règle de remise, taux de taxe, arrondi et override. Une suite de fixtures couvre devises, paliers et dates frontières. À chaque déploiement, les snapshots de référence sont recalculés en simulation ; toute différence non approuvée bloque la nouvelle version avant exposition.
Collaborer sans perdre la preuve
Rattacher les commentaires
Un commentaire vise version, ligne, condition ou document. Il possède auteur, visibilité et état résolu. Une conversation générale ne remplace pas la modification structurée du devis.
Les mentions et notifications sont idempotentes. Un utilisateur rejoint le fil avec les droits du compte. Les pièces jointes portent empreinte et contrôle.
Transformer une décision en changement
Résoudre un commentaire indique réponse et éventuelle modification. Si le prix ou le périmètre change, une nouvelle version est générée. Le fil reste attaché à l’ancienne question.
Le diff montre lignes, montants, dates et conditions. L’acheteur ne relit pas aveuglément cent pages. Les changements importants exigent un nouvel accord explicite.
Les notifications ne contiennent pas de copie indépendante du prix qui pourrait survivre à une correction. Elles citent le numéro de version et ouvrent la vue autorisée. Le monitoring détecte messages en échec, pièces non analysées et commentaires sans réponse depuis le SLA. Un replay utilise la même clé et ne double pas les invitations.
Valider selon le risque
Construire une matrice d’approbation
Montant, marge, remise, conditions et engagement de délai déterminent les approbateurs. La matrice est versionnée. Un devis standard n’attend pas le comité d’un dossier exceptionnel.
Chaque approbation vise un snapshot. Une modification matérielle l’annule. Le système évite qu’un accord ancien couvre une version plus risquée.
Séparer validation interne et acceptation
Le vendeur valide qu’il peut tenir l’offre ; l’acheteur accepte les conditions. Les deux événements ont rôles et preuves distincts. Une validation interne n’est jamais présentée comme une signature client.
Les méthodes d’acceptation suivent le contrat : bouton authentifié, signature ou bon de commande. La plateforme conserve l’identité et le document source.
La policy retourne liste d’approbateurs, séquence, seuil et justification à partir des entrées du snapshot. Sa version est conservée avec chaque verdict. Si une remise passe de 8 à 12 %, alors l’approbation précédente est invalidée et finance reçoit un nouveau dossier ; les validations des clauses inchangées peuvent être réutilisées selon une règle explicite.
Gérer validité et dépendances
Fixer une durée cohérente
Prix, stock, change, capacité et planning ont des horizons différents. La validité du devis prend le plus contraignant ou indique des conditions séparées. Le vendeur ne promet pas une ressource indéfiniment.
Les rappels précèdent l’échéance sans prolongation automatique. Un renouvellement crée une version recalculée. Le client voit ce qui change.
Réagir à un événement critique
Retrait produit, taxe, sanction vendeur ou incapacité peut invalider une offre avant son terme selon les conditions. L’événement suspend la conversion et ouvre une revue.
Par exemple, si une pièce devient indisponible, alors le vendeur propose un substitut dans une nouvelle version. L’ancienne reste visible mais non convertible. Le client choisit en connaissance.
Une tâche planifiée marque les versions expirées et publie un événement. Le panier, les liens partagés et l’API vérifient cet état au lieu de se fier à la date affichée. La réouverture crée une nouvelle version avec tarifs, capacité et dates recalculés ; elle ne change jamais l’horodatage de l’offre historique.
Négocier par alternatives
Proposer des scénarios comparables
Quantité, délai, niveau de service ou matériel peuvent former des alternatives. Chaque scénario garde total et conditions. Les différences sont visibles côte à côte.
Une option n’est pas une remise cachée. Le vendeur explique le compromis. L’acheteur sélectionne une variante avant validation finale.
Borner les contre-propositions
L’acheteur peut demander prix, quantité ou date, mais ne modifie pas directement la proposition du vendeur. Sa contre-proposition devient une demande versionnée. Le vendeur accepte ou répond.
Le nombre de cycles et leur durée sont mesurés. Une négociation bloquée reçoit un owner. Les concessions restent dans le dossier.
Le compromis entre liberté et comparabilité est assumé. Trop d’alternatives ralentissent la validation et masquent le choix ; une seule option force des échanges hors plateforme. L’opérateur limite à trois scénarios structurés, mesure le taux de sélection et transforme les demandes récurrentes en paramètres plutôt qu’en commentaires libres.
Convertir sans recalcul caché
Créer depuis la version acceptée
La conversion prend l’identifiant accepté, copie lignes et conditions, puis lie commande et devis. Elle ne relit pas le tarif courant. Une clé idempotente évite deux commandes.
Les préconditions encore nécessaires sont vérifiées. Si un élément a expiré, alors la conversion s’arrête et propose une révision. Elle ne remplace pas silencieusement la ligne.
Préserver les jalons suivants
Acompte, approbation acheteur, livraison et facturation dérivent des conditions acceptées. Les échéances sont structurées. Le PDF reste consultable avec la commande.
Scénario : deux utilisateurs convertissent simultanément. Si la première transaction crée la commande, alors la seconde retrouve son identifiant. Aucun stock ou paiement n’est doublé.
L’implémentation crée commande et lien de provenance dans une transaction, puis publie l’outbox. Les entrées sont quote_id, version_id, identité de l’acceptant et clé idempotente ; les sorties sont commande, lignes copiées et journal. Toute dépendance externe intervient ensuite avec retry, sans remettre en cause l’unicité de la conversion.
Monitorer et rapprocher
Suivre le cycle commercial
Temps de première réponse, versions, commentaires, validation, acceptation et conversion sont segmentés. Une conversion faible peut venir d’un délai, d’un prix ou d’un besoin mal qualifié. Les métriques gardent ces causes.
La marge et les reprises sont rapprochées après commande. Un devis vite accepté mais souvent corrigé n’est pas performant. Le seller manager voit les écarts actionnables.
Répondre aux incidents
Le monitoring suit total incohérent, version orpheline, approbation périmée et conversion dupliquée. Chaque alerte possède owner, seuil et runbook. Le rollback retire une version de moteur sans modifier les devis passés.
Une réconciliation compare devis acceptés et commandes. Les écarts rejoignent une file avec montant et ancienneté. La correction produit un événement auditée.
Scénario : un correctif tarifaire produit des totaux différents sur 37 devis envoyés. Si l’écart dépasse un euro ou modifie la marge sous le seuil, alors le run suspend leur conversion, simule les versions corrigées et attribue chaque dossier. Le rollback restaure le moteur pour les nouveaux calculs sans réécrire les snapshots déjà transmis.
Adapter la méthode et éviter les erreurs
Pour qui ce workflow de devis convient
Il convient aux achats B2B, services configurés, quantités négociées ou interventions. Un prix fixe peut utiliser une commande directe, mais garde un snapshot si les conditions varient.
Produit porte les états ; commercial les propositions ; finance le calcul ; juridique l’acceptation ; plateforme les versions ; support l’audit. Chaque owner valide sa sortie.
Le premier périmètre doit concentrer assez de répétition pour justifier le workflow. Dix dossiers totalement uniques réclament peut-être un outil documentaire ; cent devis partageant lignes, validations et conditions bénéficient d’un modèle. Cette décision évite de forcer des exceptions permanentes dans une machine d’états censée rendre l’engagement prévisible.
Erreurs fréquentes dans un workflow de devis
Écraser la version, commenter hors contexte, recalculer à la conversion, prolonger sans accord et confondre validation interne et signature sont les erreurs majeures. Elles détruisent la preuve.
Une autre erreur consiste à mettre toute la logique dans le PDF. Les données structurées doivent porter le workflow ; le document en fournit une représentation opposable.
Plan d’action pour construire le workflow de devis
Semaines 1 à 4 : modèle et calcul
La première semaine analyse vingt dossiers et identifie entrées, versions, décisions et litiges. La deuxième ferme machine d’états, lignes, hypothèses, rôles et validité. Chaque transition possède preuve et owner.
Les semaines trois et quatre branchent moteur de prix, snapshot, rendu et diff. Finance teste taxe, devise et arrondi ; commercial teste alternatives ; sécurité vérifie projections et délégations.
Semaines 5 à 8 : acceptation et conversion
La cinquième semaine ouvre commentaires et approbations. La sixième implémente acceptation et conversion idempotente. L’instrumentation relie chaque événement au même dossier.
Les semaines sept et huit rejouent expiration, modification concurrente, approbation annulée et double conversion. Le go exige commande identique à la version acceptée, audit complet et réconciliation verte.
Le comité vérifie les contournements par email et tableur. Les écarts deviennent des besoins ou des règles, pas des procédures cachées. Chaque nouvelle verticale doit déclarer ses lignes et conditions.
Le dossier de go contient le schéma versionné, les transitions autorisées, la matrice d’approbation et les résultats de vingt scénarios. Commercial doit retrouver le diff sans tableur ; finance doit reproduire le total à partir des entrées ; support doit expliquer une acceptation ; l’équipe plateforme doit rejouer une notification et un événement sans double effet. Si une preuve manque, la cohorte reste bornée à des montants et vendeurs explicitement autorisés.
- À faire d’abord : fermer version, état et périmètre accepté.
- À tester ensuite : expiration, commentaire, changement et double conversion.
- À différer : les scénarios dont le calcul reste manuel et opaque.
- À refuser : toute commande recalculée après acceptation.
Guides complémentaires pour l’opérateur
Structurer offre et validation
Le catalogue PIM marketplace fournit produits, attributs et identités.
Les écrans du back-office opérateur structurent versions, approbations et dossiers.
Borner la première cohorte
Le MVP marketplace avant ouverture aide à limiter les variantes nécessaires.
La méthode pour ouvrir une première catégorie permet d’éprouver les devis sur des demandes réelles.
Conclusion : engager une version claire
Un devis marketplace fiable engage une version complète, calculée et identifiable, plutôt qu’un fichier mouvant.
Commentaires, approbations et négociations restent attachés à leur contexte. Chaque modification produit un diff et un nouvel accord.
La commande reprend la version acceptée sans recalcul caché. L’audit et la réconciliation rendent le cycle défendable.
Pour concevoir ce workflow de devis, Dawap peut vous accompagner dans votre marketplace opérateur.
