Accueil > Multicanal > Partie 1 : Méthode Projet pour un « customer Interaction Hub »

Partie 1 : Méthode Projet pour un « customer Interaction Hub »

écrit par

17 mar

Description de la boite de LEGO

Tout d’abord désolé d’être resté 8 semaines sans écrire, mais actuellement le rythme de travail est plutôt élevé et dans une logique orientée client … je me consacre d’abord à mes clients (que je remercie pour l’intérêt des dossiers travaillés). Annick, Kaoutar, Laurence, Marielle, Nadége, Nassima, Sandrine, Stéphanie ainsi que Denis, Gilles, Hassan, Hervé, Marc et Thierry comprendront. Ma gratitude spécifique à Florence et Gaëlle pour l’accompagnement dans la durée sur le projet d’optimisation.

Pour me rendre plus ludique ce document, je vais vous proposer de redécouvrir les plaisirs du LEGO. Au fur et à mesure du texte, vous trouverez des messages FLASH vous permettant de vous remémorer les petits cubes magiques et multicolores. Ce premier article traite de la description des pièces du LEGO Multi-canal, le second abordera les règles de construction.

Actuellement, j’ai la chance de travailler sur un dossier plutôt sympathique d’optimisation multi-canal où j’ai l’opportunité de combiner les bases de données, le data mining et la formalisation de processus. Évidemment, il ne m’est pas possible de dévoiler le contenu et les chiffres, mais il m’a semblé intéressant de formaliser et partager sur le contexte, la démarche, les difficultés rencontrées et d’évoquer quelques solutions mises en œuvre dans la conception du « CIH »..

Le contexte est celui d’une entreprise qui utilise l’ensemble des canaux de communication :

– face à face entre le client dans des logiques de déplacement et d’accueil en point de vente,
– contacts téléphoniques entrants (demandes d’informations) avec un serveur vocal, des numéros dédiés,
– contacts téléphoniques sortants pour des prises de rendez-vous et des ventes à distance,
– contacts mailing et emailing avec une solution sophistiquée de gestion de campagnes,
– automates dans les points de vente pour donner des informations,
– différents sites internet offrant des possibilités de consultation et de transactions en ligne.
Donc, une vraie structure multi-canal qui couvre l’ensemble du territoire français.

Flash 1 LEGO : imaginer que chaque canal puisse se représenter par une couleur !

Évidemment, la coordination entre les canaux est très importante (voire vitale) … pour répondre de manière efficace aux clients mais aussi pour :

– éviter une sur pression marketing (émettre trop de message sur une période courte), – une sous pression (oublier de contacter un client sur une période de temps) ..
– une déperdition de ressources avec un équilibre entre les budgets investis en recrutement et fidélisation … et les retours en terme de ventes et marges.

Point important, le volume des flux d’interactions dépasse le Milliard sur une année…..

Évidemment pour mettre en place les logiques de flux entre les canaux, l’entreprise a mis en place un ensemble de règles « logiques » et « métiers » …du type « si un client positionne une demande de rappel sur le site Web … il faut envoyer le message au centres d’appels ».

Un travail important de formalisation entrepris depuis plusieurs années.

Conséquence : une base de règles métiers très fournie

Pour avoir un système réactif, il est normal de mettre en place une architecture des flux au plus proche du système d’informations. Au fil du temps, les règles « métiers » se développent, s’accumulent avec la croissance des données .. ce qui rend au fil du temps difficilement lisible l’architecture des flux « points à points » (on parle d’architecture spaghetti) ..
Ce type d’applications est difficile à maintenir et faire évoluer (impacts entre les règles) … et carrément dangereuse lors du projet de migration d’un composant … imaginer les risques de changer l’outil de gestion de campagnes sur l’ensemble des flux ?
Pour faire un bon travail d’optimisation, il est d’abord nécessaire de comprendre les applications, les données collectées et stockées, les flux entre les applications et les règles qui organisent et structurent ces flux. Bref un travail de recueil transverse pas facile à effectuer auprès d’interlocuteurs ayant chacun un vocabulaire et des objectifs spécifiques. Une mission d’accompagnement dans le temps … guidée par la disponibilité des équipes internes et la capacité de formalisation du consultant (plusieurs semaines de travail).

