À quoi ressemble un système de tickets structuré pour les gestionnaires de copropriété

Un ticket est une fiche toute simple. C’est aussi la brique de base la plus importante du travail opérationnel moderne, du service client d’une compagnie aérienne à la gestion des incidents d’un hôpital, en passant par l’entretien d’un immeuble.

Cet article explique ce qu’est un ticket (en copropriété, un incident), ce qui rend utile le système qui l’entoure, et ce qui change quand vous gérez vos immeubles avec un tel système.

Un ticket n’est qu’une fiche avec quatre propriétés

Retirez le jargon, et un ticket est une tâche à laquelle sont attachées quatre informations :

1. Un identifiant, en général un numéro comme #0042. Pour pouvoir en parler sans ambiguïté.
2. Un statut, l’étape où il se trouve dans le processus. Nouveau, En cours, En attente de confirmation, Clôturé.
3. Un responsable, la personne chargée à cet instant de le faire avancer.
4. Un historique, chaque modification apportée par quiconque, avec la date et l’heure.

C’est tout. Le reste (catégories, priorités, pièces jointes, commentaires) est un complément facultatif. Ces quatre propriétés transforment une réclamation en tâche suivie, au lieu d’un message oublié.

Comparez avec un message WhatsApp. Un message a un contenu. Point. Il n’a pas d’identifiant (à part sa place dans le fil), pas de statut, pas de responsable, pas d’historique. C’est pour cela qu’on ne peut pas faire tourner un processus dessus.

Pourquoi chacune des quatre propriétés compte

L’identifiant

Quand deux personnes parlent d’un incident, elles doivent savoir qu’elles parlent du même. Dans un groupe WhatsApp, on s’en sort en citant : « le souci d’ascenseur d’hier » ou « la fuite au 4e gauche, celle dont le plombier a dit que c’était le joint ». Dès que vous avez plus de cinq incidents ouverts en même temps, cela devient ambigu.

