Quand la data part à la pêche aux clients rentables (avec la finance)

-70.000 av. JC.

Vous êtes chargé(e) par votre tribu affamée et peu végétarienne d’aller pêcher du poisson. Au bord du lac et armé(e) de votre canne à pêche en bambou vous vous rendez compte rapidement qu’il y a 4 types de poissons définis par deux caractéristiques: leur poids - petit ou gros - et leur férocité: ils sont soit faciles à pêcher car dociles ou longs à pêcher car plein de fougue.

Naturellement le rêve ce serait de pouvoir identifier les gros poissons dociles; utiliser le bon appât et récolter des kilos de viande en peu de temps. Vous seriez bien heureux car vous auriez utilisé votre temps efficacement et pourriez vous concentrer sur des activités plus épanouissantes comme la philosophie.

Cela dit, vous n’être pas trop optimiste et vous vous dites qu’il est encore acceptable de passer peu de temps pour chaque petit poisson; ou beaucoup de temps sur un gros poisson.

En revanche, passer des heures sur un petit poisson, pas question car l’effort déployé est loin d’être proportionnel au résultat obtenu.

Par chance, vous avez découvert la logique mathématique l’avant-veille (oui on peut dire que vous êtes un innovator) et vous décidez de formaliser cette pensée en un tableau de satisfaction, positive ou négative en fonction du temps passé à la pêche d’un poisson et ce qu’il vous rapporte en viande:

Votre objectif, c’est de maximiser votre satisfaction d’après-pêche (et nourrir la tribu).

Votre difficulté, c’est trouver un moyen de repérer les gros poissons dociles. Cela n’est pas aisé car les apparences sont trompeuses: un requin peut avoir l’air tranquille jusqu’à ce qu’il morde à l’hameçon pendant trois jours et deux nuits ; tandis qu’un plan d’eau agité et opaque vous déformera la taille de ce qui s’y cache dessous.

Et la rentabilité d’un client, c’est aussi une histoire de pêche à la ligne.

‍

A l’instar de la fougue du poisson, la rentabilité d’un client n’est pas un état de fait évident

En entreprise, c’est la même difficulté que rencontrent les équipes quand elles veulent estimer la rentabilité d’un client. On a une vague idée de ce qu’est un client rentable mais on ne sait pas dans quelle mesure il l’est !

• “Savons nous précisément ce que nous rapporte ce client chaque mois par son abonnement ?”
• “Avons-nous vraiment pensé à prendre en compte tous les coûts directement liés au service de ce client ce mois-ci ?”
• “Avons-nous moyen d’accéder à ces informations et de les mettre en relation pour prendre une décision ?”

Les réponses à ses questions ne sont pas aussi évidentes qu’on voudrait bien l’imaginer car il y a des inconnues dans notre équation, beaucoup d’hypothèses ou encore quelques silos entre équipes à déconstruire. Bref, il s’agit de construire un modèle à partir de ce que l’on possède comme données et un modèle est par définition imparfait.

La dernière interrogation nous intéresse particulièrement car c’est celle à laquelle l’équipe data répond le mieux grâce à au savoir-faire technique dont elle fait preuve, et dont le meilleur représentant est sans doute le SQL. C’est ce langage qui lui permet de récupérer les précieuses données générée par l’entreprise, les filtrer et les croiser par des calculs qui nous donneront une meilleure idée de la réalité économique d’un client.

1.5 min

Tous les clients ne sont pas (économiquement) égaux

Mettons nous désormais dans la peau d’un service client d’une boîte qui automatise la génération de fiches de paie pour les employés d’entreprises qui ne veulent pas perdre de temps tous les mois à s’en occuper. Le service fonctionne par abonnements dont le prix est proportionnel au nombre d’employés. Un gros poisson c’est donc une entreprise cliente qui a beaucoup de clients, car elle paie plus cher.

Notre pêcheuse ce sera Alice, elle est à la tête du service client. Parfois on dit “Customer Service” (CS) pour désigner ce département qui est chargé de répondre aux problèmes des clients.

Prenons, Marin le responsable Resources Humaines de Fishtown Analytics, une entreprise cliente de ce service de génération de fiches de paie*.* Il veut ajouter un bonus en fin de mois à un employé dont la fiche de paie a déjà été générée, mais il n’y arrive pas. Il écrit donc par mail au service client qui va assigner le problème, autrement appelé “ticket”, à Léo un Customer Care Representative (CCR) qui prendra le temps de résoudre le problème.

