Traiter les réclamations des résidents : le processus en 5 étapes dont tout gestionnaire de copropriété a besoin

Si vous traitez des réclamations toute la journée et que vous n’avez jamais mis votre méthode par écrit, vous en avez une quand même. Elle vit simplement dans votre tête et change un peu chaque mardi. Cet article décrit le processus en 5 étapes vers lequel finit par converger tout cabinet de syndic, et pointe les quatre endroits où la plupart des gestionnaires perdent de l’information.

Étape 1 : Recueillir

La réclamation est signalée. C’est là que naissent 80 % des problèmes, parce que la façon dont elle est recueillie conditionne toute la suite.

Mauvais recueil : « L’ascenseur est en panne. » Posté dans le groupe WhatsApp de l’immeuble à 23 h.

Qu’est-ce qui manque ? Quel ascenseur, s’il y en a plusieurs. À quel étage il est bloqué. S’il y a quelqu’un dedans. S’il est en panne depuis une heure ou depuis trois jours. Si le résident a déjà tenté quelque chose.

Bon recueil : un formulaire structuré avec un titre, une description, une catégorie facultative et une photo facultative. Même quand les résidents le remplissent à la va-vite, vous obtenez plus d’informations utiles qu’avec un message WhatsApp, parce que la structure les oblige à répondre aux questions de base.

Le plus gros gain, quand on quitte le groupe WhatsApp, c’est d’imposer le format du signalement. Les résidents donnent de meilleures informations quand le formulaire les leur demande que quand ils écrivent au fil de la plume.

Défaillance fréquente : recueillir les réclamations par téléphone. L’information reste dans la tête du gestionnaire, elle est retranscrite de façon approximative (ou pas du tout), et elle n’apparaît dans aucun système. Le jour où le gestionnaire oublie d’agir, il n’en reste aucune trace.

Étape 2 : Trier

La réclamation existe. Quelqu’un doit maintenant décider qui s’en charge.

Dans une petite structure, c’est le gestionnaire qui le fait à la main. Dès que vous dépassez trois immeubles, on l’automatise par catégorie :

• Plomberie → le plombier habituel
• Électricité → l’électricien habituel
• Nuisibles → l’entreprise de désinsectisation et de dératisation
• Parties communes / sécurité incendie / « autre » → le gestionnaire

Si la réclamation n’a pas de catégorie, elle va par défaut au gestionnaire. Si elle a une catégorie mais que personne n’est inscrit pour celle-ci, elle va aussi au gestionnaire, et ce trou vous signale qu’il vous manque un technicien pour cette spécialité.

Vous pouvez envoyer toutes les réclamations au gestionnaire, quel que soit leur type, et beaucoup d’équipes fonctionnent ainsi. Mais c’est l’option la moins efficace : le gestionnaire devient un standard téléphonique, et le standard devient le goulot d’étranglement. Aiguiller par catégorie, avec un gestionnaire qui supervise au lieu de gérer chaque transmission, est le changement le plus rentable de tout le processus.

Étape 3 : Accuser réception

La personne qui s’en charge (gestionnaire ou technicien) reçoit l’incident et en accuse réception. Dans un système de tickets, cela veut dire faire passer le statut de Nouveau à En cours. Le résident voit le statut changer et sait que quelqu’un s’en occupe. Il n’a pas besoin de demander.

Cette étape supprime toute la boucle du « du nouveau ? ». Environ 30 % des échanges d’un processus fondé sur WhatsApp sont des résidents qui demandent où en est leur problème, faute d’autre moyen de le savoir. Rendez le statut visible, et ces messages disparaissent.

Défaillance fréquente : accuser réception dans sa tête, mais pas dans le système. La personne qui s’en charge connaît l’incident, mais le résident ne sait pas qu’elle le connaît. Il suppose que rien ne bouge et le signale à nouveau, souvent sur un ton plus vif.

Étape 4 : Résoudre

Le travail est fait. Le plombier a réparé la fuite. L’électricien a remplacé le disjoncteur. L’entreprise de nettoyage a dégagé le couloir.

