J’avoue que j’ai pas mal cherché avant de trouver les infos qui m’ont permis de réaliser les 1ers tests concluants…

D’abord j’ai naïvemet pensé qu’il suffisait de lier le report au fichier XML en direct, et qu’un fichier XML formaté par access pourrait faire l’affaire pour mes 1ers tests. Grâve erreur, j’ai multiplié les tests foireux…

Mes recherches sur l’aide et dans google m’ont appris les choses suivantes :
1: il faut faire un lien ODBC. Le driver est installé avec Crystal Report et ne peut servir que pour Crystal.
2: il y a des règles pour préparer les fichiers XML… Je m’en serais douté mais je n’imaginais pas au départ qu’un export access au format XML ne ferait pas l’affaire.

Heureusement, après de longueus recherches j’ai trouvé ce document : cr_xml_data_sources.pdf… Merci Crystal, je regrette juste que les explications de ce document ne figurent pas dans l’aide.

Pour la création du lien ODBC rien de bien compliqué. On choisit le driver CR XML, on indique un nom de source de données (le nom du lien ODBC) et on indique le dossier où sont les fichiers XML. C’est ensuite dans Crystal qu’on choisira le (ou les) bon fichiers de données.

Pour le formalisme des fichiers XML j’ai trouvé 3 possibilités.
1- fichier XML le plus simple : on y met les données sans déclarer la structure… C’est le « Raw XML » décrit en page 15 de ce document.

2- Un fichier XML avec les données et le schéma des données. C’est le « ADO XML » décrit en page 16 du document.

3- Un fichier XML avec les données et un autre avec le schéma des données. C’est le « Data Island XML » décrit en page 17 du document.

Pour ma part j’ai testé les 3 solutions présentées. Je les ai testé en Crystal 10 et j’ai obtenu les résultats suivants :

1 : Accès corrects aux données, mais sur un fichier de tests plus volumineux que l’exemple la distinction entre données texte et numérique ne se faisait plus.
2 : Je n’ai pas reussi à accéder aux données… j’ai du faire une erreur quelque part mais je n’ai pas trouvé où…
3 : C’est ce que je vais mettre en place. Les données se génèrent facilement, le schéma des données est à part et tous les formats déclarés sont reconnus sans soucis dans crystal… Le rêve pour moi

Le CTI est un domaine très intéressant, j’ai donc un petit pincement au coeur d’arréter, d’autant plus que j’ai été à l’origine de pas mal de réalisations dans ce domaine. J’espère donc trouver le temps pour rédiger la suite des articles que j’avais prévu à ce sujet. Mais d’un autre côté, après 6 ans à travailler sur le CTI je ne suis pas mécontent de voir d’autres choses et de me changer un peu les idées.

Informations sur le bandeau de TAO

Aujourd’hui avec l’arrivée des technos web pour les logiciels de relation clientèles on trouve de plus en plus de connecteurs CTI qu’il ne reste qu’à paramétrer. Ils ont l’inconvénient d’être moins souples et moins adaptables mais évitent de devoir concevoir une véritable usine à gaz pour garantir la communication d’informations entre CRM et CTI.

Ces connecteurs (celui pour Siebel par exemple, avec lequel j’ai un peu travaillé) sont bien sur facturés au nombre de postes agents. Ils sont assez faciles à installer et à paramétrer pour les fonctions basiques. Par contre, pour des traitements plus spécifiques comme la prise en compte de données d’un SVI ils sont beaucoup moins souples que la technologie que j’utilisais avant : l’activex.

L’activex est très bien quand le bandeau de TAO complète un logiciel de relation clientèle qui fonctionne avec un client lourd (en mode client serveur) par exemple. Il a aussi l’avantage d’être inclus dans l’offre CTI de base de Genesys. Mais on le sait, Microsoft (et Genesys qui est partennaire de Microsoft) tend à abandonner la technologie activex.

Enfin Genesys propose un kit de développement pour platteforme .Net. Ce kit est facturé un peu sur le même principe que les connecteurs. J’avoue ne pas avoir eue l’occasion de le tester.