Ce temps de résolution,  il a un coût !

Dans un scénario simplifié on aurait:

• Temps de résolution du ticket: 15 heures
• Total d’heures travaillées par Léo ce mois-ci: 150 heures
• Son salaire mensuel brut: 2500€
• Abonnement mensuel de Fishtown, ou revenus générés: 150€

Le coût de résolution du ticket est égal à : (15h /150h) x 2500€ = 250€

Résultat (marge brute): 150€ - 250€ = -100 €

Autrement dit en pourcentage (Taux de marge brute): (150€ - 250€) / 150€ = -66%

Conclusion: chaque euros investi pour servir ce client nous fait perdre 66 centimes; ce client nous coûte plus cher qu’il nous rapporte !

3mins

Oui, et l’équipe data dans cette histoire ?

Alice se dit que l’équipe finance aura probablement tout ce dont elle a besoin; elle possède les heures passées à résoudre les tickets et la finance possède les revenus des clients et leurs autres coûts.

C’est vrai, sauf que les données sont stockées un peu partout. Les heures résident dans un logiciel de résolution de tickets, par exemple un Customer Relationship Manager (CRM) comme Salesforce. Les revenus sont stockés dans la solution de facturation gérée par la finance tandis que les salaires des CCR cachés dans des excels restreints d’accès.

Pour orchestrer tout ça, les deux équipes pensent aux data analystes qui ont l’habitude d’agréger automatiquement des données diverses pour les présenter rigoureusement dans un outil de visualisation accessible à toute la boîte.

La force de la data c’est de créer un système robuste de calculs standards qui évite aux équipes de faire des exports et formules excel infinis. On évite ainsi les erreurs humaines de manipulations trop manuelles et on assure une fiabilité et régularité d’alimentation en données. Rien que ça.

Excel vs. SQL; les mêmes formules dans un système différent

Quel est le résultat souhaité ?

Assis à la même table digitale, il est désormais temps de parler du résultat souhaité. Lors de cette réunion les data-analystes vont chercher à comprendre le contexte, identifier le besoin et valider l’intuition d’Alice (notre responsable du service client) : oui c’est bien un use-case pour la data !

Repérer nos 4 types de poissons se traduit en : “identifier la rentabilité de chacun de nos clients par mois selon le modèle qui sera élaboré entre le Service Client, la Finance et la Data.”

Une ligne par mois et client. Des colonnes pour les coûts, revenus et la marge brute en pourcentage

4 mins

Qui fait quoi ?

La répartition des rôles par domaine d’expertise permet de maximiser leur impact: le CS partage son expertise métier (quel demande demande quel temps par exemple), la finance élabore le modèle de coût (comment repartir les salaires des équipes à travers chaque client par exemple) et la data ses outils techniques (son SQL, sa connaissance des bases des données, ...).

Le Customer Service:

• explique la situation et son besoin en données pour identifier la rentabilité des clients en fonction des heures passées à résoudre des tickets.
• précise quelles données il faut utiliser pour connaître le temps de résolution d’un ticket client

La finance:

• décide des coûts liés au service à prendre en compte dans la réalisation du modèle.
• fournit les hypothèses du modèle (comment répartit-on les coûts mensuels sur les clients ?)
• fournit en fin de mois les données de coûts sommés par catégorie et par mois dans un Excel accessible aux data engineers, il devra être rigoureusement maintenu.

La data:

• s’assure que les données “métier” (CS) sont correctes et disponibles dans notre base de données
• décide d’un système de tables SQL en concertation avec les analytics-engineers qui s’occupent entre autres de standardiser et optimiser les calculs pour les data-analystes
• rédige le “code” SQL qui va nous donner la table de marge brute client
• réalise un dashboard avec les visualisations clefs définies avec les équipes utilisatrices du dashboard.
• réitère pour préciser les éléments du modèle s’il n’est plus convenable.

5 mins

Une fois les spécifications du modèles mises par écrit on peut commencer à implémenter notre système de calcul. Si vous êtes curieux du modèle lui-même. Sachez qu’il n’est pas si compliqué; le principe général consiste à prendre chaque total de coût et le répartir sur les clients qui sont concernés. On soustrait le revenu de notre client à ses coûts et on obtient une rentabilité brute. En le rapportant à son revenu on peut ensuite comparer en pourcentages les clients entre eux.

