[Conception] Mini gestionaire de tickets

Version imprimable

01/04/2008, 14h23
spirit69

[Conception] Mini gestionaire de tickets

Bonjour à tous.

Nouveau theme, nouveau probleme.

Domaine : callcenter.
Objectif : consulter une liste d'appels à passer, enregistré les infos obtenues lors de l'appel, fermer l'enregistrement si les infos sont suffisantes. Si non, mettre le "ticket" en attente afin de procéder à un second appel par la suite.

2 types d'attentes :
- passive, une fois le délais d'attente passé, le ticket est réintroduit dans la liste d'appels à passer.
- active, une fois le délais passer, il faut signaler à l'opérateur qu'il doit passer cet appel.

Je souhaite donc utiliser MySql pour stocker les enregistrements.

Le point sur lequel je bute est la gestion des rappels.

Comment vérifier que le temps d'attente d'un ticket présent en liste d'attente (une table dédiée) va / a expirer/é ?

Pour le moment je vois :
1 table : liste d'appels
1 table : info obtenues (id appel, ...)
1 table : liste urgente.

L'appel est prit dans la liste d'appels, il est passé, résolu ou mis en attente soit en le renvoyant dans la liste d'appels s'il c'est un cas passif, soit une entrée est créé dans la liste urgente.

Enfin, toutes les x secondes un requete est exécutée sur la table liste urgente qui est censée rester de taille réduite afin de voir s'il faut déclencher une alert.
Je n'ai vraiment aucune idée de l'éfficacité de cette solution...

D'autant plus que j'ai clairement l'impression de réinventer la roue au niveau de la gestion d'appels/tickets. (OTRS open source par exemple mais beaucoup trop d'options qui ne me servent pas).

Si l'un d'entre vous a des conseils, voire des questions je serais enchanté des les écouter.
02/04/2008, 17h32
FrontLine

Bonjour,

déjà une idée à prendre en compte est pour la liste des appels, il serait peut être judicieux de réactualiser la liste des appels en Ajax par exemple. Ceci pour éviter qu'un conseillé du Callcenter prenne un appel déjà traité et pour que le temps d'appel/ attente soit au plus proche.

Pour gérer l'expiration idem : dans Mysql un champ time() représentant le délais d'expiration et permettant de mettre à jour la colonne d'info qui est rafraîchit par Ajax. Dans le cas où l'attente expire, il faut penser à mettre à jour le statut dans l'entrée Mysql qui correspond à ce ticket (expiré).

2 ou 3 conseils qui peut être ne vont pas trop te servir, je ne sais pas exactement où tu en es dans la conception du script.

FrontLine
03/04/2008, 11h15
spirit69

Je peux t'assurer que tes idées me servent beaucoup.

la petite histoire

Le callcenter ou je bosse actuellement est équipé de la facon suivante :

- BDD SQL Server 2005 pour le stockage de toutes les données.
L'organisation de cette BDD a de quoi pousser au suicide un paquet de dev ...
il n'y a que 2 tables (call et customer).
Depuis que je suis la, on me demande d'ajouter un peu de ci, un peu de ca mais c'est ingerable.
- Associé à cela, un portail web plutot pas mal fait permettant l'enregistrement des données.
- et a coté, un logiciel de gestion de ticket, le seul outil capable de nous générer des rappels pour tel ou tel log.

Le but serait maintenant de fusionner le tout.
1 BDD (modulaire!) + 1 interface (web? pas web?) si possible capable de se reperer dans le temps.

La réactualisation de la liste d'appels appels en Ajax est une bonne idée. Il faut également que je parvienne à vérouiller un appel pendant qu'un opérateur le traite.

La question que je me pose réellement actuellement est :
Continuer avec un portail web est il le bon choix ?

Je n'ai pas de pression particuliere car mon boss sait tres bien qu'il ne s'agit pas de mon domaine ici.
Disons que je prends cela comme un challenge.
04/04/2008, 02h48
FrontLine

Le boss ne met pas la pression c'est déjà ça ^^

Citation:

Le but serait maintenant de fusionner le tout.
1 BDD (modulaire!) + 1 interface (web? pas web?) si possible capable de se reperer dans le temps.

Pour se repérer dans le temps, je vois 2 solutions basé sur time() de PHP ou timestamp pour le SQL (SQL server gère le timestamp ?).

On synchronise le temps soit avec un fichier de session (ou le temps directement stocké en mémoire pour plus de rapidité) qui met à jour la BDD toutes les X secondes, soit directement dans la base de données pour éviter des pertes de temps en cas de plantage.

Un refresh avec un délais très court 1seconde voir 2 secondes, niveau performance cette appli va être utilisé par quoi ? 100 postes, 200 postes, 300 postes d'opérateurs du callcenter ? Dans ce cas c'est bourrin mais ça passe correctement avec 1 ou 2 serveurs (et mieux avec un cache opcode) par contre sur un site Web fréquenté outch le serveur.

Une solution rapide, légère et fléxible serait d'ouvrir un port socket pour y faire passer le temps et autres infos temporaire (l'attente et le traitement d'un appel est temporaire), exemple :
IDclient: 3, timeclient:945,statut:attente, et toutes infos à synchroniser et à connaître rapidement.

Ensuite tu log les infos finale à la fin de l'appel, attention à détecter la perte d'un client qui raccroche pendant son attente pour tout de même garder une trace de son appel.

Ce n'est pas un mince affaire en socket et il y a sûrement mieux qu'une interface Web, une interface logicielle avec la gestion d'un réseau peut être. Surtout pour ce style d'application mais disons que l'interface Web est un choix facilement maintenable (sauf si tu maîtrises d'autres langages).

