Written by Nous l’attendions depuis plusieurs mois, ça y est la publication commandée par la direction de l’innovation du Ministère de la Culture est paru : un guide pratique, assorti d’un « état du marché », pour les projet de déploiement d’un projet de CRM (customer relationship management) ou GRC (gestion de la relation client / spectateur / visiteur / usager).
Nous avons pu modestement contribuer à travers un témoignage des usages de notre secteur. Nous avons certaines réserves sur le document et son annexe dont nous pourrons discuter dans le groupe de travail privé dédié au CRM sur notre site.
Cette somme de 45 pages + annexes vous permettra de vous plonger dans le sujet, comprendre les enjeux, les prérequis et envisager la pertinence d’un véritable projet CRM. A ce sujet, nous proposons cet extrait qui rappelle la distinction entre les logiciels de billetterie « augmentés », les outils marketing connectés… et un véritable CRM. Mais qui souligne aussi l’importance de définir ses besoins et moyens avant de se lancer.
Certains éditeurs de billetterie ont progressivement simplifié leur système, l’ont ouvert et complété en apportant des fonctionnalités liées à la GRC comme le contrôle d’accès, le comptage, l’accueil, la jauge de sécurité, les canaux de vente, de promotion, de diffusion d’information, etc. La billetterie est devenue un espace de collaboration entre les différents services : accueil et information, sécurité (par la gestion des flux de personnes), service culturel ou d’exposition (programmation), caisses et contrôle, gestion des recettes et comptabilité, service, promotion (fidélisation, campagnes marketing, tarification dynamique, etc.), service informatique (interfaces, rationalisation du système d’information).
Néanmoins, ces solutions de billetterie augmentée n’offrent pas le même niveau de services qu’un système de GRC. Elles restent régulièrement limitées aux fonctionnalités transactionnelles et offrent peu de leviers permettant la création d’une « relation ».
Selon les besoins de l’institution, sa maturité sur ces questions et les moyens dont elle dispose, il peut s’avérer pertinent de s’intéresser à ces solutions mixtes ou de synchroniser un projet de billetterie et un projet de GRC.
Enfin, nous reproduisons quelques recommandations issues de la synthèse du guide (p.44) qui, pour certaines, sont au cœur même de nos approches. Le TMNlab et ses groupes de travail favorisant les échanges entre pairs sont un outil à votre service pour déployer vos projets numériques de façon plus solide.
Échangez à l’extérieur.
Il faut rencontrer d’autres institutions, rencontrer les éditeurs, rencontrer des acteurs d’autres secteurs, etc. pour identifier les bonnes pratiques mais également les écueils.
Mobilisez en interne.
Sans sponsor impliqué, sans directions métiers mobilisées,
sans direction informatique ou numérique engagée, sans utilisateurs impliqués dans la conception du système, il est difficile de conduire un projet de GRC. Partager une définition commune d’un outil de GRC, une même vision des objectifs et identifier collectivement la valeur apportée est un des facteurs de réussite.
Ne négligez pas la dimension RH de la conduite du changement.
Il n’est pas difficile de trouver un outil répondant aux besoins identifiés. En revanche, dans la mesure où un projet de GRC induit de nouvelles procédures et donc de nouvelles manières de travailler, l’un des véritables enjeux est de rapprocher l’organisation de l’outil et de transformer les pratiques.
Il est essentiel de mener au préalable un travail sur la qualité de ses données.
Le travail de reprise et de mise en qualité des données préexistantes et la mise en place des nouvelles procédures de collecte sont critiques pour la réussite du projet.
Il faut accepter une nécessaire transformation de ses pratiques, réadapter sa manière de travailler au fonctionnement standard de la solution choisie.
Limiter les développements spécifiques : trop de spécificités rendent le système coûteux, complexe, peu évolutif et in fine impossible à maintenir.
(NDLR : d’où l’importance de choisir un outil adapté à sa réalité et de travailler avec d’autres utilisateurs de la solution pour obtenir des évolutions mutualisées dans le cœur de l’outil, pas des développement sur mesure qui le complexifie structurellement)