卖给大公司？ 支持是不够的，您需要投资于客户的成功——为了他们自己和您的利益。

在过去的十年中，客户成功 (CS) 已经发展到现在被认为是 SaaS 业务的支柱，与产品、工程、营销和销售同等重要。

在这篇关于 CS 的两部分系列文章的第一部分中，我将解释我们如何在 Proposify 建立一个 CS 团队的历史（我来领导这个团队一段时间，我招募了一个 VP），如何实施 您自己的 SaaS 业务中的 CS 策略，以及跟踪客户成功的指标。

首先，让我们弄清楚客户成功的真正含义。

你只是说支持，对吧？

客户成功有一个不幸的名字，因为它经常与客户支持互换使用，但两者是不同的。

• 客户支持是技术性的和被动的。
• 客户成功具有战略性和主动性。

支持很重要——当客户感到困惑或遇到问题时，他们需要得到快速友好的帮助——但客户的成功是不同的。它专注于您的软件实现的业务成果。

客户成功了解每个客户的期望结果，并为成功设定个性化基准。他们监控帐户问题，例如功能使用不当或整体使用下降，并伸出援手提供指导。他们加入每个新帐户并帮助他们尽快从产品中获得价值。他们全年定期使用他们的每个帐户审查该软件，以展示它所提供的商业价值。

在 Proposify，我们在 2017 年开始看到客户成功的必要性，因为我们开始向高端市场销售，向拥有大型销售团队的中端市场和企业业务销售。在那之前，我们只有一个客户支持部门来帮助我们的整个客户群，但我们的大客户遇到了他们使用水平固有的问题，需要更积极主动的外展服务。

在过去的一年半里，经过大量学习和一些挫折，我很高兴地说我们拥有一支由 3 名客户成功经理 (CSM)、一名实施专家和一名副总裁组成的出色的客户成功团队，康纳，管理部门。

雇用农民

通常，当您雇用销售人员时，您需要猎人。你想要的人都是要到野外去，跟踪线索，完成交易。

客户成功经理的心态则完全相反。 CSM 就像农民；他们是那种会审视一段关系并制定计划以培养这种机会以最大限度地发挥长期潜力的人。 CS 准备好土壤，播下种子，并将幼苗培育成一棵强壮、健康的树。

他们知道这需要随着时间的推移建立成功的关系。这种长期的远见对 CS 的思维方式至关重要。这是一场马拉松，而不是短跑。

除了在客户成功方面的专业知识外，吸引在您所服务的类别或市场具有一定专业知识的 CSM 也非常有益。例如，我投资的一家公司 Cribcut 为发型师提供服务。所以他们的 CSM 是——你猜对了——发型师本身。在 Proposify，我们向销售人员和销售经理销售产品，因此我们 CS 团队中的大多数人都在以前的职位上做过销售。

为了有效，我们的 CSM 需要知道要问的正确问题，例如，“您的销售周期通常是多长时间？你的收盘价是多少？您在销售漏斗的哪个阶段发送提案？”拥有这些内幕知识有助于您的 CSM 将自己确立为客户值得信赖的顾问。这不仅仅是关于如何使用你的软件，而是关于软件如何解决他们的业务问题。

您的客户需要多大才能保证 CS 经理？

假设你是像 Netflix 一样的 B2C，向消费者销售产品——你可能有数百万客户，但他们每个人每月只带来 12 美元。而且，显然，我们没有人曾与 Netflix 的客户成功经理交谈过，以确保我们对正在观看的电影感到满意。

但是，如果我们每年向 Netflix 支付 50,000 美元，他们将真正确保将我们保留为客户。他们可能会实施策略来确保我们对服务的幸福和满意。 （天哪，以这个价格，我们应该可以在《怪奇物语》系列中闲逛）

