Travailler avec une entreprise: comment nous n'avons pas fait de système d'analyse pour un service SaaS

Nous étions très satisfaits du nouveau contrat et avons déjà imaginé comment le logo du client embellirait notre portefeuille. Mais tout s'est avéré moins rose. Nous vous expliquerons comment nous avons travaillé avec la fille d’une grande entreprise informatique russe et pourquoi nous n’avons pas réussi à faire un projet sympa.

à propos du projet

Le produit du client est le SaaS dans la sphère B2B, qui fonctionne sur un format de frais d'abonnement. L'utilisateur s'inscrit, passe l'autorisation, reconstitue son compte et utilise le service.

Notre tâche est d'aider le client à «collecter» des analyses. Pour ce faire, il était nécessaire de créer des processus de centre d'appels, de mettre en œuvre le CRM et de «rassembler» des analyses de bout en bout par des indicateurs clés.

Structure du processus

Avant de faire des analyses, vous devez préparer un paysage pour le collecter: structurer les processus de vente et mettre en place des intégrations avec les services. Nous avons trouvé plusieurs problèmes dans les processus:

1. Les gestionnaires étaient distraits par les étapes inutiles de l'entonnoir de vente et leur travail n'était en aucun cas surveillé;
2. Les rapports de vente étaient téléchargés manuellement à partir du panneau d'administration chaque jour;
3. Il y avait peu d'événements de conversion pour collecter des analyses.

Ensuite, nous avons fait une carte avec la structure d'interaction de tous les systèmes. Il montre quelle logique les événements devraient suivre et à quelles étapes l'analyste se dirige. Nous prenons les principales données du CRM et les corrélons avec des données sur la publicité et les conversions. Le rassembler dans myBI, le rendre dans Power BI.

Entonnoirs de vente

Les ventes aux clients ont été effectuées dans Enybox CRM, nous les avons transférées vers amoCRM pour faciliter l'intégration. Nous avons réussi à rassembler la logique de vente en trois entonnoirs.





_{Trois entonnoirs successifs}



Le premier entonnoir est la consultation. J'avais besoin d'amener le client à s'inscrire sur la plateforme. Le deuxième entonnoir fixe les premiers paiements. Ensuite, l'utilisateur a confirmé son inscription. Et nous avons, à notre tour, célébré le moment du paiement et chaque nouvelle reconstitution.

Comment l'analyse était censée fonctionner

Pour que le système d'analyse fonctionne normalement, vous devez collecter tous les événements = marquer les actions de conversion. Les événements sont déjà entrés dans le système d'analyse, mais au départ, il n'y en avait que deux types, ce qui n'est pas suffisant pour les rapports.

Affichage des données

_{Exemple de tableau de bord}



Après avoir collecté des données sur les conversions, il a fallu en faire un rapport. Le principal outil de visualisation des données est Microsoft Power BI.



Au moment de la conversion, un identifiant distinct a été généré sur le site pour synchroniser les systèmes publicitaires et CRM. Par cet identifiant, nous avons lié les données de dépenses et de revenus. Nous avons donc corrélé les données et avons pu créer des rapports à ce sujet.

Économie de l'unité. Rétention

_{Le graphique de rétention glissant du service de 1 à 12 mois de}



rétention montre combien les utilisateurs sont impliqués dans l'application et à quelle fréquence ils y reviennent. Mais en raison du fait que le service fonctionne sous forme de réapprovisionnement, j'ai dû changer cet indicateur en rétention continue. Cela montre la même chose que la rétention, mais implique que tout le temps que l'utilisateur n'a pas réapprovisionné le compte, il a également utilisé le service.

Conversion au premier dépôt

La conversion dépendait fortement du nombre de nouveaux clients et du début de leurs paiements. Au cours des 9 premiers mois, nous avons reçu environ 430 nouvelles inscriptions et 90 paiements de nouveaux utilisateurs chaque mois. La conversion en achat au cours du mois d'enregistrement était de 20%, selon les données de 12 mois.

En plus des indicateurs standards

Il était possible de voir des analyses sur le contact du client à la fois au moment d'une simple transition vers le site, et au moment de l'inscription et des paiements ultérieurs. Nous avons accumulé des données pour trouver le plus de chaînes de conversion: L'



utilisateur a vu la publicité → est allé sur le site → après un certain temps est entré et a cherché dans le contexte → enregistré, mais n'a pas payé → s'est réchauffé avec une lettre → a offert un essai routier → testé → l'OP a «abandonné» pour le premier paiement → 3 ans paiements stables.

