L'expérience de CrunchTime avec le service Help Desk Migration

Publié par Anastasia Savelieva

Mise à jour le 6 janvier 2025

1995

établi

170

employés

USA

emplacement

À propos de CrunchTime !

CrunchTime! a créé le premier système de gestion de restaurant en ligne. Depuis, les plus grandes enseignes mondiales, représentant des dizaines de milliers de restaurants, ont choisi CrunchTime comme solution de gestion intégrée, et elle est aujourd'hui considérée comme la référence du secteur.

CrunchTime emploie environ 170 personnes à temps plein et son siège social est situé à Boston, dans le Massachusetts, aux États-Unis.

CrunchTime est un logiciel de gestion de restaurants qui optimise les opérations liées à l'alimentation et à la main-d'œuvre. Notre solution de gestion administrative intègre tout ce dont vous avez besoin pour réduire les coûts alimentaires et de main-d'œuvre, améliorer l'expérience client et augmenter les profits dans tous vos restaurants.

Comment avez-vous trouvé la migration de données avec notre service ? Le processus a-t-il été source de confusion à un moment ou un autre ?

Nous avons examiné plusieurs solutions de migration et avons testé chacune d'elles afin d'évaluer leurs fonctionnalités. Help Desk Migration (HDM) s'est avérée la solution la plus performante. Son Help Desk Migration résidait dans la possibilité de migrer automatiquement toutes les pièces jointes, sans effort supplémentaire de notre part. Aucune des autres solutions testées n'offrait une telle fluidité.

Nous avons examiné plusieurs solutions de migration et avons constaté que Help Desk Migration offrait la solution la plus performante.

Glenn Evershed, responsable de programme chez CrunchTime

Le principal avantage de notre collaboration avec HDM a été leur capacité à travailler avec notre équipe pour personnaliser certains aspects de notre migration (un investissement plus que justifié) qui n'étaient pas inclus dans la solution standard. Nous disposions de données existantes dans Team Support que nous devions mapper vers des champs personnalisés spécifiques dans Zendesk , et HDM s'est montré très disponible et à l'écoute pour accompagner notre équipe dans la résolution de ces problèmes de transfert de données de Team Support vers Zendesk.

L'interface de migration était relativement simple, mais quelques points ont prêté à confusion, notamment le mappage et l'association de certaines données entre les deux plateformes (sans lien avec HDM). En effet, le vocabulaire et les flux de travail de l'équipe d'assistance différaient suffisamment de ceux de Zendesk pour engendrer des malentendus. Grâce à l'aide directe de l'équipe HDM et de notre responsable de compte, toujours disponible pour répondre à nos questions et nous assister, tous ces problèmes ont été résolus.

Quelles étaient les raisons qui ont poussé votre entreprise à changer de service d'assistance ?

En 2005, Crunchtime utilisait une database MS Access pour suivre toutes les demandes d'assistance et les requêtes, lorsque nous avons déployé Salesforce et exploité l'outil de support intégré que CrunchTime a pu utiliser avec succès pendant environ 10 ans.

Nous avons commencé à envisager une solution différente lorsque nous avons étudié les fonctionnalités multicanaux, notamment la création d'un portail client. Salesforce exigeait une licence pour chaque client du portail et, après analyse du rapport coût-bénéfice, nous avons conclu que l'intégration de notre communauté de clients, conformément à nos besoins, nous obligerait à consacrer l'intégralité de nos bénéfices nets à Salesforce.

Nous avons évalué plusieurs solutions et avons opté pour TeamSupport car il s'agissait d'une entreprise relativement jeune, dont l'évolution nous rappelait celle de CrunchTime une décennie auparavant. Nous étions très optimistes quant aux capacités TeamSupport en tant que plateforme de support multicanal. Cependant, nous avons constaté que cette solution ne répondait pas à tous nos besoins en termes de fonctionnalités.

Nous avons collaboré avec TeamSupport pendant environ 18 mois avant de décider de rechercher une autre solution. Dans le cadre de notre appel d'offres, nous avons évalué 12 autres solutions de support et réalisé une analyse approfondie de toutes leurs fonctionnalités, en tenant compte des retours d'expérience internes. Notre choix s'est finalement porté sur Zendesk et ServiceNow , et nous avons opté pour Zendesk.

Pourquoi aviez-vous besoin des historiques d'assistance dans le nouveau centre d'assistance ?

Nous disposions d'une quantité considérable de données historiques, incluant toutes les demandes d'assistance et de développement de nos systèmes précédents. Nous ne souhaitions perdre aucune de ces données, dont une grande partie avait déjà été résolue ou intégrée à notre cycle de développement, puis conservée pour un examen ultérieur ou priorisée pour une version future.

Pouvoir facilement consulter son parcours et ses expériences permet de tirer des enseignements précieux de l'expérience acquise au sein de l'organisation, tout en transmettant une expérience fondée sur les données et moins axée sur les intérêts particuliers.

Nous disposions également d'une quantité importante d'informations corrélées à d'autres systèmes utilisés, tels que JIRA dont la perte aurait limité les informations et le contexte associés.

Quels conseils pouvez-vous donner à ceux qui se préparent également à migrer leurs données vers un nouveau service d'assistance ?

Assurez-vous de bien déterminer le débit et la capacité des appels API avec votre solution actuelle, car les données que vous pouvez charger sur une plateforme peuvent être très différentes de celles que vous pouvez récupérer. Cet aspect aura l'impact le plus important sur la migration de l'historique des tickets actifs et des tickets historiques. Nous avons estimé à environ un demi-million le nombre d'appels API nécessaires pour migrer nos données. Zendesk autorisait 700 appels API par minute (42 000 par heure, soit 1 008 000 par jour) pour transférer nos données vers sa solution, tandis que notre plateforme actuelle n'en autorisait initialement que 5 000 par jour.

Nous avons dû demander une augmentation du nombre d'appels, passant de 5 000 à 10 000 appels par jour (3,5 par minute), puis nous avons finalement obtenu une augmentation jusqu'à 20 000 appels par jour (14 appels API par minute). La migration de nos données de tickets en production a pris environ trois jours, et l'extraction de nos données historiques depuis Team Support a nécessité environ un mois.

Lors de la configuration des connexions de migration HDM avec les plateformes de support, veillez à créer des comptes d'administration génériques afin que les comptes d'utilisateur créés ou les comptes d'utilisateur de configuration associés ne soient pas spécifiques à un individu.

Les leçons tirées spécifiquement de la migration vers Zendesk sont les suivantes :

1. Avant la migration, il est impératif de nettoyer les associations et affectations de tickets existantes aux personnes qui sont des agents à part entière, ou de réaffecter tous les tickets historiques à un utilisateur administrateur générique pour toute personne qui ne sera pas un agent à part entière dans Zendesk car cela causera des problèmes pendant la migration.
2.  Chaque migration (si elle est séparée en raison de la situation décrite ci-dessus) affectera automatiquement tous les agents à tous les groupes, ce qui nécessitera un nettoyage manuel. Cette opération est simple, mais elle affectera les notifications automatiques, car il faudra les désactiver afin que tous les agents ne soient pas informés de la création de tous les nouveaux tickets associés à différents groupes.
3. Veillez à spécifier le groupe par défaut approprié lors de la configuration afin de faciliter l'identification des groupes auxquels appartiennent les agents. Pour les agents appartenant à plusieurs groupes, documentez les exceptions afin de simplifier leur gestion après la migration.