Avant d’intégrer des fonctions Web à un centre d’appels existant, il est nécessaire d’effectuer quelques vérifications. On dénombre quatre points principaux d’interaction stratégique. Un centre d’appels traditionnel est composé de postes de téléconseillers (ordinateur et téléphone), d’un autocommutateur ou distributeur d’appels (PABX et ACD), d’un middle- ware CTI et d’applications métiers qui enregistrent les transactions réalisées par les clients.Un centre plus évolué contiendra aussi un moteur de routage d’appels, un serveur vocal interactif (SVI), un numéroteur (ou dialer) pour les appels sortants, une base d’historiques des contacts clients, et des scripts guidant pas à pas les téléconseillers lors des appels. Ces deux derniers éléments proviennent souvent d’un progiciel CRM.Le premier point d’interaction porte sur la gestion des disponibilités des téléconseillers. Le serveur de médias Web (tels le chat ou l’e-mail) gère les disponibilités indépendamment des contacts téléphoniques. Car c’est l’ACD qui route ce type d’appel.Dès lors, comment éviter les collisions entre téléphone et e-mail, par exemple ? Techniquement, certains injectent toutes les demandes de contact dans les ACD à condition qu’ils gèrent des files virtuelles où l’on insère des appels fictifs. On peut aussi gérer la distribution d’appels téléphoniques par le middleware CTI. Enfin, on peut développer un module qui modifie la disponibilité du téléconseiller vis-à-vis de l’ACD avant qu’il ne ” décroche ” un contact e-mail.Le deuxième point concerne l’interfaçage du module de routage des contacts Web avec d’autres systèmes d’information. Classiquement, le routage des contacts Web n’analyse que les informations présentes dans les contacts Web. Il examinera, entre autres, l’objet d’une session chat ou d’un e-mail.
Un client appelant pour la deuxième fois sera prioritaire
Il faut vérifier qu’il est possible d’interfacer le routage avec un autre système tel qu’une base de données externe. Cela lui permettra, en interrogeant cette base, de détecter, par exemple, qu’un client a déjà eu un contact téléphonique le jour même et de lui donner une priorité. La mise à jour d’une base de contacts clients existante doit aussi être possible.Le troisième point concerne la synchronisation des différentes bases de contacts clients présentes dans le centre d’appels. Si la solution de Web call center envisagée contient sa propre base de contacts clients et qu’une autre base CRM est déjà exploitée, alors il faudra les intégrer. L’application du téléconseiller devra absolument afficher la liste des contacts avec le client tous médias confondus. Le même besoin existe aussi pour le reporting.
Quelle méthode pour une liste exhaustive des contacts ?
Trois solutions sont généralement envisageables. L’application disponible sur l’écran du téléconseiller interroge les deux bases. Cela n’est guère performant.Autre approche traditionnelle : la réplication de nuit, une de plus, entre les différentes bases. Cette méthode a un inconvénient majeur. Si elle est effectuée toutes les vingt-quatre heures, le client qui envoie un e-mail et qui rappelle l’après-midi, va devoir réexpliquer le contenu de son e-mail ! On peut aussi installer un serveur de couplage ou, sous certaines conditions, des triggers dans la base de contacts du Web call center. Dès qu’un contact est ajouté dans cette base, la base du progiciel de CRM existant se voit automatiquement mise à jour.Le quatrième point concerne l’intégration de la fonction Callback (appel de l’internaute par le centre d’appels) disponible sur certaines pages Web du site de l’entreprise. Si le centre d’appels contient déjà un dialer, alors l’intégration est native. Il suffit de rajouter dans le site Web un formulaire qui déclenchera l’ajout d’une ligne dans la liste des personnes à rappeler. Si le serveur de routage (côté CTI ou côté Web) offre une interface pour ” injecter ” les appels de futurs nouveaux médias, c’est une solution pour les callback immédiats en preview. Sinon, il vaut probablement mieux acheter un dialer… Par ailleurs, afin de simplifier la qualification des contacts issus du site Web avant leur routage, le mieux est d’ajouter des formulaires qui structureront et standardiseront les e-mails et les demandes de chat, notamment. Par exemple, plutôt que de fournir juste une adresse e-mail, le formulaire demandera de préciser le numéro client et de choisir le motif du contact dans la liste définie en plus du champ Objet d’e-mail.Un paramètre critique concerne la sécurisation des échanges en mode Chat et lors de la conavigation. Si la sécurité est réellement un enjeu important, il faut prêter attention aux capacités du produit à chiffrer les sessions de chat et de conavigation. Il existe aussi une difficulté technique à assurer la conavigation sur les pages Web dynamiques intégrant des scripts, des applets, de l’ASP, du PHP, ou du ColdFusion. La majorité des pages étant dynamiques, la conavigation sur ces dernières n’est pas toujours aisée et peut ne pas être supportée par l’éditeur de la solution Web call center.
Avec le tout-logiciel, l’intégration est native
Enfin, il se peut que le centre d’appels existant soit basé sur une architecture tout logiciel dont les modules PABX et ACD possèdent un niveau d’abstraction élevé vis-à-vis de la téléphonie. Dans ce cas, l’intégration de nouveaux médias sera native : le même PABX gère la commutation de la téléphonie, des sessions chat et de la conavigation. Le même ACD gère la distribution des contacts téléphone, chat et e-mail. Il n’y a alors plus de questions à se poser sur la gestion des disponibilités vis-à-vis des médias différents.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