Un numéro d’incident (#0042, #0089) règle la question pour de bon. Un résident, un gestionnaire ou un technicien peut désigner un incident par son numéro sans la moindre ambiguïté. Cela paraît anodin. Cela supprime environ 15 % de la confusion dans un processus de gestion classique.

Le statut

Le statut transforme une conversation libre en machine à états :

Le résident n’a pas besoin de demander « du nouveau ? ». Il voit le statut. Le gestionnaire n’a pas besoin de se rappeler quels incidents sont bloqués en attendant le plombier. Il filtre par statut. Et le dirigeant du cabinet n’a pas besoin de lire 200 messages pour savoir combien d’incidents sont ouverts ce mois-ci. Il les compte.

C’est aussi dans le statut que vit l’automatisation. Quand le statut change, il se passe des choses : des notifications partent, les résidents sont prévenus, les techniciens sont désignés. C’est impossible dans un groupe de discussion, parce qu’une discussion ignore tout de la notion d’état.

Le responsable

À chaque instant de sa vie, chaque incident a exactement une personne chargée de le faire avancer. Quand le résident le signale, le responsable est le gestionnaire de l’immeuble (ou le technicien vers qui il a été transmis). Quand le gestionnaire l’attribue à un technicien, le technicien devient responsable. Quand le technicien le déclare terminé, le responsable devient le résident, qui doit confirmer la réparation ou rouvrir l’incident.

C’est la fonctionnalité qui met fin au « quelqu’un d’autre va s’en occuper » typique d’un groupe WhatsApp, où tout le monde voit l’incident et où personne ne le traite.

L’historique

Un journal complet de chaque changement de statut, de chaque attribution, de chaque commentaire. Indispensable pour trois raisons :

1. Rendre des comptes. Quand vient la saison des assemblées générales, vous pouvez présenter une chronologie précise du traitement de chaque incident.
2. Repérer les tendances. Au bout de six mois, vous découvrirez que 40 % de vos incidents de plomberie viennent du même immeuble : le signe qu’il faudra proposer en assemblée générale le remplacement des canalisations.
3. Intégrer les nouveaux. Quand un gestionnaire arrive au cabinet, il peut remonter l’historique de n’importe quel immeuble et comprendre ce qui s’y passe.

Ce qu’apporte « le système autour des tickets »

Un ticket seul est une fiche. Un système de tickets ajoute le processus autour :

• L’aiguillage. Quand un incident est créé, à qui va-t-il ? La plupart des systèmes utilisent des règles : « catégorie = plomberie → attribuer au plombier X ». Le gestionnaire n’a pas à décider.
• Les notifications. Quand le statut change, qui est prévenu ? Le responsable, la personne qui a signalé l’incident, parfois quelqu’un qui le suit.
• Les filtres. « Afficher tous les incidents Nouveaux du 12 rue des Lilas, attribués à personne, ouverts depuis plus de 24 heures. » Deux clics.
• Les actions groupées. « Clôturer les 30 incidents En attente de confirmation depuis plus de deux semaines. » Une seule action.

Rien de tout cela n’existe dans un processus fondé sur WhatsApp. Impossible de « filtrer tous les incidents ouverts de quatre immeubles » dans WhatsApp, parce que rien dans WhatsApp ne sait ce qu’est un « incident ouvert ».

Le processus minimal pour un immeuble

Vous n’avez pas besoin d’une plateforme d’entreprise à 200 fonctionnalités. Le processus minimal utile pour la gestion de copropriété comprend :

• Titre + description + catégorie facultative + photo facultative. Le signalement lui-même.
• Un champ de statut à 5 valeurs au maximum. Nouveau, En cours, En attente de confirmation, Clôturé, Rouvert. Au-delà, c’est de la sur-ingénierie.
• L’attribution à l’un des trois rôles. Gestionnaire, technicien, résident.
• Des notifications push à l’attribution et à chaque changement de statut. Pour que personne n’ait à ouvrir l’application pour savoir qu’il s’est passé quelque chose.
• Un cloisonnement par immeuble. Chaque incident appartient à un immeuble, et chaque utilisateur ne voit que les immeubles dont il fait partie.

C’est tout le cœur du sujet. Si un outil vous offre cela, avec une interface que les résidents peuvent utiliser sans formation, vous avez ce qu’il vous faut.

Les objections qui reviennent toujours

« Mes résidents ne l’utiliseront jamais. »

Environ 70 % l’utiliseront. Les 30 % restants écriront à un voisin qui l’utilise, et ce voisin reportera l’incident dans l’application. Vous n’avez pas besoin de 100 % des résidents pour profiter des bénéfices. Il vous en faut assez pour que la boîte de réception des incidents devienne la référence.

« On a essayé par e-mail, ça n’a pas marché. »

L’e-mail n’est pas un système de tickets. Il n’a ni statut, ni boîte partagée, ni attribution, ni filtre, ni aiguillage. Traiter l’e-mail comme un système de tickets échoue, parce que ce n’en est pas un.

« On a déjà un tableur Excel pour ça. »

Un tableur Excel est plus proche d’un système de tickets qu’un groupe WhatsApp. Il a des identifiants et une sorte de colonne de statut. Mais il n’a toujours ni notifications, ni travail à plusieurs en temps réel, ni rien que les résidents puissent voir, ni automatisation. C’est un relevé du travail. Ce n’est pas un processus.

Le changement d’état d’esprit

Le plus difficile, quand on passe à un système de tickets, c’est le déclic mental : passer de « le système, c’est moi » à « le système, c’est le système, et moi je le supervise ». Les gestionnaires qui l’intègrent dépassent largement la taille de portefeuille qu’ils croyaient tenable. Les autres continuent de jouer les aiguilleurs humains jusqu’à l’épuisement.

La première semaine paraît étrange, parce que vous ne répondez plus en permanence. Puis vous vous rendez compte que les immeubles tournent sans que vous interveniez en temps réel, et que c’est parce que le processus lui-même fait le travail qui, avant, ne vivait que dans votre tête.