原文：https://blog.chartmogul.com/api-based-saas // 原文是一个访谈，本文为机翻+人工校对。 下文中用//标识我的一些想法
摘要：在这一集中，我与Clearbit联合创始人兼首席执行官Alex MacCaw进行了交谈，他认为基于API的产品将成为下一代企业软件的原因：自2009年首次融资以来，该平台在几年内取得了显著的发展，现在为可口可乐，Uber和EMC2等大型企业运行电信基础设施。 一旦集成到您的平台上，在剥离功能并取代它时，有一个非常真实的 "痛苦"，要么用另一个产品，要么用自己的业务逻辑（这将不可避免地需要自己的开发团队开发）.相比让他们在已有的精致用户界面中点击注册并支付，显然说服客户使用集成API后排期开发会遇到更多的困难。
我们正在进入一个基于企业云的产品的新时代。这个时代赋予开发者权力，为基于互联网的软件的未来创造了基石。但这种新型的无界面产品并非没有一系列新的挑战…
企业软件的构建、分布和消费方式已经发生了一些关键性的转变。从内部托管解决方案的时代，需要定制系统和顾问团队来实现高效运营，到如今基于云计算的解决方案，注重良好的用户体验，几乎不需要上岗，为客户提供更灵活的价格。 但是，就在全世界都意识到设计和用户体验在企业产品中的重要性的时候--可以说是在消费市场看到同样的演变之后的几年，出现了一种新的B2B解决方案——基于api的SaaS。它完全抛弃了视觉上的用户体验。
这样的服务有几个相当难以忽视的特征。
Clearbit正在建立一个Business Intellgence API的集合，目标是成为许多企业的BI后台。与大多数基于API的产品一样，价值在于Clearbit通过简单、易于使用的界面提供的数据。
Contentful是一个新品种的CMS，它是为我们今天所处的多设备世界而建立的，与许多 "传统 "CMS产品不同。它是如何管理的呢？当然是通过API。Contentful团队在设备不可知的空间里，减少了很多管理内容的复杂性。
看起来Twilio将成为第一个真正基于API的SaaS在2016年上市。自2009年首次融资以来，该平台在这些年里取得了显著的发展，现在为可口可乐、Uber和EMC2等大型企业运行电信基础设施。而且都是通过一个API!
Algolia为搜索提供了一个API，让SaaS厂商能够有效地将处理其应用中高级、高性能搜索的复杂性外包出去--这在技术上是很难实现的。像ProductHunt、Medium和Birchbox这样的应用中的搜索功能都是由Algolia提供的! // 国内云服务商厂商提供了基于搜索场景的paas服务
一旦集成到您的平台上，就会有一个非常真实的 "痛苦"，那就是将功能剥离出来，然后用其他产品或自己实现（这将不可避免地需要自有研发团队开发）来取代它。这可能意味着，即使在存在更便宜（或功能上更优越）的解决方案的情况下，仍然可能没有足够的动力去转向这样的竞争对手。 // 这种有点像是iaas或pass服务的优势。迁移成本极大，很多非api的saas产品通过承载用数据来提高迁移成本，从而减少流失。
围绕着一个基于API的产品，很难再添加 "营销的噱头"。因此，客户更容易清楚地看到解决方案为其业务带来的价值，特别是当解决方案只是为他们提供一些数据时。所以要更多关注提供的价值。 // 为噱头买单还是为价值买单，前者的复购率和留存不会太理想。
例如，如果你正在构建一个基于API的SaaS产品，有些关键的东西你不需要考虑。 当然，这并不是说有了API就什么都简单了（见下面的挑战），但你有一个很好的机会来运行一个很大程度上简化的软件栈，可以扩展到大量的请求。
如果你的首次接入目标是让你的客户尽快达到他们的 "Aha时刻"，那么当客户需要在这之前花费开发时间来整合你的API时，这可能是一个挑战。首次接入的风险更大。 我采访了Contentful的首席执行官Sascha Konietzke，以了解他对构建和发展基于API的产品的一些挑战的看法，特别是在入职客户时。以下是他的看法。 绕过接入挑战的一个常见策略是提供一套与现有平台的集成。 当API有一套相当常见的用例，并且它们涉及到与现有服务的集成时，这特别有用。你基本上是在做（建立集成的）工作，这样你的客户就不必去做。最终的结果往往是 "一键式 "连接，而不是数周的开发和测试。 举个例子。Clearbit提供了与Google Sheets、Close.io、Salesforce、Marketo和Slack的预建集成。
这与首次接入使用的差异有直接关系。说服客户使用集成API，并将所需的工作融入到他们的开发周期中，显然比让他们在一个精致的用户界面中点击注册，并输入他们的支付细节要有更高的障碍。你还需要考虑延长你的试用期，以考虑到接入时客户增加的研发工作量。 // 类似 提供迁移工具（音乐软件之间相互迁移），在iaas服务中，如何减少用户迁移成本是一个必须考虑的点。
你为服务定价的选择会大大减少。通常情况下，对于面向数据的服务，你会看到可扩展的基于数量的定价，即根据你对API的请求数量来定价。当产品被拆成基于API的微服务时，你会发现很难根据功能或其他因素来扩展定价方案。 // 国内私有部署方案是一个可选择定价点
从积极的一面来看，你将会留下一组较小的产品，每个产品都有自己的、更简单的定价结构，而不是一个产品有很多不同的定价维度。这是一个很好的方式，让你的客户选择他们需要的解决方案的不同部分，只为对他们有价值的东西付费。 举个例子。Contentful的定价是基于你在他们那里存储的数据量 以及你向他们的API发出的请求数量。 // 让我想起一种saas产品，店铺类saas，店铺基本功能，营销功能，外观定制功能单独分开定价，按需购买。对产品架构有不小的挑战。
营销一个SaaS产品，很重要的一点就是要想方设法把你的解决方案的价值传达给目标客户（并使之可视化）。即使你的产品有一个高度视觉化、精心设计的UI，在最好的时候，这项工作也不容易。但如果把这个UI完全去掉，你就几乎没有办法把产品真正展示给你的目标客户。解决方法是什么？你必须找到一种方法来将产品所提供的价值可视化，而不是产品本身。
你很可能不仅要向企业主和决策者进行营销，还要向开发人员进行营销--他们将面临整合你的API的任务。如果你真的想销售你的产品，你必须赢得这两方面的支持。 // 你必须分析购买决策链条上面的每一个角色，进行归类和针对性的营销动作。
举个例子。Twilio通过举办开发者大会、赠送小礼品、提供代码示例和交互式集成指南等知识库来赢得开发者的青睐。
所以，很明显，销售和消费基于API的产品都有很大的好处。但是，如果你已经提供了一个 "全面的 "SaaS解决方案，你是否应该考虑将其中的部分内容作为独立的服务来提供呢？以下是你应该首先考虑的几个问题。 我的产品中是否有一些领域可以被分解成更小的独立服务？ 你的产品中是否有一些小的领域可以为客户提供一些孤立的价值？这些都是可拆解并通过API单独提供的主要候选者。 我的产品价值与它所提供的数据有关吗？ 如果答案是 "是"，您可能需要考虑以程序化的方式（通过API）提供对这些数据的访问，并使客户能够在您的数据之上构建平台和服务。 我的产品是否经常被用作客户解决方案的核心部分？ 如果是这样，你看到企业在你的解决方案之上建立额外的价值，如果你通过API提供你产品的这一部分，他们可能会更容易做到这一点。许多SaaS企业的梦想是成为一个平台或生态系统--你只需看看Salesforce AppExchange就知道，这开启了一个充满可能性的世界。
通过API提供价值的SaaS企业的运动，从大的方面来说，可能看起来并不是什么大事情。人类永远都需要能够被人类使用的产品和服务，通过某种形式的界面进行互动（尽管这个领域发生了微妙的变化，基于即时通讯的应用增长强劲）。 然而，当 "下一代 "初创企业在有限的资金和时间内完成打造产品的艰巨任务时，他们将有一个新的选择摆在桌面上。
我们有新一代的SaaS，使用一系列现有的基于API的服务的构件构建，可以更加可预测地评估其服务的成本 我们已经开始看到这种情况，甚至在一些更成熟的初创企业中也是如此。但在未来几年，我们很可能会在更大程度上看到这一点，因为越来越多的功能适合通过API进行 "外包"。 剩下的唯一问题是“有什么东西，5年后还能再从头开始建造？”
