Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE. And our guest today will be Michael Martin, CEO of RapidSOS. RapidSOS is an advanced emergency tech company that is commercializing technology to predict and preempt emergencies before they occur, dynamically warn people in harm's way and provide a rich data link from any device directly to first responders globally.

Together, we discuss the challenges facing 911 IT systems, the powerful impact of rich data feeds on emergency outcomes, and the role of IoT devices in enabling first time responses and predictive alerts. I highly encourage anyone who is a device manufacturer listening to consider collaborating with RapidSOS to explore how safety can be added to your value proposition.

I hope you found our conversation valuable. And I look forward to your thoughts and comments. Michael, thank you so much for joining me today.

Michael: Yeah, thanks for having me, Erik. Great to be here.

Erik: So Michael, I'm really looking forward to this conversation because RapidSOS is solving such a specific problem. Often the companies I'm talking to have a horizontal technology, maybe they're doing predictive analytics that can be applied to a number of different use cases. But you really have a specific scenario that you're addressing, which is improving the 911 response system. Before we go into the details of the company and the technology, I want to understand who you are and how did you end up in this space, which is something that I think people only think about maybe once a year when they actually use the system, but generally is not top of mine. What path led you here?

Michael: Yeah, well, it's been an extraordinary journey and an incredible privilege to work with 911 and first responders all day long. But like you said like most, most Americans, this was a system I knew very little about. I was a kid from a farm in rural Indiana, and I, after college ended up in New York City working in venture capital, and was just walking home late one night. It was like two in the morning, I lived in Spanish Harlem at the time.

So I got off the subway, I was in Lexington, and just was while back it was pretty clear. As I crossed the street, this individual cross the street, as I broke out into a light jog, he picked up his pace as well. And in that moment, your brain is just rushing, like it goes into hyperdrive, you're like, what do I do? And obviously, you immediately think about 911. But in that moment of extreme clarity, you also realize like how am I going to be able to get my cell phone out in the middle of an assault, somehow have a conversation with a 911 telecommunicator? And then like, you'll verbally articulate my name, my address, like what's occurring? Like how many ambulances would you say, Mr. Sally, we're going to need, how bad are you beat me up right now?

And actually, I was really fortunate. It came to me that I probably wasn't going to be able to do that. Uber had recently come out and I had the Uber app, and I was able to press a button. And there must have been an Uber car that was like a block away. So, as I was running from this guy, all of a sudden, there was someone else on this deserted street in Spanish Harlem at 2am and the guy jog past me, unfortunately.

And then separately, Erik, my father had an incident where he, this is a few months later, had something falling off the roof of the childhood home I grew up in rural Indiana, and there was no one at home at the time. And where I'm from, there's just very weak cell phone reception. So unfortunately, it just wasn't an environment where you could call 911 from a cell phone and get help. So it's crazy right to think that like we have WiFi at our home, so if you could call 911 over Skype or there was some other, if you could connect via the internet, it’s the first responders, you could get help, but that just didn't exist.

So, 911 I mean, it's extraordinary the work they do, but it’s 650,000 emergencies a day in the United States, nearly 4 million globally. So it is a significant scale challenge that we're trying to solve.

Erik: And you I guess, coming from this VC perspective maybe had the mindset to then think through what is the problem here? But did it immediately occurred to you the next day that there needs to be a new solution here? Or is this something that two, three years later matured slowly into a clearer idea around coalesced into RapidSOS?

Michael: I'm kind of like a scrawny little dude here. And so, it was like pretty visceral actually, moment I grew up on a farm, so I didn't really have these sorts of things happen to me. And so I initially I thought it was a user experience question: you ought to be able to just press a button and get a response.

And I was working with a friend of venture capital a time, so we decided to explore this further. And we had a rule that every week we needed to talk to 20 different 911 centers. So we just began cold calling 911 centers across the United States. And it was, Erik, I would just tell you extraordinary, like the story of RapidSOS is really a story of the broader 911 community coming together to build this technology. Like we were a set of computer nerds, and we're over 100 people now. And this community just time and time again from those very early days would receive cold calls, and these are very intense, busy jobs. And yet the 911 center director would take my call, answer a bunch of stupid questions for me, and then they would keep taking my call as we would keep learning.