上面的例子（12 美元对 5 万美元）过于简单化了。现实要混乱得多。您可能不应该为 1,000 美元/年的客户提供专门的客户成功经理，但界限并不总是很清楚。这在很大程度上取决于您可以在没有 CS 的情况下让您的客户取得多大的成功。一些客户可能很乐意每年支付六位数的费用，并且不需要 CSM。但是，一些较小的客户可能需要更高的触摸流程才能完全加入。如果没有它就无法留住他们，那么从长远来看，不向那些价值 1000 美元的客户提供该服务的成本可能会更高。

所以答案是，这取决于。要坚持的一般规则是将总合同价值的 10% 投资于客户成功。

假设您有一个昂贵的企业产品（六或七位数），您的销售代表需要 18 个月才能完成交易。这不是您想要流失的帐户，因此您需要投入大量资金来确保该客户的成功。这可能意味着每个季度都会让 CSM 亲自开会，并有一个专门的入职团队推出产品以进行复杂的实施。

但是对于合同价值小得多的账户，比如每年 1 万美元，客户成功手册看起来会大不相同。在这种情况下，这可能就像让 CSM 在启动电话会议上跳起来一样简单，也许每年进行一次培训课程并通过电话检查以进行续订 - 或者如果帐户存在明显问题，则更频繁。这确实是加入、保留和扩展该帐户所需的一切，但在合理范围内。

CS的关键绩效指标是什么？

客户成功的最终目标是加入、保留和扩大客户。

在基于订阅的业务中，您成功的基本指标是每月经常性收入 MRR 的增长。 增长的敌人是流失——由于取消而损失的经常性收入（也就是净 MRR 流失）。 随着 SaaS 业务的 ARR 超过 500 万美元，客户流失确实占据了上风。 客户取消或降级帐户会很快影响 MRR 的增长。

如果客户流失被最小化，并且更多的客户正在升级而不是降级或取消，那么基本上你可以实现负流失。 负流失是 SaaS 的圣杯，因为它意味着指数级增长。

积极的流失会扼杀增长。负流失会加速它。

所以 CS 团队应该主要负责客户流失，包括扩张 MRR（现有客户升级了多少）和收缩 MRR（由于降级而损失的收入）。

情况会变得更好：如果负流失率成倍增加收入，那么账户扩张会复合成指数增长。我将在下周的第 2 部分中深入探讨为什么 CS 应该参与追加销售账户以及何时是这样做的最佳时机。

客户成功与产品团队的关系

一些 SaaS 企业将净推荐值 (NPS) 分配给 CS 团队而不是产品团队。这不是我们在 Proposify 的做法，因为他们对您的产品中实际构建的内容没有任何控制权。

但是，另一方面，让 CS 负责 NPS 分数确实会给他们在决定构建什么时产生一些影响。 （如果你错过了，我在之前的文章中谈到了 Proposify 团队如何决定构建哪些功能。）

无论谁拥有该号码，客户成功都是客户的声音，他们必须传达用户卡在哪里、造成最大麻烦的原因，甚至是因为产品缺乏特定功能而失去账户的情况。在您的客户成功团队和您的产品团队之间建立良好的合作伙伴关系和持续沟通非常重要。

我们的 CS 团队定期与我们的首席产品官 Ricky Ferris 会面，分享他们的学习成果，其中一些人将担任某些项目的利益相关者，这样他们就可以为构建新功能的设计师和工程师提供客户的声音。

Comp 是什么样子的？

关于如何最好地补偿客户成功经理有很多不同的想法。

不像销售佣金完全取决于他们完成的交易，因此非常简单，CS 是一个长期的游戏。因此，补偿看起来有很大不同。我设计了一个模型，我们已经在 Proposify 开始实施。

每个季度，我们都会查看每个 CSM 的客户流失率。他们的流失率越高，他们的奖金就越低。流失率越低，他们的奖金就越高。如果他们的流失率高于零，他们几乎一无所获。如果他们的流失率是负数，则意味着他们一直在扩大账户，奖金成为克拉克·格里斯沃尔德的地下泳池梦想的基础。