Flash 2 LEGO : imaginer une règle comme les conseils d’un expert en Lego : « pour faire tenir un mur de LEGO il faut mettre en décalé les briques de 8 plots !

Une lacune inhérente à ce type d’architecture « réactive » des flux est souvent l’insuffisance des éléments de contrôle et de mesure de l’exécution du processus. Une absence d’élément de contrôles qui par ailleurs empêche une mesure simple de sa performance opérationnelle … et de sa rentabilité finale. Par exemple, actuellement, mes étudiants effectuent des analyses de sites Web et constatent un décalage entre la réception immédiate du « message automatique d’inscription » .. l’absence de réception des News Letters, voire de non prise en compte de leur relance … visiblement le lien entre leur inscription et l’outil d’emailing ne s’est pas effectué (phénomène plus fréquent qu’on ne le pense). Pour corriger ce problème de faiblesse de mesure (en fait l’architecture est construite pour avoir des réflexes .. et parfois assez peu de réflexion), il devient nécessaire de mettre en oeuvre une base de données « centralisée » des contacts, ce que je nomme un « customer interaction hub » pour tracer toutes les flux .. et suivre leur traitement et les résultats obtenus.

Conséquence : une architecture applicative complexe et un méga entrepôt de données.

Dans ce contexte, la première partie du projet consiste à :
– identifier les flux dans cette architecture (tout au moins les flux majeurs),
– identifier et localiser les différences sources de données,
– mettre en place des zones de stockage des résultats de contacts,
– analyser la qualité des données stockées,
– vérifier les possibilités de reconstruire la « chaîne d’interaction »;

Flash 3 LEGO : imaginer qu’il a fallu « retrouver » la notice explicative qui précise le contenu de la boîte de LEGO.

Dans cette phase d’inventaire, on peut rapidement constater que chaque canal stocke des informations … souvent pour son objectif propre :
– suivre le volume des appels,
– suivre l’efficacité des RDV,
– mesurer les retours de campagnes,
– suivre le trafic sur le web,
– analyser les ouvertures de contrats,
… mais chacun a une définition différente d’une action commune. Par exemple, le fait de communiquer avec un client devient selon le canal
– « joint »,
– « argumenté »,
– « vu »,
– « clické »,
– « panier cassé »,
– « en attente de retour des pièces » … .

Conséquence : un vocabulaire, mais une absence notoire de dictionnaire

Dans ce contexte, il a fallu reconstruire un dictionnaire transverse entre les canaux permettant spécifiquement de savoir quel était le niveau d’avancement atteint dans la relation avec le client sur chaque canal. En développant un dictionnaire commun, il devient possible de mesurer et de comparer la performance des canaux. Evidemment chaque canal a ses « spécificités », mais il a aussi des coûts et des charges différentes. La possibilité de « normer » les traitements permet de mieux comprendre et comparer les niveaux de performance.

Comparativement aux outils techniques qui mesurent la quantité des flux (souvent au jour le jour) et la dissocient de la mesure de la qualité (annuellement par des enquêtes) notre approche vise à combiner le « vite » et « le bien ».

Conséquence : un outil de benchmark

La création d’un dictionnaire sur les statuts commun entre les canaux permet de recoder de manière homogène les codes des applications « source ». La notion de « contact non argumenté » s’inscrit dans l’ensemble des canaux en terme de résultat.

Flash LEGO 4 : imaginer que chaque « statut » correspond à une pièce différente du LEGO : une barrette de 8, de 4, un coin, une tuile, etc…

Vous avez maintenant entre les mains une jolie boite de LEGO prête à l’emploi. Le prochain article vous fera découvrir les joies de la construction .. et les premiers écueils.

Pas encore de commentaire

Faire un commentaire