Citation:

Continuer avec un portail web est il le bon choix ?

Pour ma part je choisirais "l'interface Web" qui est plus abordable pour un tel déploiement vue que je ne maîtrise pas des langages comme le C/C++, QT, Python, Java, ... et autres langages qui seraient peut être intéressant pour ce style d'appli.

Évidemment tu n'es pas obligé de passer par le Web en plus ce n'est pas très sûr de rendre accessible via Internet, même protégé par login/mdp. Un réseau interne fera l'affaire. Il y a également des applications qui gèrent le partage de fichier si besoin (Samba par exemple).
D'autres avis seraient intéressant.

Citation:

La réactualisation de la liste d'appels appels en Ajax est une bonne idée. Il faut également que je parvienne à vérouiller un appel pendant qu'un opérateur le traite.

Une solution simple serait d'ajouter dans la base de données un champ "statut", tu vérifies ce champ pour te repérer quand un appel doit être traité ou pas, en attente ou en communication, ...
Ainsi tu vérifies si l'appel n'est pas vérouillé quand tu as besoin et tu dévérouilles quand tu as besoin.

Bon tout ça ce n'est pas très pro mais ça peut faire l'affaire et tourner correctement si c'est bien monté et convivial pour l'opérateur, le chef d'équipe, le chef de plateau, l'admin et le boss.

Si ses quelques pistes peuvent t'aider tant mieux, bon courage ;)

FrontLine
04/04/2008, 11h08
spirit69

Ces quelques lignes m'aident plus qu'un peu!

Je vois que tu as de l'expérience. C'est ce qu'il me manque (en plus d'une connaissance approfondie de Php et SQL)

Je te remercie de m'accorder de ton temps, et désolé d'en abuser mais j'ai au moins 20 000 questions dans mon sac :aie:

Tout d'abord quelques précisions :

- Mea culpa pour utilisation du mot "portail web" sans aucunes precisions.
L'appli est utilisée sur le réseau local par disons actuellement maximum 30-40 opérateur (mais ca grandit à une vitesse que je prefere voir large).
Nous avons quand meme certains opérateurs/clients qui accedent à notre outils depuis l'extérieur. Donc il faudra bel et bien que je bosse sur la sécu (je n'en suis pas la)
Mais en aucun cas il ne s'agit d'un portail accessible par tout le monde. (ouf)

- Le serveur actuel tiens le coup sans broncher.
SQL server tourne plutot bien malgré les quelques 80 000 entrées dans la table unique :aie:

- Cependant, il est vrai que l'on me pousse un peu à voir du coté Mysql ou autre gestionnaire de BDD Gratuit. (la boite voudrait se séparer de MS autant que possible).

