Prévenir une application à chaque appel entrant

Votre 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 doit être une adresse publique : une adresse de réseau privé mène directement à la sortie Erreur. La méthode se choisit parmi les verbes habituels. Les en-têtes HTTP servent à l'authentification : c'est là que se met le jeton Authorization de votre application.

L'essentiel est l'interrupteur Joindre les informations d'appel. Activé, 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 ajouté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 délai de réponse borne l'attente, de 1 à 120 secondes. Le panel 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.

Pour qu'il n'entende pas un silence inquiétant pendant ce temps, activez Musique d'attente pendant la requête, dans la partie Attente de l'appelant. Choisissez l'une de vos musiques d'attente importées, ou laissez la musique par défaut.

Router selon la réponse

C'est ce qui distingue ce module d'une simple notification.

Le mode de routage se choisit dans la partie Routage, et la partie Sorties, en bas du formulaire, rappelle à chaque fois ce qui mène où.

Succès ou erreur donne trois sorties : Succès, Erreur et Délai dépassé. Un code HTTP 2xx mène à Succès, tout autre code à Erreur. En activant Décider selon le contenu de la réponse, vous désignez plutôt une clé de la réponse et la valeur attendue : Succès si la clé vaut cette valeur, quel que soit le code HTTP. 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.

Selon la valeur d'une clé crée une sortie par valeur. Le panel lit une clé de la réponse, par exemple niveau, et vous ajoutez une sortie pour premium, une pour standard, une pour essai. Une même sortie accepte plusieurs valeurs séparées par des virgules, sans tenir compte des majuscules. Une valeur qui ne correspond à aucune sortie mène à Erreur.

Sorties personnalisées va plus loin : chaque sortie a sa condition, sur le code HTTP (404, 4xx), la présence d'une clé, ou la valeur d'une clé comparée avec égal à, contient, supérieur à ou inférieur à. Les conditions sont testées dans l'ordre, et la première vérifiée choisit la sortie.

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.

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.