Cas réel, prénom modifié
Comment une première automatisation a progressivement donné naissance au CRM qui relie aujourd’hui ses cinq ateliers.
Miguel est carrossier. Il dirige aujourd’hui cinq ateliers en région parisienne, avec trente-cinq salariés et quinze à vingt véhicules qui entrent chaque jour.
Lorsque son entreprise était plus petite, il pouvait suivre une grande partie de l’activité lui-même. Avec deux ateliers, il connaissait les dossiers, les achats importants et les dépenses engagées. Lorsqu’une réparation coûtait plus cher que prévu, il arrivait encore à comprendre pourquoi.
En passant à cinq ateliers, ce suivi s’est dispersé.
Les véhicules étaient pris en charge à différents endroits. Les achats étaient effectués par plusieurs personnes. Les factures fournisseurs arrivaient séparément. Les consignes circulaient dans des groupes WhatsApp. Certaines informations restaient dans le téléphone ou dans la mémoire d’un chef d’atelier.
L’activité avait augmenté, mais Miguel avait perdu une partie de la visibilité qu’il possédait lorsque l’entreprise était plus petite.
Il voyait ce que le groupe encaissait et dépensait globalement. Il ne pouvait plus facilement déterminer ce que chaque atelier coûtait, ce que chaque réparation rapportait réellement ni pourquoi deux garages ayant une activité comparable n’obtenaient pas le même résultat.
Lorsqu’il disait gagner presque la même chose avec cinq ateliers qu’auparavant, cela ne signifiait pas nécessairement que son chiffre d’affaires n’avait pas progressé. Le problème était qu’en grandissant, les dépenses avaient elles aussi augmenté et qu’il ne pouvait plus expliquer précisément où partait l’argent.
Miguel passait ses journées entre les ateliers.
Le soir, lorsque les équipes avaient terminé, il reprenait les véhicules un par un pour préparer les factures. Il devait retrouver ce que le client avait demandé, vérifier ce qui avait réellement été fait et s’assurer que chaque prestation apparaissait au bon tarif.
Ce travail pouvait lui prendre environ trois heures et le retenir jusqu’à 22 heures.
Miguel possédait déjà un logiciel de facturation. Celui-ci savait produire une facture à partir des informations qu’on lui fournissait.
Le problème se trouvait avant.
La demande initiale du client pouvait être dans WhatsApp. Une prestation supplémentaire pouvait avoir été décidée directement dans l’atelier. Une photographie restait sur le téléphone d’un salarié. Une consigne pouvait n’avoir été entendue que par la personne présente au moment de l’échange.
Pour créer une facture complète, Miguel devait reconstituer lui-même toute l’histoire du véhicule.
Et comme lui seul possédait cette vision d’ensemble, personne ne pouvait réellement prendre sa place.
Lorsqu’une prestation réalisée n’était pas remontée jusqu’à Miguel, elle risquait de disparaître de la facture.
Selon son estimation, un oubli représentait souvent entre 200 et 300 euros. Certains mois, il estimait que le total pouvait atteindre 5 000 à 6 000 euros de prestations manquantes.
Ce montant n’était pas issu d’une mesure comptable précise. Certaines erreurs étaient retrouvées plus tard et corrigées. D’autres ne l’étaient probablement jamais.
L’oubli pouvait également créer un problème avec le client. Une prestation demandée risquait de ne pas être effectuée simplement parce que l’information n’était pas arrivée jusqu’à la bonne personne.
Miguel n’avait donc pas seulement un problème de saisie. Il avait un problème de circulation de l’information entre la demande du client, le travail de l’atelier et la facture finale.
La facturation n’était que la partie la plus visible.
Miguel recevait environ une centaine d’appels par jour. Les appels des clients faisaient partie de son activité. Mais vingt à trente appels pouvaient également venir de ses propres équipes.
Un salarié cherchait une consigne. Un chef d’atelier voulait confirmer une prestation. Quelqu’un avait besoin de savoir ce qui avait été convenu avec un client.
La réponse existait souvent, mais personne ne savait toujours où la trouver.
Elle pouvait être dans un groupe WhatsApp, dans le logiciel de facturation, dans le téléphone d’un collègue ou dans la mémoire d’une personne travaillant dans un autre atelier.
Alors les équipes appelaient Miguel.
Même lorsqu’il n’était pas physiquement dans un garage, il restait la mémoire centrale des cinq établissements. Les ateliers pouvaient fonctionner sans sa présence, mais ils continuaient à avoir besoin de ses réponses.
Miguel ne partait plus réellement en vacances. Son entreprise avait grandi, mais elle reposait toujours trop directement sur lui.
Miguel nous a contactés à travers le diagnostic du site.
Il ne nous a pas demandé de construire un CRM complet. Il cherchait un moyen de suivre ses cinq ateliers sans devoir être présent partout, répondre à chaque question et refaire toutes les factures le soir.
Nous sommes allés observer le fonctionnement sur place.
Les chefs d’atelier savaient parfaitement où en étaient les réparations. Ils n’avaient pas besoin d’un logiciel pour leur dire qu’un véhicule était en préparation, en peinture ou en remontage.
Ce qui se perdait se situait entre trois moments :
Ces informations n’étaient pas réunies dans un dossier commun.
Chaque soir, Miguel refaisait le lien à la main. La première solution devait commencer par supprimer ce travail de reconstruction.
Nous n’avons pas remplacé le logiciel de facturation existant.
Nous avons construit ce qui lui manquait avant la facture : une fiche d’intervention commune qui accompagne le véhicule depuis son arrivée.
Quand un véhicule entre dans l’un des ateliers, l’équipe crée sa fiche et y inscrit les prestations demandées par le client.
Si une prestation est ajoutée pendant les travaux, elle est enregistrée sur la même fiche. Les documents, les photographies, les consignes et les informations utiles restent rattachés au véhicule.
À partir de là, le système connaît :
Lorsqu’une incohérence ou un oubli potentiel apparaît, le logiciel le remonte dans les éléments à vérifier.
L’information est enregistrée au moment où elle apparaît, par la personne qui la connaît. Miguel n’a plus besoin de la reconstituer plusieurs heures plus tard.
À partir du moment où les prestations sont saisies dans la fiche du véhicule, le logiciel dispose des éléments nécessaires pour créer la facture.
Grâce à la connexion API avec l’application de facturation existante, la facture est générée automatiquement.
Personne ne reprend le dossier pour recopier manuellement les prestations dans un deuxième outil.
Miguel conserve le contrôle final. En fin de service, il vérifie les prestations, les tarifs appliqués et les anomalies remontées par le système. Il peut corriger un élément si nécessaire.
Mais son travail a changé.
Il ne passe plus trois heures à chercher les informations et à construire chaque facture. Il consacre désormais environ une heure, avant la fin du service, à vérifier ce que le système a préparé.
Une prestation enregistrée dans l’application n’est pas seulement une ligne destinée à apparaître sur une facture.
Elle est reliée :
La même information n’est donc pas saisie une première fois pour l’intervention, une deuxième fois pour la facture et une troisième fois pour les statistiques.
Elle est enregistrée une fois, puis utilisée partout où elle est nécessaire.
Les courriels sont également intégrés. Les échanges peuvent être retrouvés avec le client, le véhicule et l’intervention concernés. L’application peut préparer un message à partir des informations déjà présentes dans le dossier, sans demander à l’équipe de rechercher puis recopier le contexte.
Les données enregistrées alimentent aussi les statistiques. Miguel peut suivre l’activité des ateliers, les prestations réalisées, la facturation, les paiements, les dépenses et les marges à partir des mêmes informations.
Tout reste relié autour de la fiche du véhicule.
Nous n’avons pas installé la solution dans les cinq garages en même temps.
La première version a été testée pendant deux semaines dans un seul atelier.
Cette période a permis de vérifier le fonctionnement sur de vrais véhicules :
Une fois le fonctionnement vérifié dans ce premier atelier, la solution a été étendue aux quatre autres.
Le déploiement complet a pris environ trois semaines : deux semaines de test, puis une semaine pour déployer dans le reste du groupe.
La première version avait principalement été pensée pour être utilisée au bureau.
Dans la réalité, les personnes qui renseignent une intervention travaillent dans l’atelier, souvent debout à côté du véhicule, avec leur téléphone dans la poche.
Nous avons donc repris l’interface mobile : de plus gros boutons, moins d’informations affichées simultanément et les actions principales accessibles facilement depuis un téléphone.
Nous pensions également que Miguel commencerait par consulter un tableau de bord général.
Dans la pratique, lui et ses équipes ouvraient surtout la liste des véhicules en cours. C’est là qu’ils voulaient voir immédiatement :
La liste des véhicules est donc devenue l’écran principal. Le tableau de bord existe toujours, mais il n’est plus la première chose que l’équipe voit.
Miguel a rapidement compris l’intérêt de la solution. L’adoption a demandé plus de temps à certains membres de l’équipe.
Plusieurs salariés avaient l’habitude d’utiliser WhatsApp et étaient peu à l’aise avec les outils informatiques.
Nous avons donc conservé temporairement leur fonctionnement habituel. La fiche était créée dans l’application, puis l’application publiait automatiquement les informations utiles dans le groupe WhatsApp.
Les salariés gardaient leur point de repère sans avoir à saisir deux fois la même information.
À mesure qu’ils ont commencé à utiliser les fiches des véhicules, ils ont constaté qu’ils retrouvaient plus facilement les consignes et qu’ils avaient moins besoin d’appeler Miguel ou leurs collègues.
C’est finalement Miguel qui a décidé d’abandonner WhatsApp pour le suivi des interventions. Les informations utiles étaient désormais disponibles dans l’application.
La connexion API avec le logiciel de facturation a aussi permis de réimporter l’historique.
L’application a repris les anciennes factures pour effectuer un contrôle rétroactif et rechercher les dossiers comportant des écarts.
Ce contrôle a fait ressortir une vingtaine de factures présentant des erreurs ou des prestations oubliées. Elles ont pu être vérifiées puis corrigées.
La solution n’a donc pas seulement sécurisé les nouvelles factures. Elle a également permis d’identifier des anomalies déjà présentes dans les anciens dossiers.
Lorsqu’un salarié cherche aujourd’hui une information, il consulte la fiche du véhicule.
Il peut y retrouver :
Il n’a plus besoin d’appeler plusieurs personnes pour savoir qui possède la réponse.
Les appels internes ont diminué parce que l’information est accessible par les équipes directement dans les fiches d’intervention.
Miguel conserve une vue générale, mais il n’est plus le passage obligé pour chaque question.
Une fois la facturation mieux organisée, Miguel nous a demandé de travailler sur un autre problème.
Il avait beaucoup de dépenses, mais ne pouvait plus facilement comprendre d’où elles venaient.
Avec cinq ateliers, il voulait savoir :
Nous avons ajouté un suivi des dépenses.
Chaque facture fournisseur peut être contrôlée, validée puis rattachée à un atelier, une intervention et un véhicule.
Le logiciel rapproche ensuite les prestations facturées et les coûts associés. Miguel peut consulter la situation par réparation, par véhicule ou par établissement.
Il voit désormais non seulement ce qui a été vendu, mais aussi ce que l’intervention a réellement coûté.
La centralisation des informations a permis à Miguel de répondre à des questions devenues difficiles avec la croissance :
Lorsque Miguel dirigeait encore deux ateliers, il pouvait garder une grande partie de ces informations en tête.
Avec cinq ateliers, trente-cinq salariés et plusieurs dizaines de véhicules en circulation, ce n’était plus possible.
Le CRM a repris ce travail de synthèse. Il rassemble les informations produites par les différents établissements, les rattache au bon dossier puis les transforme en une vue globale du groupe.
Miguel peut partir d’un indicateur général et descendre jusqu’à un atelier, un véhicule, une intervention ou une dépense précise.
C’est cette synthèse qui lui a rendu la visibilité qu’il avait perdue en grandissant.
La facturation et le suivi des dépenses ont été les premières étapes.
D’autres besoins sont ensuite apparus à l’usage. Chaque nouveau module concernait les mêmes éléments : le véhicule, le client, l’intervention, les pièces, les documents, les communications, la facture, le paiement ou la dépense.
Conserver plusieurs automatisations séparées n’avait plus de sens. Elles avaient besoin de partager les mêmes informations et le même historique.
Elles ont donc progressivement été réunies dans un CRM complet construit autour du fonctionnement des cinq ateliers.
Le CRM couvre aujourd’hui :
Le CRM n’avait pas été défini ainsi au premier jour. Il s’est construit à partir des besoins rencontrés et des demandes successives de Miguel.
Des logiciels standards peuvent gérer plusieurs établissements et relier certaines informations.
Mais pour Miguel, cela aurait généralement nécessité d’équiper les cinq ateliers, d’ajouter les utilisateurs et de souscrire aux différents modules nécessaires.
Le coût pouvait alors augmenter avec :
Surtout, Miguel aurait dû adapter le fonctionnement de ses ateliers aux règles prévues par le logiciel.
Ses besoins étaient plus particuliers :
Nous avons conservé son logiciel de facturation pour ce qu’il faisait correctement, puis développé ce qui lui manquait autour.
Miguel n’a pas acheté cinq licences mensuelles séparées.
Il a financé la conception d’une seule application destinée à relier ses cinq établissements.
Une fois la création réglée, il n’a pas de licence App363 mensuelle à payer pour chaque atelier, chaque utilisateur ou chaque module déjà développé.
Le logiciel appartient à son entreprise et continue de fonctionner sans que ses fonctions existantes soient conditionnées au paiement de cinq abonnements.
Un abonnement global de support et de SAV peut rester en place pour assurer le suivi technique. Les éventuels services extérieurs, comme l’hébergement, les SMS ou certaines API, sont identifiés séparément.
Lorsque Miguel demande une nouvelle fonctionnalité, elle fait l’objet d’un développement supplémentaire. Il paie cette évolution lorsqu’il la décide, plutôt que de souscrire en permanence à une série de modules dont il n’aurait pas forcément besoin.
Le modèle est donc différent :
Lorsqu’il ouvre l’application, Miguel arrive sur la liste des véhicules en cours.
Pour chacun, il peut voir :
Il peut filtrer les informations par atelier ou consulter l’ensemble des cinq garages.
Il ne voit pas seulement ce qui a été facturé. Il peut comprendre ce qui s’est passé avant la facture, ce que l’intervention a coûté et ce qui nécessite encore son attention.
Au début du projet, Miguel passait ses journées à répondre aux questions de ses équipes et ses soirées à reconstruire les factures.
Aujourd’hui, les prestations sont enregistrées pendant les interventions. Les factures se créent automatiquement. Les oublis potentiels remontent dans l’application. Les équipes trouvent les informations dans les fiches des véhicules et les appels internes ont diminué.
En fin de service, Miguel consacre environ une heure à vérifier les prestations et les tarifs.
Il dispose aussi d’une vue globale de ses cinq ateliers depuis son téléphone.
L’objectif n’est pas de le faire travailler pendant ses congés. Mais s’il souhaite vérifier un point, il peut consulter la situation sans appeler successivement les cinq garages.
Et surtout, les ateliers continuent à fonctionner sans attendre constamment une information que lui seul posséderait.
| Avant | Aujourd’hui | |
|---|---|---|
| Facturation | Environ 3 h chaque soir, jusqu’à 22 h | Environ 1 h de vérification en fin de service |
| Prestations oubliées | Jusqu’à 5 000 à 6 000 € certains mois (estimation de Miguel) | Remontées dans les éléments à vérifier |
| Anciennes factures | Jamais recontrôlées | Une vingtaine corrigées |
| Appels des équipes | Vingt à trente par jour | En baisse : la réponse est dans la fiche |
| Dépenses et marges | Vues globalement | Par atelier, véhicule et intervention |
| Vacances | Plus réellement | Miguel est reparti |
Miguel n’avait pas simplement besoin d’un logiciel capable d’éditer une facture. Il en possédait déjà un.
Il avait besoin que l’information circule correctement entre la demande du client, le travail réalisé, la facture, le paiement, les dépenses et la marge.
Le projet a commencé par une tâche précise : éviter que Miguel soit le seul à pouvoir préparer correctement les factures.
Une première automatisation en a fait apparaître une autre. Les données ont ensuite été reliées, centralisées et synthétisées jusqu’à former le CRM utilisé aujourd’hui dans les cinq ateliers.
Ce n’est pas uniquement l’automatisation de la facturation qui lui a rendu du temps.
C’est le fait d’avoir, enfin, une information commune à ses cinq ateliers et une vue globale de son entreprise.
On regarde votre cas et on vous montre le avant / après, gratuitement, en une minute.