Ce billet fait partie d'une série sur l'optimisation des opérations de support client. Nous y expliquons comment libérer votre équipe en automatisant la résolution des demandes standardisées.

La recherche manuelle d'informations est très inefficace.

Si vous êtes comme d'autres entreprises, il y a de fortes chances que vous observiez un modèle clair dans le type de questions d'assistance que vous recevez. Mais parfois, la réponse à ces questions peut également s'avérer répétitive.

Take a random inquiry to a hospital, and chances are high the inquirer is a patient looking to reschedule their appointment. Le same goes for logistics. In a recent interview, the CX Director at DPD indicated more than half of their inquiries are related à la requesting status of a package or rescheduling the delivery. 

Dans ces deux exemples, les représentants doivent rechercher un élément d'information standardisé, l'énoncer à l'auteur de la demande et effectuer une action pour traiter la réponse. Ces types de questions structurées ( flows ) se prêtent parfaitement à l'automatisation, ce qui permet à vos représentants de consacrer plus de temps aux questions complexes.

Pourquoi tout le monde ne donne-t-il pas la priorité à ses demandes de renseignements ?

Malheureusement, jusqu'à récemment, l'automatisation des communications était inaccessible. La construction de flows complexes nécessitait des outils de télécommunications coûteux et beaucoup de temps d'ingénierie. C'est pourquoi nous avons créé Flow Builder, une plateforme d'automatisation des communications qui permet aux équipes interfonctionnelles de collaborer sur les flux de communication. Elle vous permet d'exécuter une logique, d'extraire des données de sources externes et d'effectuer des actions dans des services tiers.

C'est comme ça qu'il faut faire

Dans ce guide pratique, nous allons nous intéresser à une entreprise chargée de livrer des colis. Les deux principaux facteurs de coût pour ce type d'entreprise sont les coursiers qui se présentent à un endroit où le destinataire n'est pas disponible pour recevoir le colis, et les destinataires qui appellent pour poser des questions sur l'état de leur livraison ou sur les modifications apportées à celle-ci. Notre objectif sera de réduire le nombre de fois où un coursier se présente à une porte fermée et de réduire la charge sur le centre de contact.

Ce que nous essayons d'atteindre :

• Envoyez une notification avec la mise à jour de la commande initiale.

• Attrapez la réponse à la notification.

• Décidez de ce qu'il faut faire en fonction de la réponse.

• Récupérer les options de réordonnancement

• Permettez au destinataire de reporter le rendez-vous.
  
  

Envoyez une notification avec la mise à jour de la commande initiale.

S'il existe plusieurs moyens d'automatiser les demandes de renseignements entrantes, la meilleure façon de réduire la charge des centres de contact est de faire en sorte que les clients ne s'adressent pas à eux en premier lieu. Le moyen le plus efficace d'y parvenir est de les tenir informés de manière proactive avant que leurs problèmes ne surviennent. L'avantage supplémentaire est qu'en faisant cela, nous établissons également un canal de communication qui nous permet de les orienter vers les bonnes ressources avec une implication humaine minimale.

Nous allons commencer par identifier un événement que nous voulons utiliser pour initier le flux. Dans le cas de notre société de livraison, nous voulons contacter le client au moment où la livraison du colis est programmée. Cet événement peut se produire dans différents systèmes, en fonction de votre configuration. La clé ici est que nous devons appeler un webhook de ce système au moment où cela se produit, ce qui lancera le flux.

Sur la droite, vous pouvez voir que nous avons choisi un Webhook comme déclencheur et configuré différentes variables que nous nous attendons à recevoir dans le cadre du Webhook entrant.

• téléphone - Le phone number of the recipient

• premierNom - The first name of the recipient

• emplacement de livraison - A JSON object for the suggested delivery slot with an id, copy (this might vary depending on the system you use to manage the scheduling of your appointments).

• orderId - A unique identifier for the order

Next we send out a message on WhatsApp, because we are initiating the conversation we need to use a template message, also known as an HSM. You will need to have an approved template message before you can go on à la next step, pour plus d'informations sur les modèles de messages WhatsApp, voir ici.

Lorsqu'un modèle de message WhatsApp est approuvé, il apparaît dans votre Flow Builder, prêt à être utilisé. Nous prenons le prénom du webhook entrant et la copie du créneau horaire du créneau de livraison pour remplir le message.

Notez que dans le message, nous invitons le destinataire à répondre s'il souhaite modifier le créneau horaire.

Attrapez la réponse à la notification.

Maintenant que nous avons envoyé la notification, nous voulons écouter les messages entrants au cas où le client cherche à reprogrammer son heure de livraison. Cela peut être facilement réalisé en ajoutant l'étape "Attendre une réponse". Cette étape met en pause le flux jusqu'à ce qu'il reçoive une réponse. Vous pouvez éventuellement définir une date d'expiration, mais nous laisserons les valeurs par défaut pour l'instant. Nous voulons nous assurer de donner un nom à la variable de sortie, dans ce cas "order_received_reply".

Décidez de ce qu'il faut faire en fonction de la réponse.

En fonction de la réponse du destinataire, nous devrons prendre une décision. Dans notre exemple, nous ne recherchons que les clients qui répondent par la lettre A, mais vous pouvez imaginer un scénario dans lequel vous ajoutez plusieurs options de réponse.

En utilisant l'étape "Branch", nous pouvons lire la réponse et nous brancher en fonction de son contenu. Dans ce cas, nous voulons passer à notre flux de réordonnancement lorsque nous recevons la réponse "A".

Récupérer les options de réordonnancement

After the recipient indicates they are looking to reschedule, we want to provide them with a few alternative options to pick from. We’ll use the “Fetch variables” step to send out a request to the scheduling service (this will vary depending on how you manage your scheduling) to find the best alternative time. In our case we put together a fake endpoint using mockable.io for testing.

Nous prenons les créneaux horaires que nous venons d'extraire et les utilisons pour remplir notre message. Veillez encore une fois à proposer à l'utilisateur différentes options pour qu'il confirme son créneau horaire préféré.

Permettez au destinataire de reporter le rendez-vous.

Encore une fois, nous indiquons au flux d'attendre une réponse en utilisant l'étape "Attendre une réponse"...

... et se ramifient en fonction de l'apport du destinataire.

C'est presque fait ! Enfin, nous voulons renvoyer la réponse au service de planification afin de reprogrammer la livraison.

Et pour finir, nous envoyons un message confirmant la nouvelle date de livraison.

N'hésitez pas à nous contacter !

Gardez à l'esprit qu'il ne s'agit que d'un exemple simple de la manière dont cela pourrait fonctionner dans le monde réel. Nous avons vu des personnes combiner toutes sortes de sources de données, de services tiers et de channels. Le ciel est la limite.

If you have a problem that could be optimized with communication automation we would love to talk to you. Feel free to reach out here and we can set up some time with a product expert to help you flesh out your ideas.