As an Insurer you know that there is an opportunity to communicate with your homeowner policyholders in the little advanced notice you have before a CAT hits. While call solutions have become the fastest and most effective way to connect with policyholders, certain technology still holds limitations. Making CAT notification calls an interesting technical challenge, not only because of the gravity of the situation, because of the importance of getting the best customer connections.
As we wind down from another hurricane season along the Atlantic coast, I am reflecting on the improvements we have made to our catastrophe (CAT) notification infrastructure. To continue to deploy high volumes of automated voice (phone) calls and SMS (text) messages quickly, SPLICE needed processing power to run our messaging software platform, and we needed access to telephone channels.
In years gone by, this would have all physically been housed in a nearby datacenter. If we wanted to double our call capacity, for example, we would have had to go to this datacenter and wire up physical servers, and then negotiate more phone channels with our telecom providers. Fortunately for us, we live in the “Cloud Computing” era, so SPLICE sought out partnership that allowed us to securely scale our infrastructure to meet CAT demands.
Amazon Web Services (AWS) and Twilio gave us the ability to optimize our infrastructure in a way that did not compromise security or require excessive resources. AWS not only promised to eliminate the physical server rack, it also deconstructed the notion of a computer, replacing it instead with a group of corresponding “Micro-services”.
In using this, SPLICE was able to create an infinite number of tiny messaging services, all pulling data out of an infinitely large hard drive, and all of this scaling was done automatically by us. Now we can go from a small baseline of 100,000 calls a week to many millions of calls in a couple of days.
The missing piece of this puzzle, however, was still the phone lines. Having the processing power to make 10,000 concurrent calls does not mean the world was able to support them with the existing telephone infrastructure.
You may be familiar with this scenario: have you ever tried to call your family on Thanksgiving, in a rural area, and not been able to get a line? Well, this is due to something called “overloading a switch”. In a CAT scenario, you can’t afford to have this issue. This is where Twillio came in; they are known for a great SMS API, and are an excellent aggregator of telephone infrastructure. Through this partnership, SPLICE was able draw from a functionally limitless pool of phone channels, essentially bypassing a hard “Analog” limit of dealing with phone infrastructure. So we mitigate risk by quickly rotating through different calling areas, and using automated retries to ensure that all messages are absolutely supported by physical infrastructure.
If you’re unfamiliar with APIs, click here for an informational White Paper!
SMS messages have a similar volume limitation that can be worked around with two options. The first is something called shortcodes. In using these, carriers will not throttle the messages, but the messages seem less local and personal. To solve this, SPLICE used the second option called number pooling - which is my preferred solution. Here we were able to draw from a very large pool of local numbers, and send messages from them, resulting in a much higher rate of reaching people. What’s more is that all replies and further contact is sent from the same number to keep a consistent experience for the policyholder.
When we are on the clock with a natural disaster on the horizon, it is comforting to know that we will always be able to notify a greater volume of people in a shorter period of time. Having scalable infrastructure, like we do, means we will never have to sit on our hands and hope for the best. These rich APIs also allow us to fully integrate our preference & customization features, so that we’re able to provide a meaningful experience for our clients and their policyholders.