Dans le système de tickets, la personne qui s’en charge marque l’incident comme résolu (ou « En attente de confirmation » : même chose, autre nom). L’incident repart alors vers le résident pour confirmation. La personne qui s’en charge ne clôture pas l’incident. C’est le résident qui le clôture, en confirmant la réparation. Le gestionnaire peut toutefois le résoudre directement si le résident ne répond jamais.

C’est un choix de conception délibéré. Il évite le cas où un technicien répare à moitié et clôture l’incident, puis où le résident revient se plaindre deux jours plus tard, et où commence la dispute sur ce qui a réellement été fait.

Défaillance fréquente : la personne qui s’en charge clôture l’incident elle-même, le résident n’est jamais prévenu, et il signale le même problème deux semaines plus tard parce que la réparation n’a pas tenu.

Étape 5 : Confirmer ou rouvrir

Le résident reçoit une notification. Deux boutons : Confirmer la réparation, ou Rouvrir en indiquant un motif.

• S’il confirme, l’incident est clôturé. Terminé. Personne n’a plus rien à faire.
• S’il rouvre, l’incident revient à Nouveau avec le motif du résident. La personne qui s’en charge le retrouve avec tout le contexte.

Le motif de réouverture est obligatoire. Cela évite le « toujours en panne » paresseux, sans aucune information, qui impose un nouvel aller-retour.

Défaillance fréquente : l’étape de confirmation n’existe pas. La personne qui s’en charge clôture, et on ne demande jamais rien au résident. Le technicien croit le problème réglé, le résident vit toujours avec. Cela ressort plus tard sous la forme d’une plainte en assemblée générale ou, pire, d’une assemblée générale qui vote le changement de syndic.

Où l’information se perd (et pourquoi)

Sur les cinq étapes, voici les quatre endroits où l’information disparaît le plus souvent :

1. Entre l’étape 1 et l’étape 2, quand le recueil n’est pas structuré. Ce qui n’a pas été écrit dans le message n’est jamais récupéré. Solution : un formulaire de signalement structuré.

2. Entre l’étape 2 et l’étape 3, quand le tri est manuel. Le gestionnaire connaît l’incident mais met 6 heures à le transmettre au bon technicien. Le délai de réponse du technicien s’allonge, parce que le chronomètre a démarré bien avant qu’il soit prévenu. Solution : un aiguillage automatique par catégorie.

3. Entre l’étape 3 et l’étape 4, quand le statut n’est pas visible. Les résidents demandent des nouvelles parce qu’ils ne peuvent pas les voir. Le gestionnaire réexplique trois fois. Solution : un statut partagé.

4. Entre l’étape 4 et l’étape 5, quand on saute la confirmation. La personne qui s’en charge clôture, le résident ne confirme jamais. L’incident paraît résolu, mais ne l’est pas. Solution : une étape de confirmation entre les mains du résident.

Colmatez ces quatre fuites, et votre processus ira environ 3 fois plus vite avec la même équipe.

Les délais, les pieds sur terre

Rapporté au temps réel d’une réclamation réelle, un cycle sain ressemble à ceci :

• Étape 1 (Recueillir) : le résident signale en 30 secondes.
• Étape 2 (Trier) : le système aiguille en moins d’une seconde.
• Étape 3 (Accuser réception) : la personne qui s’en charge répond en général dans les 4 heures, les jours ouvrés.
• Étape 4 (Résoudre) : très variable. Quelques minutes pour une porte de hall qui ne ferme plus, plusieurs jours s’il faut commander une pièce d’ascenseur.
• Étape 5 (Confirmer) : le résident confirme dans les 24 heures qui suivent la demande.

De bout en bout, un incident courant est clôturé en 1 à 3 jours ouvrés. Les réclamations qui traînent 3 semaines ne traînent pas parce que le travail est difficile, mais parce que les étapes 2, 3 ou 5 manquent complètement.

Si votre délai moyen de résolution dépasse une semaine et que vos techniciens ne sont pas le goulot d’étranglement, c’est le processus qui l’est. Réparez d’abord le processus.