This past spring of 2020, we ripped out all of our phone infrastructure and rebuilt it from scratch. Little did we know that a month later, our entire company would be working remotely due to COVID-19. Had we not done that, the transition to remote work would have been virtually impossible. This transition turned out to be both well-timed and overdue because in rebuilding our telecommunications at Airspace, we completely redefined what we thought was possible.
For full context, it is important to understand that Airspace is a time critical freight forwarder specializing in the most time sensitive logistics on the planet. These are anything from organs for transplant to parts for downed aircraft and machinery. If a company is losing money or a person may lose their life, they use us.
At Airspace, we have an entire team of specialists communicating with both customers and drivers 24 hours a day, 365 days a year. If you call Airspace at absolutely any time, an incredible person will answer the phone to help you. That is the promise that we make to our customers and we take it extremely seriously. A few months ago, we started feeling some creaks and cracks in our phone system: Customers reporting that they were getting a busy signal, ringing infinitely, and other things that our phone records showed no record of that should not even be possible.
Then, one night, the cracks turned into a chasm. We could not receive or place any calls whatsoever. I was on my way home and immediately turned around knowing I wasn’t going home until the problem was fixed. I called our telecommunications provider and got voicemail after voicemail since it was after hours. Once I finally tracked down someone in support, they indicated that their system was also down so my guess was as good as his as to when it would come back up. It was certainly not a confidence-building moment in our provider.
Luckily, because of the previous cracks, I had started looking into other phone systems and I was drawn to one in particular because it wasn’t really a phone system. It was a framework that allowed us to build our own phone system. It was also made by the one company that I have used in almost every application I have ever made for the last decade. Twilio had just released Flex a year earlier. It is branded as “The programmable contact center” which, as an engineer, was immediately appealing. The question was how fast could I set it up?
I bought a phone number for the impossibly low cost of $0.50 and started working through their documentation. Our phones were completely down, so all I needed at this point was a number that would route to any available ops specialist. Twilio Flex is a SaaS model, and they give you $20 for free. I had no idea how far that would get us, but in 20 minutes, I could call the number and my browser would ring. I tested with a couple of specialists and it worked like a charm. In 20 minutes and for 20 dollars, we had a solution that was better than our enterprise phone system, which cost thousands of dollars every month.
I woke up marketing and I had them contact our customers with the new temporary number. Our supervisor then sent a group text to our hundreds of drivers with the new number. Then we waited. Seconds later, the deafening silence was broken by specialists all over the room answering calls on a system that didn’t exist five minutes earlier. The next day we began the process of ripping out our enterprise contact center solution and replacing it with Twilio Flex.
What we have built in the weeks after completely overshadows what was built that night. Every phone system touts “intelligent routing”, but has a very low ceiling because it is so difficult or impossible to integrate into your main application. Almost all enterprise phone systems work in a silo, so if you want to route calls to different groups, you need to define those groups in that system. Now you have a completely separate user list that needs to be maintained — Annoying, but not the end of the world. The parameters that define what is routed to that group also live in this information silo, so the information is completely static. Routing to someone who knows a specific language is easy because that doesn’t change, but what if you wanted to route to a different group based on something that changes rapidly? For instance, what if someone who is handling a critical order should get routed to a different team than someone who is calling to inquire about an order that has already been delivered? At the time a call comes in, if your phone system cannot query your order management system, this is impossible.
So how does it work at Airspace?
The above diagram is an example of how some of our automated routing connects customers and drivers with the right specialist based on rapidly changing information. When a call comes in, we send that number to our main proprietary application and our application responds with all of the necessary information. If it is a driver, our application responds with their active orders so our specialists can have complete context and not have to search for the orders. If they aren’t on an order, it actually goes to a different team, so our specialists can handle only time-sensitive requests. If it is a customer, we route it to their specific team and their SOP is immediately shown so the specialist knows exactly how to handle their specific needs.
It is important to mention that most companies solve this problem with an Interactive Voice Response (IVR). In order to get the data they need to route the customer to the right person, they have an automated voice ask the user questions. The user can then press a number for an option or speak their choice. Let's just be honest that everyone hates these. When you can look up information from your own system about the caller, you can avoid an IVR completely and provide a faster, much more pleasurable user experience.
In an even more dynamic example, our specialists handle hundreds of orders over the course of their shift, but like most people, can only do one thing at a time. So for less than a minute they may be handling a specific order and then move on. At that moment, they have full context of that order, but if a driver or customer calls in, that call may go to a different specialist who will need to look up that order. That doesn’t sound very efficient so instead, when a call comes in, we check to see if someone is actively working on that order and, if so, we route the call directly to them. This results in saved time for the customer, the specialist handling the order, and even the specialist who no longer needed to receive the phone call.
What you don’t know can hurt you
One metric that we track tightly is something called max queue time. This is the maximum time someone has to wait before a human answers the call. At Airspace, we schedule our specialists very carefully to keep that number close to zero. Prior to implementing Flex, our phone metrics were very difficult to pull in small increments. In aggregate they showed very healthy metrics. However, when we implemented Flex, we immediately saw that there was one period of the night where queue time was very high. By factoring phone demand into how we staff our specialists, we were able to completely limit that period and reduce max queue time by over 74%.
A phone system that cannot easily communicate with your main production application is just a phone no matter what any vendor tells you. It gives your customers absolutely no value over any other company that has a phone. The amazing part is we are paying less with Twilio than our legacy enterprise provider for a system that is many many times better. At Airspace, we need vendors that are innovative and move as fast as we do. Flex is actively being built out by Twilio and we have added features that make our phone system better every single week. When you build a system on top of excellent infrastructure instead of buying it, there is no ceiling. We have yet to talk to a customer and say that their request was impossible because, with the best people and the best technology, nothing fits that description.