SaaS 销售绩效指标
ServiceNow 客户运营总裁 David Schneider 分享了针对旨在实现超大规模的 SaaS 公司的销售绩效指标。在过去的 5 个季度中:
-
- 总合同价值达成率
- 总管理(ACV、续订、PS)
-
- 净新增 ACV 达成率
- 销售配额达成率
- 季度增长
- 年度增长
-
- 累计新增客户总数
- 新客户(包括损失)
-
- ACV 重复客户百分比与净新增客户的比率
-
- 累计净客户总数
- 新客户
-
- 上岗代表数量
- 每位销售代表的平均生产力
- 销售代表年化流失率
- 总销售年化流失率
ServiceNow 客户运营总裁 David Schneider 分享了针对旨在实现超大规模的 SaaS 公司的销售绩效指标。在过去的 5 个季度中:
上桌玩牌要有足够的筹码 —— 招聘足够数量的高水平人才,这些人才要足够重视质量、足够聪明。你要向她们反复强调公司重视质量的文化,形成正式的惯例检验大块工作,该修的修。
战术上,有这样一条最佳实践 —— 降低做正确事情的难度。Stripe 技术团队做出了各种各样的取舍,以便能够保证任何工程师都能够改进系统的任何部分。鼓励责任感(ownership)。
有专门的内部工具检查国际化的水平,很无聊,但是得花时间做。要注意,这又回到了公司的文化问题,当一个做这件事情的 IC 说:“我上周花了一些时间做 i18n ” 的时候,他应该会默认,领导层足够重视这件事情,以至于会回答说:“当然你花了时间做了这件事情,棒棒哒。”
“开个工单给相应的组,会有相应的人来处理” 是个好实践,但是如果你能够推动这个系统更快更好地把这个工单修掉,你就更能够激励人去开工单。
公司会给专门的途径,比如邮件组的别名,来上报产品的质量 bug。有专门的组来 triage 这些任务,或者把任务分配到合适的组来修,有专门的惯例告诉整个公司质量 bug 的修复速率。
在做重大 API 变化之前,既要做内部测试,也要做外部测试。经常问一下“谁有一个真真正正的 Stripe 账号在手头?能不能更新到 beta 版本试一下?” 人们需要专门抽出时间来做这件事情,并且详尽地记录下来形成文档 —— 想象一下,你有一群挑三拣四的客户,虽然你很可能无法像用户那样深入地、广泛地使用自家的产品,但是这样做已经比瞎猜要好很多了。
发现“一块支付代码 5 年没有碰过了,不知道它是怎么工作的,竟然 没有测试”,这种情况虽然很少见,但是对于工程团队来说,是宝贵的财富。
以上所有都不是什么高科技,也都不是能够保证质量的充分条件。Stripe 从来都不会满足当下的质量水平,不会被动地说说“我们的标准很高”,而是保持“主动地一直在去做”。