When you run a contact center, sometimes you need to know exactly where in the world your caller is. Perhaps they’re in an emergency situation, maybe their car has broken down, or you might need to deliver something to them. Typically, these calls end up going something like a game of "Where in the World is Carmen Sandiego?”

The caller attempts to poorly describe where they are. They might know a street name or nearby landmark, such as “the McDonald’s in front of the big church.” The agent is then left frantically searching different databases or Google Maps in an attempt to locate the caller. This could go back and forth for minutes, frustrating both caller and agent, and potentially extending the time a person is stuck in a dangerous situation.

In a recent meeting with a contact centre manager, she advised me that the process of locating a customer took, on average, about two minutes. That two minutes equates to something in the ballpark of £7 ($10) per call for the average contact centre. The go-to topics at this point in the conversation are usually chatbots or call deflection to reduce handle times and free up agents for more meaningful tasks.

While there is definitely merit in those tools for some contact centres, I know that if I was stranded on the side of the road, the thought of having to rely on HAL 900, Pumpkin Spice Latte, or whatever your cute chatbot is called would make me feel like setting fire to the car and walking home.

The other option is providing an in-app experience. Certainly you could implement some click-to-call functionality and provide coordinates from the app to the agent. The problem is: how many of your customers actually have your app installed? And how many of those customers are looking to use your app when they’re in trouble?

Most are probably reaching for the phone icon in this situation. They know the interface, they are familiar with the experience of making a phone call, and don’t need to install anything. Navigating an unfamiliar app only serves to add to the stress they are already facing.

What if your contact centre could provide an omnichannel experience that sent an SMS to a customer while they were on the phone, linked them to a webpage that could determine their location, and then displayed that location to the agent when they answered the call? The GIF below demonstrates this experience in action. The right hand side is the customer’s phone, the left is a contact centre agent using Twilio Flex.

Why did I choose this approach? As you can see, I’ve used the phone, SMS app, and browser: all apps that have been in every smartphone for more than ten years. Customers know how to use them intuitively. Developers can use the React architecture adopted by Flex to create components with ease that provide necessary information to an agent. It’s not necessary to have a specialised skill set in a particular contact centre vendor interface.

As a business, I can use my internal teams to own my product roadmap, make changes to my contact centre as quickly as I make changes to my corporate website, and I don’t need to invest in huge professional services engagements or just hope that a vendor will implement the features I need.

Finally, but crucially, as an agent, I’m armed with knowledge. Now I can focus on getting this customer somewhere safe and send a patrol on its way faster than ever.

Let’s step through the call flow now.

1. Caller dials a Twilio number and is directed to a Studio flow which connects them to an IVR.(Studio is Twilio’s visual drag and drop editor that allows developers to get their ideas up and running without having to write a lot of code for the things they do every day on Twilio.)

2. The IVR requests permission to send an SMS to the caller. If accepted, the caller is placed in a queue and is advised to stay on the phone, click the link in the SMS, confirm their location, and then return to the call.

3. Caller stays on the phone, receives an SMS, and taps the link in the SMS.This opens the native browser. The caller is prompted by the browser to allow the website to know their location. The caller accepts and is presented a Google Maps view of their current location using the coordinates of the device.

4. Caller confirms location through mobile browser. The caller taps the confirm location button and is advised to return to the call.

5. Location is written to a Twilio Sync document, identifiable by the caller's phone number.

Twilio Sync is a State Management API. It persists state in the cloud and synchronises across devices. It also uses mobile and web SDKs for easy access from your own applications.

6. A task is created with the caller’s latitude and longitude; the caller is enqueued to Twilio Flex.

The location server is instructed to dequeue the call. During this process, it searches for the Sync document associated with this call. It reads the coordinate values in the Sync document and appends them to the attributes of the task.

7. Agent accepts the task and is connected to the caller.

8. Flex plugin replaces the CRM container with a Google Maps view showing the caller's location. A simple search is carried out using the latitude and longitude as parameters in the Google Maps URL.

A detailed view of this call flow is below.

You may be wondering where the location server has come from and if Twilio only works with Google Maps?

First, the location server. It’s responsible for being the go between for your customer and your agent to provide the location information. It communicates with a map API (Google in my case), Twilio, and provides the front end template to the customer to confirm their location. This sits within your own infrastructure; it is not provided by Twilio. It may be something you already have running, or if you don’t have one, you can deploy my code from Github with a single click to Heroku here. Here you will find instructions to create a Twilio Flex instance, provision the IVR in Studio with a simple JSON import, and to create the Flex plugin. That gets you all the necessary Twilio pieces.

The final piece is the one-click deployment to Heroku to get you well on your way to demonstrating your own proof of concept. I’ve created a location server using Flask (a Python web framework) that makes the necessary API requests out to Twilio and Google to provide the functionality. It also serves up the necessary HTML/Javascript to display the location confirmation workflow to the caller.

As with all things Twilio, if you have your own location server, have a different map provider of choice, or wrongly feel that Python isn’t amazing, you can absolutely swap in your choices and build out a similar experience for your customers.

Of course, the possibilities don’t end there. You could use all that Sync information to create a dashboard showing where all your customers are calling from and start making some real-time decisions. Do you need to move patrols closer to certain locations where there is an obvious problem?

You could also surface weather information for those coordinates to an agent. With this information, an agent can display empathy, such as advise the customer to remain in the car with the heater on or seek shelter at a nearby service station. This information can be sent directly to patrols as well, who will now be able to pinpoint exactly where the caller is located.

Maybe you even want to go as far as to provide a Twilio number to the caller that they can reach the patrol on? Through the use of Twilio Proxy, you could establish a session for each job, the caller and patrol numbers remain anonymous, you can record the calls, and you can provide analytics. As you can see, the possibilities are plentiful.

I can’t wait to see what you build! I’d love to hear your ideas or help out where I can.

LinkedIn: https://www.linkedin.com/in/stuartlogan82/
Twitter: @stuartlogan82
Github: https://github.com/stuartlogan82