So, it didn't take long to realize that this challenge was so much greater than a user experience challenge. He really was a United States; and as we've learned more, a global infrastructure challenge. So as I mentioned, you have 650,000 emergencies a day in the United States. Most of those emergencies are still traversing a 1960s largely analog voice only system. And so we live in a world where there's approximately 7 billion connected devices today with incredible amounts of information.

And when you call 911 prior to RapidSOS, they typically would not even know your name. They were literally getting less data than caller ID. And it was amazing how the system worked in light of that. I mean, it's a true testament to the people of 911. But yeah, it quickly became clear that this was a pretty significant infrastructure challenge across the country.

Erik: But I would have to kind of assume that if I just dial 911, and have my phone in my pocket, somehow, somebody's going to show up at some pointed and take care of me, that they would know they'd be able to track my location and so forth. What are the different layers of the challenges here that extend from the technical architecture down through the end user that you've had to address in building the solution as it is today?

Michael: And I think the fundamental challenge here is just the lack of data. It's basically how legacy telecom voice only system. So just to put it in perspective, a 911 call typically will come in and be limited to only 512 bytes of data. We don't live in a world where we talk about bytes of data any more, we talk about megabytes of data, like a typical internet connection, maybe 500 megabytes per second. That's 500 million bytes of data per second.

But the entirety of data in a normal level one calls will meant the 512 bytes in total. To put that in perspective, like that's less data than the very first transatlantic telegram transmitted back in 1858 between the Queen of England and President Buchanan, 160 plus years ago. So we're here we are in 2019 with an iPhone in your pocket, and in the worst moment of your life 911 does not even know your name typically.

And the challenge in solving that is that it's not just one system, it's approximately 6,000 different normal one centers that are running approximately 25,000 different systems across the United States alone. And so the result is that if you want to create this standardized system for rich emergency data, you have to figure out how to integrate into all those systems. And I think originally, had all sorts of naive assumptions about how to do that. I mean, we initially thought, oh, well, 911 centers will surely have internet, that's we're just going to put a web browser up.

And I think as you start to spend time in 911 centers and our team spends about 30,000 hours a year working with 911 centers, you learn very quickly just how this is not like really any other job. I'll never forget at very first 911 center I did today, it was a Massachusetts, it was a warm spring day, beautifully sunny outside, and I was inside listening in on my first call. And it was a mother who called after her son had committed suicide. And she was hysterical. I lasted on that phone call about 15 seconds, and I took off my headset, actually walked outside. Now, that 911 telecommunicator had to stay on the phone, figure out the address where 911 was heard, and then she'd stayed with her until an ambulance arrived eight minutes later.

And she ended that phone call and she proceeded to take calls for the rest of her 12 hour shift making like $35,000 a year. So just shipping more data over the wall, having a live video feed from inside the home or something like that would not have been helpful, it would have only have added more trauma to that incident. And so, the more time we spend working with 911, telecommunicators across the United States, we just realized the intensity of this wall and we realized we had to figure out how to slot this content into their existing software systems and their existing operating procedures.

And that really it turned out to be a pretty significant challenge. We're now seven years in. We've raised close to $100 million. And really, we're still really early from a commercial scale because we just had to keep iterating, we ultimately would work with over 4,000 first responders to build out all these tech and the plug in over 10,000 different systems across the United States.

Erik: And these first responders, I guess, they just have a laundry list of challenges that they've been dealing with for the lifetime of the system to an extent. So you have this incredible group of people that are helping your customers to an extent, that are driving the development. So what does this mean from a solution perspective? You need to get data from my phone about who I am, where I live, where I'm hopefully right now into this legacy system. Where is the data coming from right now? Then I know you have a number of partnerships, is this partnership data? How are you procuring this data that they have not had access to for the existence of the system up to the state?

Michael:  So maybe what I'll do is probably answer the first question, which is like how do we do that, and then secondly, what are the sources of the data? On the health part, because we really were working to shift the paradigm from a voice conversation in a really challenging environment to a data-driven flow. And so to do that, we studied about 12.5 million 911 calls, we looked at all the questions that the 911 telecommunicators would ask in order to get to an answer that says, you needed send advanced life support ambulance to 123 Main Street, for example.