Un problème est survenu

Au tout début, les initiateurs du projet ont reporté le démarrage à l'automne (ils ont postulé au printemps). De telles «lacunes» dans le travail se sont produites plus d'une fois. Mais nous n’y avons pas pensé et nous avons pris cela pour acquis. Les principaux problèmes étaient la communication et la bureaucratie dans les processus de nos clients. Voici comment vous pouvez représenter toute la période de travail sur un projet:

Développement lent

La raison des lacunes de conception était la structure de travail du client. Nous avons travaillé avec l'équipe du client et certaines tâches n'ont pu être effectuées que de son côté en raison de la haute sécurité des processus.

A manqué deux sprints - perdu un mois

Tous les managers et développeurs de leur côté ont travaillé en itérations de deux semaines. Mais ils placent constamment notre projet en dernier et souvent nos tâches ne rentrent pas dans le "sprint".

Mauvaise communication et manque d'expertise

Au cours du projet, le responsable du client (partie prenante) a changé cinq fois. Tout le monde connaît probablement ce sentiment lorsque le projet sur lequel vous travaillez devient soudainement inintéressant pour le client. Mais même cela peut être résolu.



Il était plus difficile de gérer l'incompétence des parties prenantes. L'un d'eux était un grand cadre qui connaissait bien son produit. Mais il ne comprenait même pas les principes de base de l'élaboration des processus de vente. Nous avons passé plusieurs réunions pour le persuader de retirer la scène avec le statut "Comment ça va?" De l'entonnoir de vente.



Imaginez un entonnoir de vente comme l'image ci-dessus. À l'une des étapes, les gestionnaires doivent savoir «comment va le client». Selon vous, qu'adviendra-t-il des analyses de conversion de cet entonnoir?



Les managers découvriront «comment allez-vous» auprès du client au lieu de le déplacer dans l'entonnoir, le statut n'est pas anodin. Il n'est pas évident de savoir quand le mettre: après le premier contact ou après la qualification. En conséquence, les offres «sautent» d'avant en arrière le long de l'entonnoir ou se tiennent simplement debout, au lieu d'un mouvement séquentiel.

Pendant le processus de vente, il est impossible de définir des étapes intermédiaires dans lesquelles les transactions vont s'accumuler. Sinon, toutes les analyses se transformeront en désordre et les gestionnaires perdront beaucoup de contacts.

Fakapas de notre côté

Nous n'avons pas pris en compte la bande passante du système. Pour un événement de plate-forme au sommet, nous avons envoyé jusqu'à 10 demandes à amoCRM pour exécuter la logique des processus métier.



100 000 événements par jour * 10 requêtes adressées à amoCRM = 1 000 000 requêtes par jour



1 000 000 requêtes par jour / 10 requêtes par seconde (limite AMO) = 100 000 secondes = ± 27 heures



Résultat: la synchronisation ne s'arrêtera jamais



amoCRM initialement sélectionné, comme "passer" la limite des demandes au système. Mais au cours du développement du projet, les exigences et les fonctions se sont accrues et nous avons "atteint" la limite.

Nous avons choisi le mauvais outil. AmoCRM n'est pas physiquement adapté pour traiter un grand nombre de demandes.

De plus, l'erreur était que nous avons tout développé sur GO, et un spécialiste en était responsable. Quand il est parti, il y avait une montagne de code hérité que personne ne pouvait distinguer. Mais, malheureusement, ou heureusement, cela n’était pas nécessaire.

Tout s'est encore cassé

Ce cas est un autre exemple de projet qui a été enterré dans les approbations et un tas de gestion inutile.



Nous manquions d'expertise technique. Au client - stabilité dans la gestion et désir de mener à bien le projet.



Mais c'est de l'expérience. Grâce à lui, ces tâches semblent désormais aussi triviales que possible, et nous avons déjà reproduit une solution similaire dans un autre projet.

Comment éviter l'échec

Afin de ne pas répéter de tels cas à l'avenir, nous avons mis en évidence les aspects à observer lors du travail avec les entreprises clientes.

1. : ; . , .
2. . — . — . . .
3. . KPI — .
4. Penser à l'avance. Même lors du développement d'un MVP, vous devez examiner les goulots d'étranglement qui pourraient survenir à l'avenir. Le projet est toujours en expansion et il est important de fournir une structure pour ne pas réécrire tout le code à partir de zéro.

---

L'auteur de l'article est Fyodor Anisimov, marketeur LAND PRO.