Ordres de modification convenus par chat, jamais documentés
Un client demande « une petite addition » lors d’un appel, cela est construit, et six mois plus tard, personne ne peut indiquer quand la portée — ou le prix — a réellement changé.
Les missions de services informatiques se basent sur des estimations, des SOW et des facturations par étapes — pas sur une liste de prospects. Voici comment mettre en place un CRM autour de cette réalité, étape par étape.
Un engagement des services informatiques n’est pas un accord unique — c’est une chaîne de documents et de dates : une estimation définie, un SOW signé, une série de jalons de livraison, les ordres de modification qui suivent inévitablement, et un renouvellement AMC un an plus tard. Un tableur peut contenir une liste de clients, mais il ne peut pas vous dire quel SOW n’est pas encore signé, quelle facture de jalon est en retard ou quel AMC renouvellera le mois prochain. Une fois que vous exécutez plus d’une poignée de missions simultanément, c’est dans cet écart que les revenus s’échappent discrètement.
Chaque engagement avec les services informatiques — création de site web, application, support continu — suit la même forme. C’est le nommage des étapes qui les rend traçables.
Un prospect contacte un projet ou un besoin de soutien. Le premier travail consiste simplement à le rassembler au même endroit — pas un e-mail transféré, mais un véritable enregistrement avec une source et un propriétaire.
Vous évaluez ce dont ils ont réellement besoin via des appels et des documents. C’est là que la plupart des détails se perdent s’ils restent dans la boîte mail de quelqu’un plutôt que dans le registre.
Un coût et un calendrier approximatifs reviennent au client, en fonction des exigences recueillies.
L’estimation devient un énoncé de travail formel — portée, livrables, jalons et modalités de paiement détaillés.
La portée ou le prix est ajusté. Chaque révision devrait mettre à jour le même enregistrement SOW, et non être bifurqué dans un nouveau fil de courriels.
Le client signe. C’est le moment où le travail doit être autorisé à commencer — et le moment où le calendrier de paiement s’impose.
Le travail est livré selon les jalons du SOW, chacun déclenchant sa propre facture.
Les changements de portée en cours de projet sont enregistrés comme leur propre enregistrement, liés au SOW original — et non absorbés silencieusement dans la chronologie.
Une fois livré, l’engagement passe à un contrat annuel de maintenance qui nécessite un rappel de renouvellement plusieurs mois à l’avance.
Ce ne sont pas des hypothèses — ce sont les mêmes points de défaillance qui apparaissent dans la plupart des équipes services informatiques avant de se centraliser sur un CRM.
Un client demande « une petite addition » lors d’un appel, cela est construit, et six mois plus tard, personne ne peut indiquer quand la portée — ou le prix — a réellement changé.
La personne qui a dirigé Discovery part ou s’occupe, et le seul document de ce qui a réellement été promis lui est reparti.
Sans rappel lié à la date du contrat, un contrat annuel de maintenance expire discrètement — et le client découvre quand quelque chose tombe en panne.
Les jalons sont livrés mais la facture correspondante est une étape manuelle, facile à oublier, plutôt qu’une étape déclenchée.
Le flux de travail ci-dessus ne fonctionne que si le CRM est configuré pour correspondre, et non à un pipeline de vente générique dans lequel vous forcez votre processus.
Demande, collecte des besoins, estimation, SOW, signé, livraison, AMC — comme de véritables étapes, pas comme un pipeline de lead/won/lost sans le détail supprimé.
Ainsi, un rapport ou une vue filtrée peut répondre à « ce qui est en retard » sans que personne ne relise chaque dossier.
Ainsi, « SOW signé » est un événement système avec un horodatage, pas un PDF scanné que quelqu’un doit retrouver et retélécharger.
Réglez une fois, pour que rien ne dépende de quelqu’un qui se souvient de consulter un calendrier dans trois mois.
Vous pouvez construire le processus ci-dessus dans n’importe quel CRM qui vous permet de personnaliser pipelines et champs. Worxley a été conçu spécifiquement en pensant aux engagements des services IT — la forme SOW et jalons est un choix de première classe, pas une solution de contournement.
Mettez en place exactement les neuf étapes ci-dessus — ou moins — sans lutter contre une structure fixe d’entonnoir de vente.
Envoyez, signez et suivez les SOW sans laisser le dossier ni payer pour un outil de signature électronique séparé.
Des coups de main automatisés avant qu’une facture de jalon ou un renouvellement AMC ne soit à échéance, pas après qu’elle soit déjà en retard.
Donnez à un client une visibilité sur son propre statut d’engagement sans lui donner accès à l’ensemble de votre CRM.
Un outil de ticketing suit les problèmes après qu’un client est en ligne. Cela couvre tout ce qui précède — demande, cadrage, SOW et livraison — ainsi que l’AMC qui finit par relier les deux. La plupart des équipes gèrent les deux, connectées par le même enregistrement client.
Consignez chaque ordre de modification comme un enregistrement lié à part entière par rapport au SOW original, avec sa propre valeur et validation — afin que la véritable portée et le prix de l’engagement soient toujours la somme de ce qui est réellement enregistré, pas ce dont quiconque se souvient avoir accepté.
Oui — définissez un champ de date de renouvellement sur l’engagement et une règle de rappel s’affiche un nombre déterminé de jours avant le propriétaire du compte, sans que personne ne maintienne un calendrier séparé.
La plupart des équipes importent leur liste de clients existante comme point de départ, puis reconstruisent les étapes du pipeline pour correspondre au flux de travail ci-dessus par la suite. Vous n’avez pas besoin de migrer des SOW historiques pour tirer de la valeur du suivi correctement des nouveaux.
Partez du pipeline de ce guide et adaptez-le à votre activité.