And then we actually looked at what data would be relevant, where in the conversation, to get to that answer faster? And so there's a very large and robust data model that sits behind our architecture. And what that serves to do is to look at how we get the right data to the right place at the right time to facilitate a faster, more effective emergency response.

And then from an engineering standpoint, there's a lot of work we have to do to clean the data, credential the information, secure it, and then pass it through in a very mission critical time sensitive manner into what's typically an existing legacy software system. In some cases, it could be a 10 plus year old software system that that municipality might be using for a portion of their operations.

We've also built a large credentialing authority. So, most of our partners are extremely sensitive to their information. So the result is that they're only sending us data where a 911 center had signed up, and it's using that content. So, for example, if a 911 center isn't yet equipped to receive medical or health information, that information is not going to be passed through our platform as an example. So there's a very large geofencing component of the United States that goes through credentialing, what software systems that agency using, what are they trained up to use, what are they accepting, etc. So, there's kind of this large data model.

Erik: I'm here in Shanghai from Portland, Oregon, and then I go to Milwaukee, for example, as I move across these is different than when jurisdictions, is the type of data that can be transferred be modified by your system, according to the geography that I'm in at that point in time, how does that work for people in transit?

Michael: So, it is based off your generally quite accurate location. Location is coming from various input sources, the two largest for us are Google and Apple, and they’re smartphone operating systems. So if you call 911 when you're in transit, you'll get initial 911 jurisdiction. When your call arrives, behind the scenes the software queries us and based off the query key, and your location, and knowing the credentialing authorities of that agencies, there's a variety of information in that secure handshake that occurs. That's when we pass whatever information has been authorized to be shared around that incident.

And if you move into a new agency, if that call gets transferred, the same process occurs basically all over again where as soon as the call is at the new agency, once again, there is this secure handshake that occurs and that authorizes certain information to be shared. And then data that's not used is obviously discarded in our system. So we're not a data retention or data company.

Erik: So the data then is passed to the individual who's receiving the call, but they're still using the legacy interface. Do these interfaces already have all of the required fields? Or you then have to work with whoever's providing those interfaces to make sure that the interface can actually visualize the data?

Michael: Yeah, that was one of the things that took a lot of time is we're now about seven years in, as I mentioned. We've worked with over 70 different public safety technology vendors to interface in over 10,000 different systems. So there was a significant amount of work that went into the user experience component to that. And again, to the credit of our partners, many of them had large teams on this, so we would work with those folks. So, in a large public safety technology organizations, like for example, like a Motorola Solutions, where they have a suite of different solutions out there and a large design team, so we would partner with them to develop those interfaces. Then we would often do focus groups with their customers. So this was a multi-year process where we work with 4,000 plus first responders, we worked with over 70 different technology vendors in the space to build out those capabilities.

Erik: And right now, if I look at your website, you have four products: you have the emergency API suite, the clearing house, integration and RapidSOS portal, are these all essential and all integrated together in all situations? Or it’s a situation where one center might say I want access to the clearing house only? Can you break down the solution and just help to understand what is the decision process for somebody that's integrating this into their systems?

Michael: So you can think of us a little bit as a two sided platform. So on the input side, we have various data providers that we work with. So these are some large examples. As I mentioned, Apple, Google, and we power Ubers emergency functionality. We power some large tech to core platforms, for example, that feed data into our system. And that's through our emergency API. It's a pretty standardized modern rest in API with support for a number of different use cases, whether that's directly from a device.

We recently added support for professional monitoring centers for things like the security industry. We actually also do have an ability to do loved one notifications, or actually loop in a monitoring station. So basically, the idea is that any sort of built environment or sensor can initiate an emergency response now. And in some cases, like a car crash, it might make sense to go directly to 911 versus in other cases like a smoke alarm going off, it might make sense to verify that that incident is real, whether you confirm with a homeowner or you go through a professional monitoring station, whatever that is.

So our emergency API is a platform that ingests that initial emergency signal and any other associated data, cleans it, standardizes it, credentials it, verifies it increasingly in a sensor-driven approach, and then passes that into our emergency clearing house. It’s all of our cloud infrastructure that is built to manage the over quarter million emergency events a year. And so the clearing house is going to complete the process of the credential icing standardization securing of the data and then it passes it into one of two different outputs into the 911 center. And that might be an integrated solution which is inside one of those different 70 plus public safety technology vendors 10,000 different systems, or it might for our own product, which we call RapidSOS portal.

