CRM pour Technologie

À quoi ressemble vraiment la vente de technologie ?

La demande entrante d'un éditeur est rarement un appel téléphonique. C'est un compte d'essai créé à 23 h 10 par quelqu'un avec une adresse professionnelle, qui s'est aussi inscrit chez deux concurrents ; un formulaire « demander une démo » rempli depuis un comparatif ; ou un message d'un partenaire qui a rencontré un prospect à un salon. La personne est assez technique pour évaluer seule et assez occupée pour avoir oublié jeudi. Celui qui répond le premier avec quelque chose d'utile — une réponse qui marche, un créneau de démo, un exemple client pertinent — obtient le second échange ; les autres gardent un essai qui expire en silence.

Les données sur la vitesse sont anciennes et sans nuance : l'étude de la Harvard Business Review sur 2 241 entreprises a montré que répondre dans l'heure rendait un lead près de sept fois plus susceptible d'être qualifié qu'en attendant une heure de plus, et que le délai moyen de réponse était de 42 heures. Les entreprises technologiques ne sont pas plus lentes que la moyenne ; ce sont simplement celles où le fondateur fait encore la vente entre deux mises en production.

La deuxième forme, c'est la seconde vente. Dans un modèle d'abonnement ou de maintenance, gagner l'affaire est le début du revenu, pas la fin. Le client qui a ouvert quatre tickets le premier mois et en a vu trois traités en retard ne renouvelle pas, et aucun rapport de pipeline ne dira pourquoi, parce que le pipeline a cessé de regarder à « gagnée ». Le support et la vente doivent être sur la même fiche.

Le pipeline que nous recommandons pour démarrer

Chaque étape est un fait vérifiable. « Intéressé » et « chaud » ne sont pas des étapes ; un essai créé et une démo effectuée le sont.

Pour une ESN ou un intégrateur, la forme est la même à deux différences près : « réunion de cadrage » remplace « démo », et « proposition envoyée » porte un chiffrage de projet plutôt qu'un prix d'abonnement. Si vous vendez à la fois du produit et de la prestation, donnez-leur des pipelines séparés ; Starter en inclut deux, Growth cinq, Business dix.

Les champs utiles sur un lead technologique

La mise en page de la fiche lead se configure par rôle : le commercial voit les champs de valeur et d'essai, l'agent de support voit le contact technique et les tickets ouverts, et personne ne fait défiler quarante champs. Les produits portent aussi leurs champs personnalisés — niveau d'offre, périodicité de facturation, postes inclus — de sorte qu'une proposition se construit depuis le catalogue au lieu d'être saisie à la main.

Essais, démos et le problème de l'essai inactif

Un essai que personne de votre côté n'a touché au troisième jour est, statistiquement, déjà perdu. Le webhook de leads accepte une simple requête HTTP depuis votre propre application, si bien qu'un nouveau compte d'essai crée un lead à l'instant de son inscription, avec l'offre, la source et les champs de campagne. Ensuite, le travail consiste à planifier, pas à se souvenir.

1. J0 — responsable et premier contactLa distribution par canal attribue le lead à tour de rôle ; une automatisation envoie le premier message dans la langue du lead et crée une tâche « appeler sous 4 heures ouvrées ».
2. J+3 — le point d'étapeUne automatisation sur le champ « début d'essai » ouvre une tâche pour le responsable : l'essai a-t-il produit quelque chose ? La réponse est une note et un changement d'étape, pas une impression.
3. Démo — planifiée depuis le filUn rendez-vous avec date, présentateur et prospect ; les rappels partent par WhatsApp, SMS ou e-mail ; le résultat marque présent ou absent et déplace l'étape.
4. J+12 — l'alerte d'expirationDeux jours avant la fin de l'essai, une tâche et un message ; un essai qui expire sans échange passe en Perdue avec le motif « pas de contact », qui est un motif que l'on peut corriger.