Je pense donc tenter l'aventure sur Mysql histoire de me faire la main.
(A moins que tu ne me dise qu'il s'agit d'une tres mauvaise idée)

- Nos lignes telephonique ne sont pas liées aux PCs. Concretement, on recoit un appel (ou on passe un appel) et on saisi manuellement le numéro concerné afin de creer une entrée dans la BDD.

- Je ne me lance pas non plus dans la réécriture complete du callcenter (je n'en ai pas les connaissances actuellement) mais d'une partie liée à un nouveau client, avec un fonctionnement tres simple :

Citation:

1 - On recoit une liste de numéro à contacter
2 - On appelle le numéro et on pose les questions
3 - a - on a nos réponse, c'en est fini pour ce numéro
3 - b - pas de réponses, deux possibilités :
3 - b - 1 - on réinsere le numéro dans la liste à appeler (3 appels max)
3 - b - 2 - il nous est demandé d'appeler à une heure précise donc il faut etre capable de générer une alerte le moment venu.
4 - on récupere une liste de numéros traités et résolus avec succes que l'on transmet.

C'est un schéma tres simple, sans reelle difficulté. Sauf cette fichue alerte.

Apres ces quelques précisions, les questions :yaisse2: :

Citation:

On synchronise le temps soit avec un fichier de session (ou le temps directement stocké en mémoire pour plus de rapidité) qui met à jour la BDD toutes les X secondes, soit directement dans la base de données pour éviter des pertes de temps en cas de plantage.

Un refresh avec un délais très court 1seconde voir 2 secondes, niveau performance cette appli va être utilisé par quoi

Pourrais tu détailler un peu plus? ou éventuellement me diriger vers des tutos. Car malheureusement, c'est la partie sur laquelle je bute. Je ne sais pas du tout comment proceder.

Pas de souci, si j'ai le temps en passant je répondrais ;)

Citation:

Je vois que tu as de l'expérience. C'est ce qu'il me manque (en plus d'une connaissance approfondie de Php et SQL)

Pas tant que ça, il m'est arrivé de travailler quelques mois dans différents Callcenters et un ami manager dans un Callcenter me bassine tous les soir à l'heure de la pause café sur sa journée de manager dans le centre d'appel où il bosse, voila pour ma courte expérience dans le domaine :lol:

Citation:

Mea culpa pour utilisation du mot "portail web" sans aucunes precisions.
L'appli est utilisée sur le réseau local par disons actuellement maximum 30-40 opérateur (mais ca grandit à une vitesse que je prefere voir large).
Nous avons quand meme certains opérateurs/clients qui accedent à notre outils depuis l'extérieur. Donc il faudra bel et bien que je bosse sur la sécu (je n'en suis pas la)
Mais en aucun cas il ne s'agit d'un portail accessible par tout le monde. (ouf)

Ok donc une interface Web accessible par couple login/mot de passe avec log du temps de travail et nombre d'appel passé/reçu par le collaborateur.
Même avec une centaine d'opérateur l'appli devrait pouvoir tourner sur un seul serveur avec tout de même de la puissance, pas un processeur de 400 Mhz :aie:
Un 2eme serveur de secours qui prend le relais en cas de panne du 1er ne serait pas du luxe, donc prévoir la syncro des données entre les 2 serveurs, sinon ça va être ingérable.

Citation:

- Le serveur actuel tiens le coup sans broncher.
SQL server tourne plutot bien malgré les quelques 80 000 entrées dans la table unique :aie:
- Cependant, il est vrai que l'on me pousse un peu à voir du coté Mysql ou autre gestionnaire de BDD Gratuit. (la boite voudrait se séparer de MS autant que possible).

Je pense donc tenter l'aventure sur Mysql histoire de me faire la main.
(A moins que tu ne me dise qu'il s'agit d'une tres mauvaise idée)

Je ne connais que Mysql, je ferais donc cette appli avec.

80 000 entrées c'est loin de la limite des capacités de Mysql. J'ai une table qui comporte plus d'1 million d'entrées et ça tourne correctement.

Citation:

- Nos lignes telephonique ne sont pas liées aux PCs. Concretement, on recoit un appel (ou on passe un appel) et on saisi manuellement le numéro concerné afin de creer une entrée dans la BDD.

Te serait il possible de lier le téléphone au PC ? Il existe des softs (peut être même gratuit) pour ça :)
Ca éviterait à l'opérateur des manipulations rébarbatives, 1 clic ou 2 clics = 1 appel + exécution du script serait l'idéal.