When we do, portal is also embedded in a bunch of different software systems. So it's like the 911 Center can choose the various interface that they want to receive the content in. But you are correct, there's four main product pieces that all fit together to manage that in emergency.

Erik: And it sounds like some of these then could be used by nonemergency agencies? So these could be used potentially, it could be integrated maybe by another technology company. I think you mentioned loved one notices. So if I want to make sure that my grandmother is okay, then I could potentially have some connected devices in her house that would just be pinging me, maybe everything is okay, or mild emergency give her a call. Is that right that there could also be then private users of the system?

Michael: That's exactly right. In fact, we did that for a number of customers today where they might have some sort of sensor and for example, in an aging in place scenario. So wearable device on someone's grandparent, and if it detects a fall, or if they just press the panic button, rather than going immediately to 911, we partner with a variety of professional monitoring services, so these are our private call centers, or we can go to the family members. And so the family members can then speak to that loved one.

And if the loved one is not responsive, or if they're in need of help, we basically can conference in 911 near the loved one and on the screen of 911 will be all the vital signs and other information from that loved one. And we can actually do that from anywhere in the world. So the telecom and data routing capabilities are in a very modern scalable cloud infrastructure which, for example, if you were calling from China and your mother was in Wisconsin, like we could help connect you to provide a response for your mother, even if she wasn't able to speak.

Erik: What is the perspective of the 911 providers today on an IoT data? Because I suppose the system is set up to take an input from a human. If you have a maybe a smartwatch that says, this person might have had a stroke, or a car that says this car might have just had an accident, is that data sufficient to trigger an emergency event? Or is there another process that type of machine data would flow through in order to result in an emergency vehicle or support being provided?

Michael: This is one of the really powerful things about switching from an analog voice call into a rich data framework is the power of more sophisticated devices and multiple data feeds to verify and provide critical contextual information around an incident. So, in the old world, you might have had a legacy smoke alarm that went off. And you may not know, is it just you burnt the pizza or the homes on fire. Versus in a modern connected home, you could have more than one sensor going off, you could have a thermostat where the temperature is rising, you can have a camera feed, verifying for image recognition that there's flaming the incident in the shot, etc.

So, what I think is really powerful here is how we can merge multiple different sensor feeds to drive that verified effective response. We've been doing a variety of testing. And in compared to those legacy flows, it's really profound in terms of the ability to accelerate response for the 911 Center, and also to help them dispatch the most appropriate units possible. Often looking at between 10 and 20 plus minutes faster response time, which is as you're probably aware, Erik, can be really profound in an emergency. I mean, in the early stages of a fire during flashover, typically growing at a rate that approaches doubling in size every 30 seconds.

So getting the fire department there 10 minutes faster is often the difference between the entire home being burned up and the damage being confined to one room.

Erik: I'm thinking about something like a car accident as well, where unfortunately had some of the people I went to school with die in car accidents in high school. And this is not unfortunately uncommon in the US just because of the issues with drinking and driving. So you could foresee a situation where there could just be a signal that this car is accelerating in such a way that indicates that the driver might be drunk or it's exceeding the speed limit by a certain rate, and that might potentially trigger than an activity. Is the system already set up to take inputs from vehicles or sensors that indicate that an event has not yet occurred but that there's a certain problem ability that an event might occur based on the data being received by the system?

Michael: We're thinking a lot about how we can partner with our various data partners to do exactly what you're describing there, Erik. Is like, are there steps where you can take actually preventative action, which obviously has the greatest impact of all? Today in the automotive space, we do have a couple different partnerships, where at the very least we're able, as soon as that impact occurs to get all the critical information directly to 911 and first responders.

So just even example that like compared to an environment where you would have an accident, and then you would need to call 911. Or perhaps you would rely on like a third party auto club or other service to call on your behalf from a call center somewhere. Now you can and instantly on the screen of 911 make model color of the vehicle, how many people are inside based off the seatbelt sensors, so there's four people buckled in crash severity using what they call Delta V, or change in velocity around the impact.

