Révisé le 2026-07-12 · Public : agences
Un texto « peux-tu ajouter un champ pour le numéro de police d'assurance? » n'est pas un cahier des charges. C'est pourtant sur ce genre de message, envoyé un mardi soir, que beaucoup d'agences configurent des changements sans jamais documenter ce qui a été demandé, pourquoi, ni combien de temps ça a réellement pris.
Ce guide vous propose un processus simple de demande de changement (change request) pour les mandats GoHighLevel : formulaire minimal, estimation, approbation, livraison.
Ce que vous allez mettre en place
- Un formulaire ou gabarit de demande de changement.
- Une règle claire : ajustement mineur inclus vs change request facturable.
- Une étape d'approbation client avant de commencer.
- Une trace écrite de chaque changement livré.
Avant de commencer
- Un canal de communication clair avec le client (courriel, formulaire, outil de ticket).
- Une définition de ce qui distingue un ajustement mineur d'un vrai change request.
- Un tarif horaire ou forfaitaire pour les changements hors forfait.
Étape 1 : Définir ce qui est inclus vs facturable
Écrivez la règle en une phrase pour le client. Exemple : « Corrections de typo, ajustement de texte dans un courriel existant = inclus. Nouveau workflow, nouveau pipeline, nouvelle intégration = change request. » Partagez cette règle dès la signature du mandat.
Étape 2 : Créer le gabarit de demande
Chaque demande doit capturer : description du changement, pourquoi (objectif business), urgence, qui approuve côté client. Un Google Form, un champ dans votre outil de ticket, ou un courriel avec ces rubriques obligatoires suffit.
Étape 3 : Recevoir et qualifier la demande
Quand une demande arrive, ne commencez pas tout de suite. Lisez, posez une question de clarification si besoin, puis estimez en heures (fourchette basse / haute). Répondez dans les 24 à 48 h ouvrables avec l'estimation.
Étape 4 : Obtenir l'approbation écrite
Le client approuve par courriel ou clic dans votre outil : « Oui, procéder pour X heures à Y $/h » ou « Oui, forfait Z ». Pas de travail sans approbation. Un « oui verbal » un vendredi soir ne compte pas.
Étape 5 : Planifier et exécuter le changement
Planifiez la fenêtre de déploiement (évitez vendredi 16 h sur un compte en production). Testez sur un compte lab ou hors heures si le changement touche des workflows actifs. Voir Gouverner vos snapshots si vous poussez une mise à jour.
Étape 6 : Livrer et documenter
À la livraison, envoyez un résumé : ce qui a changé, où le voir dans GHL, date de mise en ligne. Ajoutez l'entrée au dossier client. Voir Documenter une livraison GHL.
Étape 7 : Facturer et archiver
Facturez selon l'approbation. Archivez la demande, l'approbation et le résumé de livraison ensemble. Dans six mois, personne ne se souviendra du « petit ajout » sans cette trace.
Pièges fréquents
- Commencer le travail sur un texto vague sans estimation ni approbation.
- Pas de distinction claire entre support inclus et change request.
- Déployer un changement majeur un vendredi sans personne de garde.
- Aucune trace écrite : le client oublie avoir approuvé, vous oubliez avoir livré.
- Sous-estimer les heures et absorber le coût à chaque « petit ajout ».
Vous avez réussi si…
- Chaque changement hors forfait a une demande, une estimation et une approbation écrite.
- Le client sait où regarder pour voir ce qui a changé après chaque livraison.
- Votre équipe ne configure plus rien sur un texto du mardi soir sans processus.