BreizhVoIPVotre standard sait qui appelle avant vous. Le module Webhook transmet cette information à une autre application, pendant que le téléphone sonne, et peut même router l'appel selon ce qu'elle répond.
C'est le module qui relie le téléphone au reste du système d'information : un CRM qui ouvre la fiche du client, un outil de ticketing qui prépare le dossier, un tableau de bord qui compte les appels.
Il se pose dans un plan d'appel, depuis la famille Services.
Ce qui part, et où
L'URL est obligatoire, en HTTP ou HTTPS, et la méthode se choisit parmi
les verbes habituels. Les en-têtes personnalisés servent à l'authentification :
c'est là que se met le jeton Authorization de votre application.
L'essentiel est la case Envoyer automatiquement les informations d'appel.
Cochée, le panel ajoute au corps de la requête un objet callContext qui
contient l'extension appelée, le numéro de l'appelant, l'identifiant unique de
l'appel, sa langue et les variables Asterisk.
C'est le numéro de l'appelant qui fait tout le travail : il suffit à votre application pour retrouver le client et préparer sa fiche.
Vous pouvez y ajouter vos propres champs personnalisés, une paire clé-valeur
à la fois. Poser origine: standard sur un plan et origine: sav sur un autre
permet à l'application de savoir par quelle porte l'appel est entré, sans que
vous ayez à multiplier les URL.
Le délai, qui n'est pas un détail
Le timeout borne l'attente de la réponse, de 1 à 120 secondes. Le panel recommande 10 à 30 secondes, et prévient explicitement au-delà de 60.
La raison est simple : l'appelant attend pendant ce temps. Une application lente ne ralentit pas un traitement de fond, elle fait patienter quelqu'un qui a le téléphone à l'oreille. Dix secondes est déjà long pour lui.
Prévoyez le cas où l'application ne répond pas. Un webhook branché sur un service en panne, avec un timeout de soixante secondes, ajoute une minute de silence à chaque appel entrant. Reliez la sortie Timeout vers la suite normale du parcours plutôt que de la laisser en cul-de-sac.
Router selon la réponse
C'est ce qui distingue ce module d'une simple notification.
En mode simple, trois sorties : Succès, Erreur, Timeout. Le routage suit le code HTTP.
En cochant Utiliser la réponse JSON pour router, vous désignez une clé de la
réponse et la valeur attendue. Sur le plan de démonstration, le CRM répond
clientConnu: true ou non, et l'appel part vers l'accueil ou vers le support en
conséquence.
Un mode conditionnel va plus loin en définissant des sorties personnalisées selon des conditions, quand deux issues ne suffisent plus.
Ce que ça permet, concrètement
Ouvrir la fiche du client sur l'écran de l'agent avant même qu'il décroche. C'est le gain le plus immédiat, et il se mesure en secondes gagnées sur chaque appel.
Router selon des données que le standard n'a pas. Un client dont le contrat a expiré, un dossier déjà ouvert, une commande en cours : le CRM le sait, le téléphone non. Le webhook fait le pont.
Compter et tracer dans votre propre outil, sans dépendre des statistiques du panel.
Le webhook part pendant l'appel, à chaque appel. Sur un standard qui en reçoit trois mille par semaine, c'est trois mille requêtes que votre application doit encaisser. Vérifiez qu'elle tient la charge avant de brancher le module en production, et surveillez le premier jour.
Et ensuite
Pour vérifier que le webhook part bien et que l'appel emprunte la bonne sortie, le mode debug montre le passage dans le module et la sortie retenue, avec le temps que ça a pris.