Recueillir les demandes hors horaires sans promettre une réponse immédiate

Un client écrit alors que l’atelier a déjà fermé. Le lendemain, l’accueil retrouve son message parmi d’autres conversations. Le téléphone peut manquer, la demande être peu claire ou une réponse avoir été donnée par un autre canal. Je commencerais par cette continuité avant de proposer un assistant qui tenterait de tout résoudre.

Recueillir une demande hors horaires peut être utile. Cela ne revient pas à réparer une voiture, confirmer un devis ou disposer d’une personne qui résout les incidents la nuit. Le message initial doit expliquer ce que le système peut faire et quand la demande sera examinée, selon les horaires réels de l’entreprise.

Une demande de rendez-vous, du début à la fin

Dans ce scénario hypothétique, le client demande un rendez-vous de révision. Le système recueille le motif avec ses mots, un contact et sa préférence horaire. J’éviterais de demander des documents ou des données inutiles à la préparation du rendez-vous.

S’il reconnaît une demande courante, il peut afficher les conditions approuvées par l’atelier. Si le client décrit une panne ou demande s’il peut continuer à conduire, la réponse est confiée à une personne : l’assistant ne pose pas de diagnostic et ne décide pas si le véhicule peut être utilisé en sécurité.

La demande reçoit un identifiant et l’état « en attente de vérification ». Cet état diffère de « rendez-vous confirmé ». Proposer un créneau exige de vérifier disponibilité et durée ; réserver un pont élévateur exige de connaître l’intervention. Un rendez-vous d’accueil ne doit pas devenir automatiquement une réservation de ressources de l’atelier.

Je commencerais sans réservation directe. Après confirmation par l’accueil, le système envoie la date et les conditions convenues. Si la réservation est autorisée ensuite, je testerais également deux demandes simultanées pour le même créneau et le comportement en cas d’absence de réponse de l’agenda.

Le relais dont une personne a besoin

L’avis interne comprendrait le motif, les données indispensables, les actions réalisées et ce qui reste à confirmer. Je définirais qui examine la file à l’ouverture et comment elle est réattribuée en cas d’absence. Un avis sans responsable peut rester aussi longtemps en attente que le message initial.

Le client devrait disposer d’un moyen visible de demander une prise en charge humaine. WhatsApp prévoit des voies de transfert claires et directes lorsque les réponses sont automatisées. Sa politique encadre aussi l’autorisation de contact et les modèles de WhatsApp Business Platform : mieux vaut ne pas prévoir le suivi comme si tout message pouvait être envoyé à tout moment.

Je n’ajouterais pas une campagne de réactivation au même pilote. Préparer un rendez-vous demandé et écrire des mois plus tard pour vendre un autre service sont des décisions différentes, dont les conditions doivent être examinées séparément.

Quand le système s’arrête à mi-chemin

Si la demande est enregistrée, mais que l’avis interne échoue, elle doit rester en attente et visible. Si une personne l’a déjà traitée par téléphone, elle doit pouvoir la marquer comme résolue pour éviter un nouveau suivi. Les répétitions sont rattachées à la demande existante plutôt que d’en ouvrir une autre sans vérification.

n8n propose la gestion des erreurs et la consultation des exécutions échouées. Je vérifierais néanmoins une liste de demandes en attente : une exécution peut se terminer sans erreur technique et laisser une demande mal classée.

Pendant un essai limité, je mesurerais les demandes complètes, les doublons, les transferts corrects et le délai avant l’examen humain. Je compterais aussi les minutes de correction. Le nombre de réponses automatiques ne dit pas si le client a obtenu une solution. La première amélioration serait de pouvoir retrouver chaque demande et savoir qui doit la poursuivre.