So very quickly, the 911 Center can go from taking several minutes to get a phone call, and then having a multi-minute conversation and then trying to dispatch the most appropriate unit resources to immediately understand that situation getting four ambulances out to the scene immediately. So in a life threatening medical emergency, and for which unfortunately to your point, you get this a lot in car accidents, in the US, we have nearly 6 million car accidents a year, and you have around 2 million drivers that are experienced permanent injuries, around 35,000 fatalities a year, every minute you save in a life threatening emergency like that is approximately a 2.2% reduction in mortality rates.

So the impact that we can have by taking that sensor information, and immediately getting it into the hands of 911 first responders is absolutely profound when it comes to human life around these major incidents. And so I think there's a lot we can do there.

Erik: I guess there's another way that preventative systems could be set up, which is the reverse flow. If there is maybe an active shooter situation in a mall or there's a forest fire in a particular location, you could potentially have the system already been aware of the situation but the individuals in the community not being aware of the situation. Are you able today, are you considering how to have that reverse data flow where people in the vicinity would then be receiving a message on their mobile that says move away from this location or this area's unsafe or take cover it at some sort of message that would indicate that there's a particular danger in an environment?

Michael: Yeah, we are absolutely working with 911 centers to figure out how can we more effectively manage mass events. And it's something that's pretty close to home. I got married last week, and my wife is a doctor in Las Vegas, she was there in residency during the Las Vegas shooting. And obviously, this is one of the largest mass shooting events in US history. We play a small part compared to the first responders but helping to manage many of the mass incidents we've seen over the last couple years in the United States.

And I think about like just the extraordinary challenging environment, like if you listen to the paradise fires, 911 calls, and just how quickly the center's become overwhelmed with the [inaudible 28:29]. It's a call center where in a major incident just getting totally inundated with phone calls, but there's generally a lack of situational awareness. So, one of our new products, which has been called jurisdiction view actually plots in real time all those requests for emergencies on one master view. And we actually are able to transmit the data in many cases before the phone even rings.

So now what that allows a 911 Center to do is to geographically manage a mass incident. So for example, in a less severe case, we had a major car accident and so you had 100 inbound calls around it because this happens on like the one-on-one in California. And then you had someone across town who's having a heart attack. Right now that person could be 100 callers back in the queue because 911 has to work through each of the phone calls. But now they can see that it's a distinct incident and they can actually answer that individual heart attack incident before they answer call number 48 around the car accident.

But in mass incidents, which is where you started here, Erik, we can now give them this master situational awareness view. So in the case of paradise, where you had hot embers that were blowing ahead of the main fire Friday was getting spot fires all over town, and where local authorities just had a very challenging environment to understand that operational environment, now you can start to get this master operating picture of that, which naturally leads your next point, Erik, which is then we can start to provide advance notice to people in harm's way.

And I think that is absolutely that vision that we are working towards, which is how can we actually start to warn people in advance of these incidents before they occur? And we haven't rolled out a specific product there yet. But that's certainly something that we're working on right now with a number of our public safety partners.

Erik: This is an area where this is a public need this scenario where it almost probably feels a bit strange to talk about money, but you are venture backed, and you have 100 employees, and you need to operate the business to continue developing these solutions. I see on your website, it says available at no cost to public safety agencies nationwide through RapidSOS portal or integrations. Let's say who are you're paying users, who are your free users, if you just go into a little bit of detail of what would a solution look like from the business perspective?

Michael: So after I had that experience in New York, I went to grad school. And the summer of grad school, I borrowed my dad's Prius and I drove over 1,500 miles and met with 911 centers all across the United States. And my cofounder, Nick Horlick, who was wrapping up his PhD at MIT at the time, he was actively coding our software, so we would talk every day after I spoke to 911 centers. And it felt like a seminal moment for me in that journey in figuring out like, where do we want to grow up at this idea and making it?

And we just felt strongly that the 911 community, the first responders are just doing extraordinary work, and they're under resourced, understaffed, way underpaid, and it felt like it would be a deviation from our mission to try to monetize for certainly for our core service offering around providing baseline location and coordinate around an incident the United States. And so today, we do provide that service for free to 911 centers, we cover about 90% of the US population for that.