即使您的销售代表没有达成任何新交易，您的收入仍在增长，这要归功于您的客户服务团队。 这就是负面 MRR 流失的强大程度。

我觉得这个模型很有意义。 这至少是值得一试的。 有很多不同的模型可以用来衡量客户的成功，但这是最接近负流失率的模型，这是 CS 部门的关键绩效指标。 它在理论上是有效的，但我会在以后的一集中检查它是如何工作的。 康纳可能最终也会改变这一点。

在下周的帖子中，我将准确介绍客户成功如何降低客户流失率并提高生命周期价值。

您在业务中实施了哪些 CS 策略？ 我们在 Proposify 所做的事情是否引起了您的共鸣？ 如果是这样，请在评论中告诉我！

不再支持圣地亚哥发布。因此，产品文档和发行说明仅供参考，不会更新。

公共服务数据模型（CSDM）是您在设置ServiceNow®应用程序时可以遵循的框架或蓝图。遵循该模型可确保应用程序的数据正确映射到相应的表。

下图说明了CSDM概念模型以及各种角色和用户角色如何使用该模型。它确定了CSDM框架中的每个域（基础、设计、构建、管理技术服务和销售/消费）。Manage Portfolio域包含所有其他域的一部分。此图显示了域如何协同工作来管理ServiceNow应用程序和服务。

CSDM概念模型中的每个域都与一个或多个产品、服务或服务类型相关联，您可以根据需要对其进行扩展。

CSDM概念模型

CSDM域

• Foundation域表示包含从其他CSDM域中的对象引用的基本数据的表。
• Design域表示ServiceNow®应用程序组合管理（APM）当前使用的表。
• Build域表示在DevOps等数字产品的构建工作中使用的表。
• 管理技术服务域表示ServiceNow®IT运营管理（ITOM）当前使用的表，如服务映射和发现。
• Sell/Consume域表示Service Portfolio Management（）和Customer Service Management当前使用的表。
• ManagePortfolio域包含所有五个域的一部分。

服务和服务类型

服务使您能够在不产生成本的情况下，以最小的风险实现您想要的结果。此定义与ITIL v3和IT4IT中“服务”的基本定义一致。服务通常有三个组成部分：交互、产品和服务系统。

基本系统服务类型

ServiceNow包括这些基本系统服务类型，您可以扩展这些类型以与组织中的服务类型保持一致。

应用程序服务（应用程序服务表[cmdb_ci_Service_auto]）

• 应用程序服务是已部署的应用程序堆栈的逻辑表示。

注意：有关叶节点和结构化层次结构的详细信息，请参见设计域。

• 应用程序服务密钥详细信息（应用程序服务表[cmdb_ci_service_auto]）。
  • 它是一个可操作的CI，也是应用程序的唯一实例。
  • 用于偶发事件、问题和更改。
  • 可以为每个区域和每个环境（开发、QA和生产）创建。
  • 可以通过手动映射、带入口点的服务映射和动态查询来创建。

业务服务（cmdb_ci_service_Business）

业务服务与业务用户相关联。业务服务通常是一个或多个业务功能的基础。

业务服务关键细节：

• 它是一个可操作的CI，可以是一个级别。它不能是业务服务的层次结构。
• 用于事件、问题和更改中的影响。
• 也用于变更审批。
• 必须以消费者或卖家为中心。

技术服务（cmdb_ci_service_Technical）

技术服务与服务所有者相关。技术服务通常是结构化层次结构中一个或多个业务或应用程序服务的较低级别叶节点。

技术服务关键细节：

• 它是一个可操作的CI，可以是一个级别。它不可能是技术服务的层次结构。
• 用于事件、问题和更改中的影响。
• 也用于变更审批。
• 必须以供应商为中心，并包括为企业消费或销售提供的技术。