How to automate resolving queries that don’t need a human response

How to automate resolving queries that don’t need a human response

How to automate resolving queries that don’t need a human response

Jan 10, 2020

Published by

Published by

MessageBird

MessageBird

Category:

Category:

Automation

Automation

Ready to see Bird
in action?

Ready to see Bird
in action?

How to automate resolving queries that don’t need a human response

This post is part of a series on optimizing customer support operations. In it, we cover how to free up your team by automating the resolution of standardized inquiries.


Manually looking up information is highly inefficient

If you are anything like other businesses, chances are high you see a clear pattern in the type of incoming support questions. But at times, the answer to those questions can turn out to be repetitive as well.


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


In both examples, reps have to look up a standardized piece of information, state it back to the inquirer and perform some action to handle the response. These types of structured flows are perfect for automation, which gives your reps back time to spend on complex issues.


Why isn’t everyone prioritizing their incoming inquiries?

Unfortunately, up until recently, communication automation has been inaccessible. Building complex flows required expensive telecommunications tooling and significant engineering time. That is why we built Flow Builder, a communication automation platform that empowers cross-functional teams to collaborate on communication flow. It allows you to run logic, pulls in data from external data sources and performs actions in third party services.


This is how you do it

In this how-to we will be looking at a company tasked with delivering parcels. Two major drivers of cost for these types of companies are couriers arriving at a location where the recipient is not available to receive the package, and recipients calling in with questions around the status of their delivery or changes to the delivery. Our objective will be to reduce the amount of times a courier arrives at a closed door and reduce the load on the contact center.

What we are trying to achieve:

  • Send a notification with the initial order update.

  • Catch the reply to the notification.

  • Decide what to do based on the reply.

  • Fetch rescheduling options

  • Allow the recipient to reschedule.

Send a notification with the initial order update.

While there are various ways to automate incoming inquiries, the best way to reduce the load on contact centres is for customers not to reach out in the first place. The most effective way to realise that is to keep them proactively informed before their issues arise. The added benefit is that by doing this, we also establish a communication channel which allows us to steer them to the right resources with minimal human involvement.


We will start by identifying an event we want to use to initiate the flow. In the case of our delivery company, we will want to reach out to the customer the moment the parcel gets scheduled for delivery. This event can occur in a variety of systems, depending on your setup. The key here is that we need to call a webhook from that system the moment this happens, which will initiate the flow.


On the right, you can see we have chosen a Webhook as the trigger and configured different variables we are expecting to receive as part of the incoming webhook.


  • phone - The phone number of the recipient

  • firstName - The first name of the recipient

  • deliverySlot - 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 to the next step, for more information about WhatsApp template messages see here.


When you have an approved WhatsApp template message it will show up in your Flow Builder ready to be used. We take the firstName from the incoming webhook and the timeslot copy from the delivery slot to populate the message.


Note that in the message we are prompting the recipient to reply if they want to change the time slot.



Catch the reply to the notification.

Now that we’ve sent out the notification we want to listen for incoming messages in case the customer is looking to reschedule their delivery time. This can easily be done by dropping in the “Wait for a response” step. What this step does is pause the flow until it receives a reply. You can optionally set an expiration date, but we’ll leave that set to its defaults for now. We do want to make sure to give the variable output a name, in this case “order_received_reply”.



Decide what to do based on the reply.

Depending on the reply by recipient we’ll want to make a decision. In our example we are only looking for customers who reply with the letter A, but you can imagine a scenario where you add multiple reply options.


Using the “Branch” step we can read the reply and branch of depending on the contents. In this case we want to branch into our rescheduling flow when we receive “A” as a reply.



Fetch rescheduling options

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.



We take the timeslots we just fetched and use them to populate our message. Again make sure to prompt the user with different options to confirm their preferred timeslot.



Allow the recipient to reschedule.

Again, we tell the flow to wait for a response by using the “Wait for a response” step...



… and branch out depending on the recipient input.



Almost done! Lastly, we want to pass the reply back to the scheduling service to actually reschedule the delivery.


And to finish it off, we send a message confirming the new delivery date.



Feel free to reach out!

Keep in mind, this is just a simple example of how it could work in the real world. We have seen people combine all sorts of data sources, third party services and channels. Sky's the limit.


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.

Your new standard in Marketing, Payments & Sales. It's Bird

The right message -> to the right person -> at the right time.

Your new standard in Marketing, Payments & Sales. It's Bird

The right message -> to the right person -> at the right time.