Demande d'intervention : de la saisie au technicien

Une demande d’intervention arrive par mail. Entre ce mail et le technicien qui part, il y a six gestes : lire, contrôler, créer le bon, choisir qui y va, planifier, prévenir le client.

Aucun n’est compliqué. Ensemble, ils prennent environ cinq minutes, plusieurs dizaines de fois par semaine — et chacun est une occasion d’oublier quelque chose.

Le vrai problème n’est pas le temps

Cinq minutes par demande, c’est mesurable et ça se supporte.

Ce qui se supporte moins, c’est ce qui arrive quand la personne qui fait ces six gestes est absente, ou débordée un lundi matin. La chaîne s’arrête. Les demandes s’empilent dans une boîte mail, et personne ne sait dire combien il y en a ni depuis quand.

Une chaîne qui repose sur une personne n’est pas un processus. C’est une habitude, et elle s’interrompt avec elle.

Ce qui a été construit chez Sotrelec

La demande reçue par mail est analysée et transformée en bon d’intervention structuré, prêt à être affecté. Le choix du technicien tient compte des compétences et du secteur. La planification déclenche la confirmation au client, sans que personne ait à la rédiger.

Le traitement complet est passé de cinq minutes à trente secondes.

Ce qui n’a pas changé

Le logiciel de gestion. Il n’a pas été remplacé, il n’a même pas été modifié.

L’outil construit se place avant lui : il prépare l’information, la structure, la contrôle, et la lui transmet une fois propre. C’est le principe qui revient dans presque tous nos chantiers — on outille ce qui se passe avant le logiciel, pas le logiciel lui-même.

Le contrôle humain n’a pas disparu non plus. Une demande ambiguë remonte à une personne, comme avant. La différence est qu’elle remonte signalée, au lieu de se noyer parmi les autres.

Les trois conditions qui ont rendu ça possible

Les demandes arrivaient sous une forme régulière. Pas identique — un mail reste un mail — mais suffisamment cadrée pour qu’on puisse en tirer les mêmes éléments à chaque fois.

Les règles d’affectation existaient déjà. Elles vivaient dans la tête de la personne qui affectait. Les écrire a été la vraie difficulté du projet, et de loin la partie la plus utile : plusieurs cas n’avaient jamais été tranchés explicitement.

Quelqu’un a vérifié pendant les premières semaines. Un système qui décide seul dès le premier jour ne se corrige jamais. Les premiers temps servent à attraper les cas que personne n’avait prévus.

Si votre chaîne ressemble à celle-là

Prenez dix demandes récentes et tracez leur trajet : qui les lit, qui décide, qui saisit, qui prévient le client. Notez le temps réel de chaque étape et les endroits où l’information est retapée.

C’est ce relevé qui dit si le chantier vaut le coup — et il tient sur une page.

Le diagnostic part de votre description et vous répond en moins d’une minute.