Citation:

1 - On recoit une liste de numéro à contacter
2 - On appelle le numéro et on pose les questions
3 - a - on a nos réponse, c'en est fini pour ce numéro
3 - b - pas de réponses, deux possibilités :
3 - b - 1 - on réinsere le numéro dans la liste à appeler (3 appels max)
3 - b - 2 - il nous est demandé d'appeler à une heure précise donc il faut etre capable de générer une alerte le moment venu.
4 - on récupere une liste de numéros traités et résolus avec succes que l'on transmet.

C'est un schéma tres simple, sans reelle difficulté. Sauf cette fichue alerte.

1 solution serait de stocker le délais de rappel dans un champ "timealerte" ou "timerappel", par la suite il faut donc vérifier dans la colonne d'infos qui est rafraîchit avec Ajax si il y a des alertes pour les placer en 1er dans la liste des clients à appeler.

Tu peux aussi gérer ça avec un indice de priorité, ce qui pourrait également te servir pour placer un client important en priorité.

Donc sélection des appels à passer avec une condition Mysql du style :

Code:

WHERE timerappel > 'hier' AND timerappel < 'demain' AND statut = 'à traiter' ORDER BY timealerte DESC, priorite DESC

Remplace hier et demain par le time() d'hier et de demain, ou alors tu mets la date d'aujourd'hui dans un champ et l'heure dans un autre.
Définis toi des statuts d'appel : à traiter, traiter, ... (ou des identifiants de statut "0=à traiter, 1 = traité, ..." pour un gain de place et de rapidité à la sélection via une requête). Avec un champ où tu log un commentaire (le client m'a insulté ou client à rappeler en juillet, ...).

Citation:

Pourrais tu détailler un peu plus? ou éventuellement me diriger vers des tutos. Car malheureusement, c'est la partie sur laquelle je bute. Je ne sais pas du tout comment proceder.

Qu'est ce que tu ne comprends pas ?

Si c'est la manière de procédé que j'évoque :
- l'opérateur est en appel => toutes les secondes tu mets à jour ta variable de session.
Un compteur du style (à l'arrache) :
Code:

1 2 3 4 $debut_appel = time(); // Temps avec time () du début d'appel // time() actuel - le time() du début de l'appel pour en sortir les secondes de différence $_SESSION['timeappel'] = time()-$debut_appel;
Ce qui te donne la durée de l'appel à chaque refresh (à vérifer j'ai pas testé).

A la fin de l'appel tu stockes la durée de l'appel ($_SESSION['timeappel']) dans la base de données.

Au pire pour éviter de synchroniser tu fais un UPDATE à chaque refresh Ajax mais ça va être très très gourmand pour le serveur. Attention une config de base de Mysql ne permet que 100 connections simultanées à la BDD.

Je dis tout ça dans le tas sans trop réfléchir aux différents problèmes et conséquences. L'organisation du script est à méditer donc. :mouarf:

FrontLine

04/04/2008, 15h48
spirit69

Merci beaucoup pour tous ces conseils.

Je vais regarder ca en détail dans les prochains jour.

Ca m'a l'air d'etre à ma portée, et ca me permettra d'en appendre un peu plus sur php/mysql/js

J'en profite pour poser une question de débutant :

j'ai beaucoup de mal à formuler ma requete pour trouver une réponse sur google.Disons que je souhaiterais mettre la main sur des scripts/tutos permettant un refresh des infos coté client.

C'est a dire que lorsque l'opérateur n'est pas en appel, je souhaite que silencieusement le script consulte la BDD afin de voir si le temps d'attente d'un appel urgent va expirer afin d'alerter l'opérateur.

C'est un peu le coeur du probleme :aie: une fois cela résolu le reste c'est de la conception.
04/04/2008, 20h37
FrontLine

Exemple en Ajax la page est interface.php et l'appli rafraichit est info.php.
C'est dans info.php que tu consultes ta base avec les alertes et tout.

Pour formuler dans une recherche je pense que "refresh+ajax" te retournera des résultats.

Sinon vois aussi du coté de innerHTML et DOM.