Ce post fait partie d'une série sur l'optimisation des opérations de support client. Dans celui-ci, nous abordons comment libérer votre équipe en automatisant la résolution des demandes standardisées.

Rechercher des informations manuellement est très inefficace

Si vous êtes comme d'autres entreprises, il y a de fortes chances que vous constatiez un schéma clair dans le type de questions de support entrant. Mais parfois, la réponse à ces questions peut également s'avérer répétitive.

Prenez une demande aléatoire dans un hôpital, et les chances sont élevées que le demandeur soit un patient cherchant à reprogrammer son rendez-vous. Il en va de même pour la logistique. Lors d'une récente interview, le directeur de l'expérience client chez DPD a indiqué que plus de la moitié de leurs demandes concernent le statut d'un colis ou la reprogrammation de la livraison. 

Dans ces deux exemples, les agents doivent rechercher un élément d'information standardisé, le communiquer au demandeur et effectuer une action pour gérer la réponse. Ces types de flux structurés sont parfaits pour l'automatisation, ce qui permet à vos agents de retrouver du temps pour se concentrer sur des problèmes plus complexes.

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

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

Voici comment procéder

Dans ce guide, nous allons examiner une entreprise chargée de livrer des colis. Deux principaux facteurs de coût pour ce type d'entreprises sont les livreurs arrivant à un endroit où le destinataire n'est pas disponible pour recevoir le colis, et les destinataires appelant avec des questions sur le statut de leur livraison ou des changements apportés à la livraison. Notre objectif sera de réduire le nombre de fois qu'un livreur arrive devant une porte fermée et de réduire la charge sur le centre de contact.

Ce que nous cherchons à réaliser :

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

• Capturer la réponse à la notification.

• Décider quoi faire en fonction de la réponse.

• Récupérer des options de reprogrammation

• Permettre au destinataire de reprogrammer.
  
  

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

Bien qu'il existe diverses façons d'automatiser les demandes entrantes, la meilleure manière de réduire la charge sur les centres de contact est que les clients ne prennent pas contact en premier lieu. La méthode la plus efficace pour y parvenir est de les tenir proactivement informés avant que leurs problèmes ne surviennent. L'avantage supplémentaire est qu'en agissant ainsi, nous établissons également un canal de communication qui nous permet de les orienter vers les bonnes ressources avec un minimum d'intervention humaine.

Nous commencerons par identifier un événement que nous voulons utiliser pour initier le flux. Dans le cas de notre entreprise de livraison, nous souhaitons contacter le client au moment où le colis est programmé pour livraison. Cet événement peut se produire dans divers systèmes, en fonction de votre configuration. L'important ici est que nous devons appeler un webhook de ce système au moment où cela se produit, ce qui initiera le flux.

À droite, vous pouvez voir que nous avons choisi un Webhook comme déclencheur et configuré différentes variables que nous prévoyons de recevoir dans le cadre du webhook entrant.

• téléphone - Le numéro de téléphone du destinataire

• prénom - Le prénom du destinataire

• créneauDeLivraison - Un objet JSON pour le créneau de livraison suggéré avec un id, une copie (cela peut varier en fonction du système que vous utilisez pour gérer la programmation de vos rendez-vous).

• idCommande - Un identifiant unique pour la commande

Ensuite, nous envoyons un message sur WhatsApp, car nous initions la conversation, nous devons utiliser un message modèle, également connu sous le nom de HSM. Vous devez disposer d'un message modèle approuvé avant de pouvoir passer à l'étape suivante, pour plus d'informations sur les messages modèles WhatsApp, voir ici.

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

Notez que dans le message, nous demandons au destinataire de répondre s'il souhaite changer le créneau horaire.

Capturer la réponse à la notification.

Maintenant que nous avons envoyé la notification, nous voulons écouter les messages entrants au cas où le client souhaite reprogrammer son heure de livraison. Cela peut facilement être fait en insérant l'étape "Attendre une réponse". Ce que cette étape fait, c'est suspendre le flux jusqu'à ce qu'elle reçoive une réponse. Vous pouvez facultativement définir une date d'expiration, mais nous allons laisser cela réglé sur les valeurs par défaut pour le moment. Nous voulons nous assurer de donner un nom à la variable de sortie, dans ce cas "réponse_commande reçue".

Décider quoi faire en fonction de la réponse.

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

En utilisant l'étape "Ramification", nous pouvons lire la réponse et nous ramifier en fonction du contenu. Dans ce cas, nous souhaitons entrer dans notre flux de reprogrammation lorsque nous recevons "A" comme réponse.

Récupérer les options de reprogrammation

Après que le destinataire a indiqué qu'il souhaite reprogrammer, nous voulons lui fournir quelques options alternatives à choisir. Nous utiliserons l'étape "Récupérer des variables" pour envoyer une demande au service de planification (qui variera en fonction de la façon dont vous gérez votre planification) pour trouver le meilleur moment alternatif. Dans notre cas, nous avons constitué un faux point de terminaison utilisant mockable.io pour les tests.

Nous prenons les créneaux horaires que nous venons de récupérer et les utilisons pour remplir notre message. Encore une fois, veillez à donner au utilisateur différentes options pour confirmer son créneau horaire préféré.

Permettre au destinataire de reprogrammer.

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

… et nous nous ramifions en fonction de l'entrée du destinataire.

Presque terminé ! Enfin, nous voulons renvoyer la réponse au service de planification pour effectivement reprogrammer la livraison.

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

N'hésitez pas à nous contacter !

Gardez à l'esprit que ceci n'est qu'un exemple simple de la façon dont cela pourrait fonctionner dans le monde réel. Nous avons vu des gens combiner toutes sortes de sources de données, de services tiers et de canaux. Le ciel est la limite.

Si vous avez un problème qui pourrait être optimisé grâce à l'automatisation de la communication, nous serions ravis de discuter avec vous. N'hésitez pas à nous contacter ici et nous pouvons organiser un rendez-vous avec un expert produit pour vous aider à développer vos idées.