RapidSOS 了解到最好的产品设计有时是没有产品设计

对于 RapidSOS 的创始人来说，通过向 911 呼叫添加有用数据（例如位置）来提高应急响应的质量是一个鼓舞人心的目标，并且获得了广泛的支持。只有一个问题：他们将如何创建可行的业务？美国大约 5,700 个公共安全回答点 (PSAP) 并不是很好的竞争者。由于资金紧张且高度分散，911 中心已经将微薄的预算用于人员配备和维护已有数十年历史的设备，而且他们几乎没有资源来改进系统。此外，国会关于中心现代化的拨款法案已经搁置了十多年，我们将在本 EC-1 的第四部分中进一步探讨这个主题。人们显然希望得到更好的紧急服务——毕竟，他们终有一天会拨打 911 并寻求帮助。然而，在紧急情况真正发生之前，他们从不考虑紧急情况，因为 RapidSOS 从我们在第一部分讨论的其 Haven 应用程序的采用率低中学到了。人们还没有准备好提前为这些服务支付月费。那么，谁来支付？谁对美国陈旧的 911 系统感到恼火，愿意花钱修理它？最终，该公司将自己迭代成一个 API 层，一方面是数千个 PSAP，另一方面是应用程序和消费者设备的开发人员。这些开发人员希望在他们的产品中包含安全功能，但不想在数千个不同的机构之间设计数百个软件集成。因此，RapidSOS 的商业模式变成了向 911 呼叫中心提供免费软件，同时向通过其平台连接的科技公司收费。这是一条艰难的道路，也是一个典型的先有鸡还是先有蛋的问题。如果没有呼叫中心集成，科技公司就不会使用 API——在那种情况下它基本上是无用的。就呼叫中心而言，他们不想使用没有任何直接价值的软件，即使它是免费赠送的。这是一个故事，讲述了 RapidSOS 如何从 2017 年起克服这些逆风，最终为自己筹集了数亿美元的风险投资、数千名呼叫代理客户、与 Apple、Google 和 Uber 等公司达成的数十项收入交易，以及与比任何初创公司都有权保护的软件集成商更多。明智的产品决策、精心校准的商业模式和坚韧最终将使公司获得逃逸速度，不仅在美国扩张，而且在全球范围内也越来越多。

在 EC-1 的第二部分，我将分析 RapidSOS 当前的产品供应和业务战略，探索该公司从消费者应用程序到嵌入式技术的支点，并了解其新兴但不断增长的国际扩张努力。它提供了关于迭代的重要性、如何确保正确的客户反馈以及确定最佳产品策略的关键课程。从 RapidSOS 旅程的最初阶段就很清楚，将数据输入 911 中心将是其第一个关键挑战。整个 911 系统——即使在今天在大多数州——都是为语音而不是数据而构建的。我们在介绍中认识的 RapidSOS 公共安全高级主管 Karin Marquez 在丹佛附近的 PSAP 工作了数十年，从接听电话到高级主管。 “当我开始时，它是一个单人调度中心。所以，我一个人工作，接听 911 电话、非紧急电话、派遣警察、消防和紧急医疗服务，”她说。作为 911 接听员，她对每个电话的第一个要求是弄清楚紧急情况发生的位置——甚至在描述正在发生的事情之前。 “一切都从位置开始，”她说。 “如果我不知道你在哪里，我就不能派你帮忙。我们可以开始建造房屋的其他一切。每一个额外的数据 [点] 将有助于让我们更好地了解紧急情况是什么，可能涉及谁，他们涉及哪种车辆——但如果我没有地址，我就无法发送你帮忙。”