Choisir des états sans ambiguïté
Distinguez le brouillon, le devis envoyé, la réponse reçue, l’acceptation et le refus. Un devis en préparation ne doit pas déclencher une relance client. Définissez qui peut corriger les statuts et ce qui constitue une réponse. Conservez la version effectivement envoyée pour ne pas rappeler des conditions qui ont changé depuis.
Arrêter le parcours au bon moment
Avant chaque envoi, vérifiez la dernière réponse, le refus éventuel et les restrictions de contact. Un rappel programmé doit être annulé si le dossier évolue. Une opposition bloque les nouveaux messages concernés. Les délais et le nombre de rappels sont fixés avec l’entreprise ; ils ne sont pas choisis librement par le modèle IA.
Éviter un second envoi après une panne
Attribuez un identifiant au rappel et gardez son état. Si le fournisseur ne confirme pas la transmission, classez le résultat à vérifier plutôt que d’envoyer à nouveau immédiatement. Testez une réponse reçue juste avant l’échéance et un clic répété sur la validation. L’historique doit permettre de comprendre pourquoi un rappel a été envoyé ou annulé.
Recette : une réponse reçue entre préparation et envoi
Préparez une relance fictive, puis enregistrez une réponse du client avant l’étape de transmission. Le nouvel état doit arrêter le message préparé. Rejouez ensuite la même tâche pour simuler une reprise après panne : aucun second envoi ne doit partir. Si le fournisseur n’a pas confirmé son résultat, affichez un état à vérifier et rapprochez les événements avant de décider d’un nouvel essai.
À préparer pour votre projet
- Statuts fiables des devis
- Accès aux réponses
- Délais de relance approuvés
Le périmètre à confirmer
Le fournisseur peut confirmer une transmission sans confirmer la lecture. Les messages doivent afficher leur état réel.
Le devis précise les outils, les accès, le calendrier et les éventuels coûts de licences ou de consommation. Aucun gain chiffré n’est annoncé sans mesure.