Je me demande quand même, entre deux solutions facturées de manière comparable, si les entreprises vont faire le choix de continuer à développer en interne. Je n’en suis pas très sur, et je trouve ça dommage car les besoins en matière de traitements d’appels téléphoniques sont très variables d’un centre d’appels à un autre.

Les besoins, eux, peuvent être bien plus complexes. On peut en effet avoir besoin de distribuer l’appel du client en fonction :
– du conseiller qui traite habituellement son odssier
– de la situation de son dossier
– de la demande que va soumettre le client
– de l’endroit d’où il appelle (déterminé par son numéro de téléphone par exemple)
etc etc.

Pour cela il y a 2 solutions :

– Le routage interractif
– Un SVI.

Le principe du routage interractif c’est que l’appel n’est pas directement distribué par le PABX. Celui-ci envoit une demande de routage au CTI et c’est le CTI qui va décider de la ressource vers laquelle il faut envoyer l’appel. Pour cela il dispose des informatons classiques d’une application CTI :
– numéro de téléphone du client
– numéro appelé par le client
– temps d’attente depuis que l’appel est arrivé sur le PABX

Avec ça il n’y a qu’à appeler des procédures / programmes externes et de tenter d’identifier le client. Le routage interractif est intéressant quand on veut transmettre l’appel au conseiller habituel du client, ou envoyer l’appel au service le plus compétent en fonction de l’état du dossier du client (au contentieux si il y a un problème sur le dossier par exemple).
La limite de ce type de routage est le taux de reconnaissance du client. Pour que ce soit efficasse la base de données clients doit être à jour en ce qui concerne les coordonnées téléphoniques.

Le SVI (Serveur Vocal Interractif) offre, à mon avis, un peu plus de possibilités. Au fil des questions / réponses le client va s’identifier et exprimer son besoin. Ensuite, comme pour le routage interractif, et en fonction des données du dossier du client il sera possible de déterminer le meilleurs moyen de distribuer l’appel. Là on sera sur d’identifier le client et de traiter au mieux l’appel. Cerise sur le gateau, il sera peut être possible de traiter la demande du client de manière automatique, sans faire appel à un conseiller.

Par contre certaines personnes sont assez hostiles quand au fait d’être mises en relation avec une machine. Il est nécessaire de connaitre la population concernée avant de se lancer dans la mise en place d’un SVI.
De plus il ne faut pas oublier de correctement dimensionner le SVI sous peine de perdre des appels.

Enfin, signalons qu’il est possible de coupler SVI et routage interractif. La mise en place d’une telle solution ne se fait que pour des cas où les règles de distribution des appels sont très complexes.

N’hésitez pas à faire part ici de vos expériences.

Pour ma part j’ai travaillé dans un contexte appels uniquement. Le middleware Genesys facilité beaucoup le travail de mise en place de CTI dans un centre d’appels mais nécessite une attention accrue tant il offre de possibilités… La phase de configuration est primordiale.

En ce qui concerne la partie TAO pure je dois avouer que ce genre de projet est un vrai bonheur, je me suis litéralement amusé à développer, puis à enrichir fonctionnellement et techniquement cette application.

Le positif :
– La sécurité a été revue : plus de passage en mode intranet automatique, besoin d’activer des composants flash, anti popup (enfin…)
– Les onglets sont faciles à utiliser. C’est un peu au dessus (fonctionnellement) des 1ers Firefox. Normal, même Firefox a évolué depuis. La mosaïque, en particulier, disponible sur Firefox en extension, est présente dès le départ sur IE.
– La gestion des flux RSS est bonne et intuitive
– L’intégration d’autres programmes tels ICQ, Live Messenger, les utilitaires Bluetooth est aussi un plus.
– On ne peut pas mettre autant de plugins que dans Firefox, mais les fonctionnalités fournies de base sont suffisantes à mon avis.

Pour résumer, c’est enfin un IE qui me convient, car la navigation par onglet est pour moi un critère très très très important, et le comportement « confiant » qu’avait IE 6 me génait énormément. Encore quelques améliorations dans la gestion des onglets et ce sera très bien. Après ça, le choix sera plus compliqué à faire entre IE et Firefox…