Le rapport de délai de réponse mesure la première réponse en minutes ouvrées selon le calendrier des horaires, si bien que l'inscription de 23 h 10 traitée à 9 h 05 compte cinq minutes et non dix heures, et que le commercial qui répond systématiquement en quarante minutes apparaît à côté de celui qui répond en quatre.

Tickets : le support comme outil de rétention

Le module de tickets est le bureau de support de vos clients à l'intérieur du CRM : un client ouvre un ticket par e-mail ou via le formulaire, ou votre équipe en crée un depuis une conversation WhatsApp, et il vit sur la même fiche client que l'affaire qui l'a fait signer. Un ticket a un statut, une priorité, un responsable et un fil de messages ; l'attribution envoie une notification ; le manager voit la file par personne et par ancienneté.

Trois choses font que le module fonctionne dans une entreprise technologique au lieu de simplement exister :

Une fiche, deux historiques

Le chargé de compte qui ouvre l'échange de renouvellement voit les douze tickets du trimestre passé avant que le client ne les mentionne. L'agent de support voit l'offre, les postes et qui a vendu.

Un routage par règle, pas à la voix

Une automatisation attribue les tickets par produit, par niveau de client ou à tour de rôle dans l'équipe support, et renotifie le responsable quand un ticket reste sans réponse au-delà d'un délai que vous fixez.

La charge de tickets comme signal commercial

Un rapport croisé tickets par client par mois, à côté du montant des affaires, est l'alerte précoce d'attrition dont une activité par abonnement a besoin et qu'elle a rarement.

Soyons précis sur ce que ce n'est pas : il n'y a ni chronomètres de SLA contractuels ni chaînes d'escalade en cas de dépassement. Il y a des priorités, des anciennetés, des règles d'attribution et des rapports — ce que la plupart des équipes de moins de cinquante personnes utilisent réellement.

Les automatisations qui se rentabilisent

Une automatisation est une règle avec un déclencheur et une ou plusieurs actions. Les règles d'étape se déclenchent quand un lead entre dans une étape ; les règles globales surveillent les dates, l'inactivité et les messages entrants. Le catalogue comprend l'attribution d'un responsable, l'envoi d'un message ou d'un e-mail, la création d'une tâche, la modification d'un champ, l'ajout d'une étiquette et le changement d'étape, et chaque exécution est journalisée avec son résultat.

Commerce, support, technique : qui voit quoi ?

Les rôles décident quels modules une personne peut utiliser et ce qu'elle peut y faire — consulter, créer, modifier, supprimer, exporter — par entité. Le périmètre de données décide de quelles fiches elle voit : les siennes, celles de son département ou toutes. Les départements forment un organigramme ; un manager voit ce que voit son département.

Commercial

Ses propres leads et affaires plus les non attribués ; consultation et modification, ni suppression ni export ; voit les prix et sa propre commission, pas celles des autres.

Directeur commercial

Périmètre de département sur le commerce ; réattribue, exporte, voit les rapports de pipeline et de délai de réponse.

Agent de support

Les tickets et les fiches clients derrière ; la boîte de réception ; ni pipeline ni finance.

Développeur

Les tickets qui lui sont attribués, la fiche client en lecture seule ; rien d'autre. La plupart des développeurs ne demandent pas mieux.

Fondateur / administrateur

Tout, y compris la finance, le journal d'activité et les paramètres.

Le journal d'activité enregistre qui a consulté, modifié, réattribué ou exporté quelle fiche — c'est la réponse quand un client demande qui a eu accès à ses données, et une chose raisonnable à avoir avant qu'un questionnaire de sécurité ne le demande.

Une semaine dans un éditeur de douze personnes

