Le CTI et le développement TAO avec Genesys et Alcatel

Genesys propose entre autre un SDK et un connecteur pour réaliser l'intégration des fonctions CTI.

Quel plaisir quand on a le choix. Mais parfois il est dicté par la technologie du logiciel de vente / gestion de la relation clientèle.

Quand j'ai commencé à travailler sur le CTI il s'agissait de faire un couplage Genesys / Vantive. Vantive fonctionnait (le produit a disparu) sur une technologie client serveur avec un client lourd. Les deux solutions étaient donc aisées à mettre en place. Comme à cette époque (c'était en 1998) le CTI commençait à faire son apparition, les connecteurs n'étaient pas encore jugés assez complets et c'est le choix d'un développement Delphi qui a été fait.

Il y a deux ans il a été décidé d'abandonner Vantive au profit de Siebel. La question développement ou connecteur s'est donc à nouveau posée. Mais cette fois ci il a bien fallut tenir compte de l'historique, les conseillers étant habitués à l'ergonomie du bandeau de TAO et nous à une certaine souplesse dans le traitement des données CTI.

Dans un tel contexte il est naturel de commencer par regarder le connecteur Genesys / Siebel. L'intégration des fonctionnalités CTI entre un bandeau de TAO stand-alone et un browser web utilisé en client léger devient en effet vite assez complexe à étudier et il y a de forts risques que cela donne naissance à une véritable "usine à gaz" ne serait ce que pour les fonctions de base du couplage téléphonie informatique.

Mais si l'utilisation du connecteur pour assurer les échanges Genesys / Siebel a semblé s'imposer de lui-même il nous restait quelques points sur lesquelles on se posait des questions :
- l'ergonomie du connecteur ne nous satisfaisait pas à 100%
- le traitement d'évènements et/ou de données téléphoniques spécifiques à notre centre d'appels étaient impossible

Il faut en effet savoir que les connecteurs sont en plein développement. La particularité de ceux disponibles pour Siebel / Genesys (en tous cas pour les versions qui étaient disponibles en 2004) est de gommer les singularités des PABX utilisés. Donc seules les fonctionnalités 100% standard sont supportées, ce qui nous gênait dans une certaine mesure pour exploiter pleinement les fonctionnalités de notre PABX Alcatel.

La solution retenue a donc consisté en un mix connecteur / développement interne. Le connecteur a été mis en place afin de permettre une transmission aisée des évènements CTI de base à Siebel (début et fin d'appels, connexion et déconnexion des agents etc etc...). Alors que le bandeau préexistant et développé en Delphi a pris en charge la partie IHM avec l'affichage des données spécifique à notre centre d'appels, la gestion de fonctionnalités téléphoniques spécifiques à Alcatel ainsi que le formatage de données attachées à l'appel.

Cette solution nous a été d'autant plus profitable qu'une partie fonctionnelle spécifique à nos besoins est toujours traitée dans un bandeau de TAO développé entièrement en interne. Ces traitements auraient été possibles en faisant des scripts dans Siebel mais nous y avons vu plusieurs inconvénients :
- On se serait écarté des standards Siebel pour l'intégration Genesys et cela aurait compliqué les travaux de montée de version
- Les évolutions CTI (dont on sait sur nos plateaux d'appels qu'elles doivent être traitées rapidement) auraient été ralenties par la complexité des procédures de développement et de mise en production Siebel (qui a des contraintes de projet très fortes chez nous).

Entre les versions 5 et 7 de Genesys on note l'accent mis sur la haute disponibilité des serveurs de CTI mais aussi sur la possibilité de gérer des centres d'appels en multi-site. Pour y parvenir Genesys gère le TServer (pièce principale de la solution CTI Genesys) au niveau du serveur de configuration.

En toute logique le bandeau de TAO en fera autant, il ne se connectera pas directement au TServer mais passera par le serveur de configuration et grâce à un nom d'application qui lui sera propre déterminera le TServer qui sera utilisé et sur quel port. Cela permettra d'obtenir les avantages suivants :
- il suivra la gestion haute disponibilité si celle-ci a été mise en place sur les serveurs
- les changements d'installation des différents TServer pourront être effectués sans se soucier de changer quoi que ce soit au niveau de la configuration / du développement des bandeaux de TAO
- La gestion des différents environnements (développement, recette, production) et des différents sites de production en est grandement facilitée.

Dans le but de profiter pleinement des avantages décrits ci-dessus il faut, bien sûr, prévoir à l'avance les différents environnements / sites d'appels qui seront mis en place ainsi que les configurations des différentes instances du bandeau de TAO à déclarer.

Il est à noter que si cela est possible en développement interne, ce fonctionnement n'est pas possible avec le connecteur Siebel qui lui doit se connecter en direct sur un TServer. Du moins pas avec les versions 6.X du connecteur Genesys.

Là aussi cela peut paraitre basique comme vérification, mais il est nécessaire de vérifier l'ordre des évènements envoyés par le PABX et de voir si on peut les gérer par le CTI.

On peut prendre un exemple concret avec les évènements de fin d'appels sur Alcatel. Quand un appel distribué par l'ACD prend fin le PABX fait passer l'agent par les phases suivantes :
- raccrochage de l'appel
- passage en mode de post-traitement
- passage en "pause syndicale" (si celle-ci est activée sur le PABX)
- passage en mode prêt ou retrait en fonction de la configuration du groupe de travail
La réception de ces évènements ne pose aucun problème à Genesys. Ces phases peuvent être écourtées sur lé téléphone sans que cela ne pose le moindre problème du côté du CTI. Mais imaginons que l'on veuille gérer la durée de chacune de ces phase via le bandeau de TAO.

Via le Desktop toolkit de Genesys nous ne pouvons ni demander la fin d'une phase en cours, ni commander le passage en "pause syndicale". La demande de passage en post-traitement, en mode prêt ou retrait est possible, mais pas en "pause syndicale". Cette notion peut être émulée sur le bandeau TAO alors que le téléphone est dans un mode qui est fonctionnellement semblable.

De tels cas sont heureusement rares mais il est de toutes façons recommandé d'avoir une bonne connaissance des fonctionnalités utilisées sur le centre d'appels et de s'assurer de ce qui est faisable en CTI avant de commencer l'étude du bandeau de TAO. du bandeau de TAO

C'est la base de la gestion du bandeau de TAO. En réponse à la demande de connexion le TServer renvoie la liste des fonctionnalités supprotées par le PABX auquel il est lui même connecté. Ce qui peut être utile quand on gère un centre d'appels disposant de plusieurs PABX différents.

Le login dépend du type d'agent et de la façon dont il travaille. Sur Alcatel il est possible de monitorer les postes de deux façons distinctes :
- on monitore un poste téléphonique sans qu'un agent ne soit connecté dessus.
- on monitore un poste sur lequel un agent se connecte
Le fonctionnement avec login agent est beaucoup plus souple en centre d'appels car il permet aux agents de se connecter sur n'importe quel poste et de changer de groupe de travail facilement. La distribution des appels et les groupes de travail sont présentés ici.

Alcatel, par rapport à d'autres PABX présente une particularité : au moment où un agent se connecte le login de l'agent se substitue au numéro du poste téléphonique utilisé. Le résultat est un changement de numéro d'annuaire de la ressource en question. L'agent peut donc disposer d'une ligne directe qui a le même numéro quelque soit le poste de travail où il s'est installé.

L'option "agent substtitute" permet au bandeau de TAO de ne monitorer qu'une extension et de demander au TServer d'envoyer tous les évènements, même relatifs à l'agent, sur l'extension du poste téléphonique. Cette option est obligatoire pour le connecteur Siebel.

Le passage en prêt est simple à gérer. L'évènement reçu est un "TEventAgentReady". La demande de passage en prêt se fait avec la méthode "TReady". Alors que le passage en retrait ou post traitement est un peu plus subtil.
Les passage en reatait et en post traitement se font tous les deux sur réception d'un évènement "TEventAgentNotReady". Ce qui les distingue c'est le "WorkMode" reçu dans l'évènement. Ses valeurs possibles sont :

0 The work mode is unknown
1 The agent has to perform a manual operation to become available after a call is disconnected
2 The agent's availability is decided by the switch
3 If the agent work mode is set to AgentManualIn, this status specifies the condition assigned 
  to the agent after the previous call has cleared and before the agent becomes available to 
  receive the next call
4 The agent is not ready to receive calls
5 The agent work mode is set to NoCallDisconnect other than the default value

Dans le cas qui nous occuppe ce ont les valeurs 3 et 4 qui nous intéressent. Elles seront aussi utilisées avec la méthode "TNotReady" qui nous servira à demander le passage en mode retrait ou en post traitement.

Rappel : En mode prêt l'agent peut recevoir tous types d'appel (appel ACD / interne / direct sur son nuléro), en mode retrait il ne peut recevoir que des appels internes ou directs et en post traitement il ne peut recevoir aucun appel.

Sur un PABX Alcatel un agent se connecte sur un poste (ou extension) et de vient un agent (ou position ACD) une fois connecté. Il est aussi possible d'utiliser le CTI directement pour prendre le contrôle d'un poste sans avoir besoin de se logguer. C'est ce qui est géré dans cet exemple de code.
Dans cet exemple de code j'utilise une connexion classique au TServer, en configurant ce dernier en mode "agent-substitute" je n'aurais besoin de déclarer qu'une extension.

if ( AgentID = '' ) and ( AgentPwd = '' ) then
begin
     TExtension1.TExtensionType := TExtension2.TExtensionType;
     TExtension1.TDN := AgentDn;

     TitreBandeau := 'Poste ' + AgentDn;

end
else
begin
     TExtension1.TExtensionType := 2;
     TExtension2.TDN := AgentDn;
     TExtension2.TAgentID := AgentID;
     TExtension1.TDN := AgentID;
     TExtension1.TAgentID := AgentID;
     TExtension1.TAgentID := AgentID;
     TExtension1.TAgentPassword := AgentPwd;
     TExtension2.TAgentPassword := AgentPwd;

     AgentType := AGENT_ACD;

     TitreBandeau := 'Agent ' + AgentID + ' - ' + AgentServiceName + ' - ' + AgentAgenceName;

end;

case AgentType of

AGENT_ACD:
begin
     TExtension1.Enabled := true;
     if not TExtension1.Enabled then Tracer( 'Could not start Extension 1' );

     TExtension2.Enabled := true;
     if not TExtension2.Enabled then Tracer( 'Could not start Extension2' );

     TExtension1.TRegister;
     TExtension2.TRegister;

     TExtension2.TQueue := AgentQueue;
     TExtension1.TQueue := AgentQueue;

     // Le login se fait sur l'extension 2 (poste)
     // et c'est l'extension 1 qui sera ensuite utilisée.
     TExtension2.TLogin;
end;

AGENT_NON_ACD:
begin
     TExtension2.Enabled := false;
     if TExtension2.Enabled then Tracer( 'Could not stop Extension2' );

     TExtension1.Enabled := true;
     if not TExtension1.Enabled then Tracer( 'Could not start Extension1' );

     TExtension1.TRegister;
end;

end; // Case

C'est le point de départ de la gestion des appels par le bandeau de TAO. C'est là que l'ouverture de fiche va être faite en automatique, et que le téléconseiller va commencer à gagner du temps.

C'est au début de l'appel qu'on exploite toutes les données venant du PABX.

La première chose à déterminer sur la prise d'appel est le type de cet appel :
- appel entrant sur un groupe d'agent
- appel entrant sur la ligne directe de l'agent
- appel interne
- appel sortant (manuel ou généré par le CTI)

Les évènements qui indiquent le début d'un appel sont "TEventRinging" au moment ou le poste de l'agent sonne et "TEventEstablished" au moment où l'appel est effectivement transmis à l'agent.

La plupart du temps c'est le "TEventEstablished" qui est préféré pour traiter les données de début d'appel. Les informations à rechercher sont le "CallType" qui peut avoir les valeur suivantes :

0 The type of this call is unknown
1 An internal call
2 An inbound call
3 An outbound call
4 A consultation call

Dans le cas d'un appel entrant il rests à déterminé si l'appel est arrivé sur la ligne directe de l'agent ou a été distribué par l'ACD. Cela déterminera s'il y aura une phase de post traitement en fin d'appel mais peut aussi influer sur les possibilités de traitement en cours d'appel. Pour cela il suffit de vérifier l'attribut "FirstDNIS" de l'évènement de début d'appel. Il indique le point d'entrée dans le PABX. Si le numéro est celui d'un pilote c'est que l'appel est un appel ACD. Si c'est un numéro d'agent c'est que l'appel est un appel sur une ligne directe.

Ce n'est qu'une fois que l'appel aura été catégorisé que l'on pourra déterminer les traitements adéquates à appliquer, pour l'ouverture de la fiche du client mais aussi pour déterminer si et comment on va enregistrer des informations sur l'appel qui va avoir lieu. On pourra par exemple enregistrer les dates et heures d'appel du client et indiquer quel conseiller a traité la demande.

C'est le type d'appels le plus courant. Un appel entrant est distribué par l'ACD et est traité par un agent. Les informations disponibles en début d'appel sont assez classiques :
- numéro de téléphone de l'appelant
- ressoirce d'entrée sur le PABX (le First DNIS dont que nous avons utilisé pour vérifier le type d'appel)
- temps d'attente avant distribution de l'appel
On peut dans certains cas aussi y trouver des données attachées. Les données transmises dans le champ SUU (aussi appelé mini message), par exemple, sont transmises jusqu'au bandeau de TAO par ce biais.

Nous verrons ici les appels sortants passés unitairement par l'agent. Les campagnes d'appels gérées en automatique seront abordées dans un autre article.

Il peut être pratique pour un attaché commercial d'avoir des outils facilitant l'appel d'un client. Par exemple, sur la fiche de celui-ci, un bouton qui déclencherait la composition du numéro.
Pour cela rien de plus facile : la méthode TDial appliquée au TGetDefaultCallObj de l'extension et le tour est joué...
De plus on interceptera l'évènement EventDialing pour traiter le cas où l'attaché commercial numérote directement sur son poste téléphonique.

C'est le point le plus complexe dans la gestion des appels par TAO. Il faut gérer le transfert tant au niveau de l'agent qui va le provoquer que celui qui va recevoir le transfert. Il faut aussi distinguer 2 types de transfert : en un ou deux temps.

Le transfert en un temps est le plus facile à gérer : Ils se font sur des ressources telles que des pilotes dont on sait qu'elles peuvent accépter des appels sans avoir besoin de vérifier leur disponibilité.

Le transfert en deux temps commence par un appel de consultation. L'émetteur commence donc par faire un double appel pour consulter l'agent destinataire, puis soit il valide le transfert soit il reprend l'appel du client.

Dans les deux cas on aura pris soin d'attacher à l'appel les informations nécessaire pour ouvrir la fiche du client et positionner le logiciel de CRM sur l'écran approprié. Cela se fait en attachant des données à l'appel. Dans ce cas on appréciera les souplesses de la gestion des données attachées qui peuvent être disponibles lors de l'appel de consultation alors qu'elles ont été attachées sur l'appel du client.

consult-user-data
Default Value: separate
Valid Values:
separate Stores user data for original and consultation calls in separate structures
inherited Copies user data from an original call to a consultation call when the consultation call is established; thereafter, stores user data separately for the original and the consultation call
joint Stores user data for an original call and a consultation call in one structure

L'agent destinataire souhaité du transfert peut donc disposer des données relatives au client dès le début de l'appel de consultation. Cela peut l'aider à décider s'il va accepter ou non le transfert.

Côté initiateur du transfert la compléxité réside dans la gestion de début et de fin de l'appel de consultation. On peut avoir ces enchainements :

Dans le cas où le transfert d'appel est finalisé
- début d'appel ACD
- composition de l'appel de consultation
- établissement de l'appel de consultation
- validation du transfert
- fin de l'appel de consultation
- fin de l'appel ACD

Dans le cas où l'appel de consultation n'aboutit pas
- début d'appel ACD
- echec de l'appel de consultation
- reprise de l'appel ACD
- suite du traitement de l'appel

Dans le cas où le destinataire ne souhaite pas accepter le transfert
- début d'appel ACD
- composition de l'appel de consultation
- établissement de l'appel de consultation
- abandon de l'appel de consultation
- fin de l'appel de consultation
- reprise de l'appel ACD
- suite du traitement de l'appel

Ce sont des informations stockées dans la mémoire du serveur CTI et qui sont associées à un appel ou à un évènement CTI. Elles permettent :
- de transmettre des données entre applications, entre applis de Gestion de Relation Clients
- de transmettre des données entre bandeau de TAO et
- de faire des statistiques CTI enrichies par des données clients

6-1-1. Récupérer des données attachées▲

NbKey := UsrData.GetCount;
i := 0;
while i < NbKey do
begin
     UsrPair := UsrData.Get(i);
     if UsrPair.type = CKVTypeString then DataString := UsrPair.StringValue;
     if UsrPair.type = CKVTypeNum    then DataNum    := UsrPair.NumValue;
     if UsrPair.type = CKVTypeBinary then DataString := UsrPair.BinaryValue;
     if UsrPair.type = CKVTypeList   then DataString := UsrPair.ListValue;

     Tracer( 'User Data :' + UsrPair.Key + ' = ' + USrPair.StringValue );

     i := i + 1;
end;

6-1-2. Ajouter des données attachées▲

     UsrPair := CoCTKVPair.Create;

     UsrData.Clear;
     UsrPair.Key := 'XXXXXXXXX';

     UsrPair.Type_ := CKVTypeString;
     UsrPair.NumValue := 'XXXXXXXXXXXX';
     UsrData.AddHead(UsrPair);

     UsrData.Clear;
     UsrPair.Key := 'XXXXXXXXX';

     UsrPair.Type_ := CKVTypeNum;
     UsrPair.NumValue := 9999999999;
     UsrData.AddHead(UsrPair);

     UsrData.Clear;
     UsrPair.Key := 'XXXXXXXXX';

     UsrPair.Type_ := CKVTypeBinary;
     UsrPair.BinaryValue := 1;
     UsrData.AddTail(UsrPair);

     UsrData.Clear;
     UsrPair.Key := 'XXXXXXXXX';

     UsrPair.Type_ := CKVTypeList;
     UsrPair.ListValue := datalist;
     UsrData.AddTail(UsrPair);

Ce sont des évènements non téléphoniques servant à échanger des données entre applications TAO et serveurs CTI. Les user events se différencient les uns des autres par leur destination et les données qui leur sont attachées. Un user event permet d'échanger des données attachées en dehors de tout contexte d'appel.

6-2-1. Envoyer un user event▲

var
    l_UserData  : CTKVList;
    l_UserPair  : CTKVPair;
    l_UserEvent : TEventInfo;
begin
    if TExtension1.Enabled then
    begin
         // Caractéristiques de l'événement
         l_UserEvent := CoTEventInfo.Create;
         l_UserEvent.ThisDN := AgentID;
         l_UserEvent.OtherDN := AgentID;
         l_UserEvent.AgentID := AgentID;

         // Attachement des données

         l_UserData := CoCTKVList.Create;
         l_UserData.Clear;
         l_UserPair := CoCTKVPair.Create;

         // On extrait les clés et les valeurs de la chaîne

         l_UserPair.Key := Key;
         l_UserPair.Type_ := CKVTypeString;
         l_UserPair.StringValue := TheData;
         l_UserData.AddHead(l_UserPair);

         l_UserEvent.UserData := l_UserData;

         // Envoi de l'événement
         TExtension1.TSendUserEvent(l_UserEvent);
         
         l_UserPair.free;
         l_UserData.free;
         l_UserEvent.free;
    end
    else
         Result := FALSE;

end;