‍

Techniquement que se passe-t-il au sein de la data ?

#1 Les data-engineers récoltent les données à leurs sources

Schématiquement on peut dire que les data-engineers assurent la bonne ingestion des données dans la base de donnée. Il faut que tous les matins les analytics-engineers et data-analystes puissent consulter et utiliser dans leur base de donnée les informations que nous allons utiliser dans notre modèle.

Si le flux s’interrompt un jour, c’est tout le modèle qui devient inutilisable !

#2 Les analytics-engineers et data-analystes traduisent les calculs du modèle en requête SQL

Quand on arrive ici le plus dur est fait. On a aligné les équipes et récolté les données; il ne reste plus qu’à les réconcilier en SQL via quelques jointures pour obtenir une table intermédiaire à partir des trois sources.

‍

Exemple de requête SQL qui permet d’obtenir de réconcilier 3 sources de données (CS, Finance, Data)

La façon d’écrire le SQL ne sera pas détaillée aujourd’hui mais sachez simplement que c’est une tâche partagée entre data-analystes et analytics-engineers. Ces derniers sont à la croisée des rôles de data-engineers et de data-analystes; ils s’occupent par exemple de fournir des outils de développement de code aux data-analystes.  Ils élaborent des tests pour ne pas introduire de bugs, documentent les données sur les données-mêmes (”métadonnées”) et en aident à l’écriture de SQL optimisée et complexe.

6 mins

#4 Visualiser la donnée

Parfois les équipes sont assez autonomes pour ne vouloir que les données brutes, mais c’est plutôt rare car la visualisation correcte et efficace de la donnée est aussi une compétence forte de l’équipe data.

Le résultat c’est celui annoncé: une ligne par client, par mois et sa rentabilité affichée en pourcentages. Le premier réflexe: trier par ordre décroissant. Et hop on a les clients les moins rentables en haut de liste: nos fameux petits poissons fougueux.Pour ceux-là on comprend que les heures passées à résoudre leurs problème n’est pas du tout compensée par les revenus qu’ils génèrent.

Le second réflexe ce serait voir ce qu’il se passe si on les triait par caractéristique: par exemple par total d’employés, par pays ou par secteur d’activité. Avec différentes vues on comprend différemment la réalité de notre service: peut-être que les gros poissons sont une très mauvaise idée finalement car ils sont en moyenne beaucoup plus fougueux: est-ce que pêcher un thon rouge infatigable est vraiment plus efficace que de pêcher 1000 crevettes ?

Ici une illustration de groupements de clients par taille; on peut immédiatement comparer les taux de marge brute

Une fois en possession de notre table, un champs infini de possibilités s’offrent à nous en termes d’affichage et d’analyses; ce sont les équipes qui exprimeront leurs besoins en données plus particuliers.

Exemple de dashboard qui donne à plusieurs échelles

7 mins

L’après-projet

Une fois les données modélisées et visualisées, l’équipe data a la responsabilité de communiquer précisément le résultat et d’adapter le modèle dans le cas où les entrées du modèle venaient à changer: par exemple si un coût devait être ajouté au modèle.

Enfin l’équipe data ne livre pas de la donnée tel un journal au pied d’une porte: elle doit guider son utilisateur final avec empathie car si elle connait son sujet par coeur, ses sources et formules, ça n’est pas le cas d’un utilisateur lambda qui rencontrerait pour la première fois la notion de taux de marge brute.

La data en support des équipes métier

Comme on l’a vu le besoin émane des équipes métier, expertes d’un sujet particulier. Elles ont des intuitions et veulent les valider par une donnée enrichie par des calculs automatiques. Toutefois ces équipes seules n’ont pas forcément les outils adéquat pour obtenir de la donnée fiable et actionnable.

Dans ce cas précis faire appel à l’équipe data est une bonne idée. Elle va mettre à disposition ses données stockées en base, son langage de calcul le SQL et ses outils de visualisation pour répondre au besoin.

Comme à la pêche, on ne peut pas efficacement attraper les meilleurs poissons sans cannes à pêche taillées par des artisans passionnés ou quelques bonnes techniques de grand-père.

Par ailleurs, plusieurs alumni DataBird ont choisi de devenir pécheurs au service de la finance. Leurs articles sont disponibles sur le blog.

Je souhaite en savoir plus

Article de Victor Ronchin, 24/03/2022, Paris

‍