1. Lundi — les inscriptions du week-endDéjà attribuées par la distribution ; chaque commercial appelle sa liste depuis le softphone, renseigne les postes et l'outil actuel, déplace l'étape.
2. Mardi–jeudi — les démosPlanifiées depuis le fil, rappelées automatiquement, marquées « présent » ; les propositions sont construites depuis le catalogue et envoyées le jour même.
3. Chaque jour — la file de ticketsRoutée à tour de rôle, les plus anciens d'abord ; un développeur prend les deux tickets escaladés ; le client voit les réponses dans le fil qu'il a ouvert.
4. Vendredi — la liste des inactifsLes propositions sans mouvement depuis dix jours, remontées par l'automatisation ; un appel chacune, un motif de perte honnête quand il s'applique.
5. Fin de mois — les deux rapportsLe pipeline par étape et par source ; les tickets par client par mois. Les deux sur un écran, les deux exportables.

ESN et intégrateurs : le projet après l'affaire

Une ESN ou un intégrateur vend un projet, pas une offre. Le pipeline s'arrête à « gagnée » et le travail commence : une liste de tâches avec responsables et dates, des jalons, des heures et des coûts. Dans la formule Business, une affaire gagnée peut ouvrir un projet avec ses tâches, et les revenus et dépenses de l'affaire en montrent la rentabilité — le chiffrage face à ce que cela a réellement coûté en personnes et en licences.

• Les tâches récurrentes couvrent les contrats de maintenance : une fenêtre de correctifs mensuelle, une revue trimestrielle, un renouvellement de licence annuel, chacun générant sa tâche à l'échéance.
• Les produits avec prix de revient couvrent les licences et le matériel revendus ; quand l'affaire est gagnée, le coût est comptabilisé automatiquement et la marge sur la revente devient visible.
• Les tickets sous contrat restent sur la fiche client, si bien que le chargé de compte voit la charge de support quand vient l'échange de renouvellement.

Les chiffres qu'un fondateur ou un directeur commercial doit suivre

• Le délai de première réponse en minutes ouvrées, par commercial — le chiffre qui prédit les démos mieux que tout autre.
• Le taux inscription → démo et démo → proposition, par source — quelles campagnes produisent des acheteurs et pas seulement des comptes.
• Les jours passés en « Proposition envoyée » — la fuite ; s'ils augmentent, quelqu'un ne relance pas.
• Les affaires gagnées et la valeur mensuelle par commercial et par mois — avec l'entonnoir derrière.
• Les tickets par client et par mois, et l'ancienneté des tickets par responsable — le signal de rétention, à côté du revenu qu'il protège.
• Les motifs de perte par produit — l'entrée la moins chère de la feuille de route produit.

Tout cela vient du générateur de rapports croisés à partir de Growth : lignes, colonnes, une mesure et un filtre, enregistrés et exportés en CSV.

Ce que ce n'est pas

Ce n'est pas un outil de suivi de tickets techniques pour les développeurs : il n'y a ni sprints, ni dépôts, ni versions, ni intégration avec les outils de développement. Les tickets sont des conversations client avec un statut et un responsable ; le bug derrière un ticket appartient à votre outil de développement, et le ticket en porte la référence dans un champ.

Ce n'est pas un moteur de facturation d'abonnements : il enregistre le montant des affaires, les revenus, les dépenses et les commissions, mais il ne débite pas de cartes, n'émet pas de factures récurrentes et ne gère pas les relances d'impayés. Et les sauvegardes quotidiennes automatiques de votre espace de travail ne font pas actuellement partie du service ; exportez ce que vous devez conserver.

Quand ça ne fonctionne plus

Quelle formule convient ?

Une start-up de deux fondateurs qui fait sa propre vente tourne sur Starter. Une société avec une équipe support, plus d'une poignée d'essais par semaine et des développeurs qui ne devraient voir que les tickets se retrouve sur Growth — pour les tickets, les automatisations et les rôles avant tout. Les sociétés de services qui ont besoin de projets et de marge par mission passent en Business. Voyez la page des tarifs, ainsi que les pages tickets et automatisations, les deux modules qui portent la charge.