Le développement d’un portail de validation de devis commence par une question simple : quel document le client accepte-t-il exactement ? Un bouton de validation ne suffit pas lorsque les quantités, les options ou les délais peuvent évoluer. Le système doit relier la décision à un contenu identifiable, puis expliquer les conséquences d’une modification ultérieure.
Imaginons un atelier fictif qui prépare des équipements sur commande. Le client reçoit un devis, demande une autre finition et délègue la validation à une collègue. L’atelier doit savoir quelle version lancer en fabrication. Le portail doit donc représenter le parcours de décision, et pas seulement remplacer une pièce jointe par une page web.
Décrire les décisions et leurs responsables
Distinguez la consultation du devis, la demande de changement et son acceptation. Ces actions peuvent appartenir à des personnes différentes. Précisez si une validation concerne toute l’entreprise cliente ou seulement un établissement. Un intitulé de rôle trop général laisse souvent des interprétations contradictoires entre la vente et la production.
Décrivez aussi les absences et les délégations. Une personne autorisée peut-elle transférer la décision à une collègue ? Le responsable commercial peut-il modifier le contenu pendant cette période ? Ces règles doivent être visibles dans le périmètre du projet et démontrables avec des comptes de test distincts, sans utiliser les données de vrais clients.
Donner une identité au contenu proposé
Chaque version doit permettre de retrouver les lignes, options et conditions présentées au client. Gardez un lien clair entre la vue du portail et le document exporté. Un numéro de devis inchangé ne suffit pas si plusieurs contenus différents circulent sous cette référence et que personne ne sait lequel a été retenu.
Définissez ce qui déclenche une nouvelle version. Une correction de commentaire interne n’a pas nécessairement le même effet qu’un changement de quantité. L’équipe métier doit décider quelles modifications exigent une nouvelle validation. Le développement traduit ensuite cette règle dans le parcours, au lieu de laisser une convention implicite déterminer une décision commerciale.
Prévoir les états incomplets et les retours
Le client doit pouvoir distinguer une demande envoyée, une modification en préparation et un devis effectivement validé. Une notification reçue ne constitue pas, à elle seule, une preuve que la bonne personne a terminé l’action attendue. L’état du dossier doit rester consultable indépendamment du message qui l’annonce.
Si le client refuse une version ou revient après son expiration, proposez une prochaine étape compréhensible. Préservez les échanges utiles à la reprise du dossier. Les éventuelles exigences de signature ou de portée contractuelle doivent être traitées avec les responsables compétents ; elles ne découlent pas automatiquement du fait d’avoir ajouté un bouton dans une application.
Tester une modification après ouverture du devis
Ouvrez une première version avec un utilisateur client, puis modifiez une quantité depuis le compte de l’atelier. Essayez ensuite de valider l’ancienne page encore ouverte. Vérifiez le résultat dans le portail, le document exporté et l’historique. La production doit pouvoir retrouver le contenu effectivement accepté sans interpréter une succession d’e-mails.
Pour préparer un projet avec Brainbaby Labs, apportez un exemple anonymisé de devis et un cas où son contenu a changé. Cette situation permet de définir les versions, les droits et les notifications nécessaires. Le premier livrable peut alors être accepté sur un parcours complet, de la proposition initiale à une décision exploitable par votre équipe.