docs/40-relation/30-sav.md —
ce document se lit aussi dans le dépôt, sans serveur.
SAV et contacts client
Où : Gestion → SAV pour la file d'attente — et l'icône de la barre du haut, qui en porte le compteur. Et sur la fiche d'une commande, pour lire l'historique et répondre.
À quoi ça sert
Un client a un problème. Il le dit. Quelqu'un doit le voir, y répondre, et que ça reste écrit.
La page SAV est une file d'attente : ce qui est arrivé et qui n'a pas encore été traité. Elle se vide quand on traite.
D'où les demandes arrivent
Le formulaire public de la boutique
Le client va sur monsieurcle.fr/support/, donne son numéro de commande et son adresse e-mail, et si les deux concordent, il peut écrire — et joindre des fichiers.
Ce formulaire n'est pas dans le dépôt Darsy. Il vit sur WordPress. Le dossier public/support/ de Darsy n'est pas ce que les clients utilisent. Un développeur qui juge le comportement réel d'après ce qu'il lit dans le dépôt se trompera — voir le côté technique.
Le guichet de suivi du mini-site
sav.monsieurcle.fr/suivi/ sert le meme parcours en deux temps, avec l'en-tete et la navigation du mini-site d'aide.
Il ne remplace pas encore le formulaire WordPress, et il ne peut pas : celui de WordPress recoit des fichiers, celui-ci non. Un client qui signale une cle qui n'ouvre pas envoie une photo. Tant que le guichet ne sait pas les recevoir, rediriger /support retirerait cette possibilite.
Depuis l'ERP
Sur une fiche de commande, un opérateur écrit au client : réponse à un SAV, demande d'information, message libre.
Les quatre types
| Type | Qui l'écrit | Ce que c'est |
|---|---|---|
sav_opened | Le client | Une demande de SAV, ou une annulation |
information_request | L'opérateur | On demande quelque chose au client |
sav_reply | L'opérateur | Une réponse à une demande précise |
generic | L'opérateur | Tout le reste |
Ce qu'on peut y faire
Lire la file
Filtrer par type, chercher dans l'adresse, le message ou le numéro de commande.
Le compteur de la barre du haut décrit exactement le même ensemble que la page — sinon le badge dirait 7 et la liste en montrerait 4.
Répondre
Depuis la fiche de la commande. On écrit, on joint des pièces si besoin, on envoie.
Une réponse doit pointer la demande d'origine, et cette demande doit appartenir à la même commande. Sans ce rattachement, une réponse pourrait se coller sous la demande d'un autre client.
Changer le statut de la commande en même temps
On répond « votre clé est prête » et on passe la commande en conséquence, dans le même geste.
Clôturer
Une demande traitée quitte la file. Quel que soit son type.
Ce que ça touche ailleurs
| Ce qu'on fait | Ce que ça change |
|---|---|
| Répondre à un client | Un e-mail part. Une note est écrite sur la commande, toujours, même si l'e-mail échoue. |
| Appliquer un statut | La commande change de statut dans WooCommerce, avec tout ce que ça déclenche |
| Clôturer | La demande sort de la file et du compteur |
| N'importe quelle action | Une ligne dans le journal d'audit |
L'e-mail peut échouer, la trace jamais
Trois états : sent, failed, not_sent. Le message est écrit en base avant la tentative d'envoi.
Un e-mail perdu ne doit jamais effacer le fait qu'on a répondu.
Le statut passe par WooCommerce, jamais par SQL
Voir les règles des commandes.
Les règles
La file ne montre que ce qui vient du client
Un message qu'on a envoyé n'est pas une demande en attente. Proposer d'y répondre, ce serait se répondre à soi-même.
La direction est déjà enregistrée : toute action faite depuis l'ERP marque l'opérateur, le formulaire public ne marque personne. C'est ça le critère, pas le type du message.
Une demande close est close, quel que soit son type
Une version antérieure ne clôturait que les sav_opened. Les demandes d'information auxquelles on avait répondu restaient dans la file et dans le compteur indéfiniment.
Les demandes importées de l'ancien outil n'apparaissent jamais
Elles avaient été traitées avant l'import. Elles sont écartées de la liste comme des compteurs.