So, most 911 centers in the United States are using our service today for every one of their emergencies. We do manage close to 400,000 incidents a day, about 150 million a year. So the business model here is really about how can we align ourselves with people that want better outcomes, and how can we allow traditional players in security, emergency response, alarm companies, digital health companies to provide a faster, more effective lower cost offering to those to their member basis.

And so our input partners pay us for this service. And then we also try to align ourselves with insurance companies as well. So you can take a given car accident as an example, and by the time you repair two vehicles, deal with the health resulting healthcare treatment cost, pay for the tow truck and other types of purchase monitored sort of incidents, you could be looking at over $100,000 of cost around that incident. So we can do things to prevent it before it occurs and to drive a faster more effective response to reduce medical treatment cost afterwards. It really is a triple win. The 911 center wins, obviously, the individual and the emergency wins, but also the insurance company also wins.

And then the other example would be new these various systems, sensors or services where getting an emergency response is an important component or an add on service. So for Uber, for example, we’ll power over 100 million Uber rides a year in the United States where we provide that blanket of protection, so that if you ever were to have a heart attack, or some sort of emergency in an Uber, it's one tap and then immediately 911 is going to know, your name, the driver’s name, make, model, color the vehicle and updated in real time your location, so all that critical information.

We've had a number of wearables companies where we power their court service offering so that if they detect a fall for a senior or some sort of health emergency, we actually facilitate the response. We also, as I mentioned, provide that monitoring function as well, so that even if it's not something that requires 911 response, we can still provide a professional that can talk to that individual, make sure they're safe, etc. So, we're really enabling our partners to offer new services in the home security, commercial security, vehicle crash response, digital health, wearables’ markets.

Erik: I'm sure there's a lot to your business that we haven't delved into. Is there anything else that you think is really critical that we cover either about how you're operating today or where you're going to as next steps as you continue to grow RapidSOS?

Michael: I think there's probably two different maybe last parting thoughts I would have. One is just for your tech audience here, which is, today we live in a world with close to 7 billion connected devices. And whether or not your device was purpose built to drive emergency response, not every wearable device was meant to play in the health by following it up space, but almost certainly, in certain incidences, the data on that device could be transformative and life-saving for the owner of that system.

So whether it's a connected building, a connected car, or wearable health device, any sort of these sensors in our environment around us, we really would like to partner to get that information into the hands of 911 to really turn that connected device into a life-saving device. So I think that's the first point.

The second point is just, I think a lot of people that just don't necessarily have a lot of visibility in the how 911 works. It's just to really say thank you on behalf of all of us to the 911 and first responder community. I mean, it's just hard to describe until you've been in one of these centers or done a ride along to describe just how intense that job is. And these are heroes that do this every single day, 12 hour shifts, and they're generally underpaid and underappreciated.

And so it's just extraordinary the work they've done on the side after work on the weekends to build this with us. I mean, it really is a collective effort of over 4,000 first responders now that has led to RapidSOS, and I'm a founder here, it's just an extraordinary privilege to work with this community.

Erik: A lot of our listeners are either working with younger IoT device, or software companies, or more legacy companies that have been building solutions for industrial for building management for decades. And a lot of them are in situations where their devices are not purpose built to identify emergencies, but do collect data that might indicate an emergency around a fire in a factory, an issue in an elevator. And I would encourage those companies to think through whether it makes sense to even just, let's put aside for a moment creating goodwill, but just from a business perspective, it might be a differentiating value proposition to say the data we're already deriving through our product can also be used to increase safety in your factory, in your ability and in your facility.

So I would encourage companies to follow up. I think this is a mission that everybody can get behind. So that's going to be an easy sell to the R&D teams to get them working on projects with RapidSOS. Michael, thank you so much, again, for taking the time to talk with us. This is really fascinating and for one, certainly keep a tab on where you continue to develop to.

Michael: Thank you, Erik. Really great to be on the show, and I appreciate the time here.

Erik: Thanks for tuning in to another edition of the industrial IoT spotlight. Don't forget to follow us on Twitter at IoTONEHQ and to check out our database of case studies on IoTone.com. If you have unique insight or a project deployment story to share, we'd love to feature you on a future edition. Write us at erik.walenza@IoTone.com.