企业级SaaS产品与C端互联网产品差异大，甚至是截然相反，这些特征也会成为后续客户成长旅程的重要影响变量。本文就如何设计并服务好企业级SaaS产品客户成长旅程进行分析总结，希望对你有所启发。
大家肯定好奇，标题为什么不直接借用c端互联网的用户体验旅程而硬生生套上一个没听过的概念——客户成长旅程呢？
因为用户体验旅程预期是达成一个相对简单且确定性结果目标，但SaaS产品的客户体验旅程不一定是确定性结果目标，甚至这个旅程没有起点也没有终点，它更像一套完整的游戏养成过程，但又比游戏的养成模型更复杂，比如用户角色、需求及行为模式的差异、产品采购或续约决策行为的超理性，以及在产品体验中场景协同需求的结果导向型等，这些构成了客户成长旅程的底色，所以企业级SaaS产品体验是一套完整的和客户共建和成长的旅程。
之前我在很多文章里都反复阐述过，企业级SaaS产品具有标准化、订阅制、购买决策理性、接入和使用门槛高、付费转化慢、客户留存高、用户基数相较c端小、用户角色分工复杂、组织协同性强、结果预期不确定、需求闭环周期长、业务行业壁垒高、需求场景更复杂、企业组织及流程标准化程度要求高、互联网化程度高、平台与客户之间共生依赖关系更强等特征。
这些特征跟c端互联网产品差异很大，甚至是截然相反，这些特征也会成为后续客户成长旅程的重要影响变量。如何设计并服务好客户成长旅程，这是一个很大的课题，以我的能力和专业局限，可能也很难讲透，尽力而为吧。
c端产品设计是围绕着用户个体的线性任务旅程展开的，而企业级SaaS产品是围绕着组织协同的企业增长旅程展开的。
c端产品有清晰的任务起点和终点，用户旅程和结果预期是相对确定性的，可能会有朋友说超级APP就不是线性旅程，但值得注意的是，虽然超级app集成了用户多重需求，但他们每一重需求都是一个相对独立的目标任务闭环，且互不影响。而企业级SaaS产品设计则是围绕着企业成长旅程，企业成长是一套复杂、有组织、强关联、相互影响、且是开放式结果预期的客户养成机制，所以大家会发现：c端产品的核心健康指标叫活跃、留存、gmv、复购等，而企业级SaaS产品的健康指标是NPS和客户成长性依赖。
我们都知道，企业级SaaS产品和服务解决的的根本问题其实是经营性问题。这就像小到提供一颗螺丝钉，大到和客户一起共建一栋厂房，或者叫功能空间吧（比如一个工厂、一条生产线、一个餐厅及功能服务全套体验设计方案），客户需要美好的主观感受和细节体验固然没错，但最终还是希望产品能满足经营中的实际降本增效和业务增长需要，即能帮客户一起解决经营性问题，而且提供的产品和服务最好还能持续伴随客户成长不断的迭代和完善。
这时侯的客户体验就具备相对确定性的价值和需求形态了（如：效率提升、成本优化、安全稳定、运营增长等或以上兼得），而不仅仅是建造房子过程中的服务感受或某一个结构单元个体的精妙设计所带来的即时多巴胺奖励，这和c端用户体验旅程有本质差别（to b和to c产品体验奖励机制类似于内啡肽和多巴胺差异）。
这很好理解，在物质富足的现代社会，消费行为除了解决温饱需求和安全需求之外，其实更多满足的是一种情感代偿需求，因此个人消费需求从根本上来说其实追求的是体验满足感，而非完全意义上的实用价值本身。
相信大家一定有一个共识，就是做服务不如做产品、做非标不如做标准、做定制不如做SaaS，因为这样可以突破无限边际成本。
其实前几年，国内SaaS行业也走过以前c端相同的路，起初大家发现海外企业级软件服务市场规模很大，海外成熟的SaaS产品和服务标准化程度也非常高，业务生态更健全。
比如因为营商环境和企业组织管理相对规范，各平台之间的产品、功能的协议标准也很统一，兼容性也非常好。也就是说大家会一起共建和维护一个企业数字化产品和服务生态，每一个环节都有竞争空间，只要做好都能有饭吃。他们更类似现在成熟的高端传统制造业，比如汽车行业，哪怕是只生产一个螺丝的供应商，只要你做到足够好，大家就能很好的共生和发展。
于是大家参照当年的消费互联网模式，直接把海外SaaS模式依葫芦画瓢复刻了回来，也将消费互联网（c端）的用户体验旅程管理模型照搬到国内SaaS行业，但因为国内行业生态的复杂性和差异，结果发现跑起来非常吃力，传统c端互联网的用户体验也不能作为产品价值管理的唯一标准。
最后也不乏有很多产品人抱定改造企业组织和协作方式的愿景来做标准化，但改造个体（消费者）容易，改造超理性决策的企业组织何其困难。
现实环境倒逼这个行业开始回到初始化姿态，重新思考企业级SaaS在国内如何更贴近真实市场环境和客户需求，标准化是一个变化发展的动态过程，而不是一个恒定的产品和服务结果形态，而解决客户问题成为产品标准化的内生动力，我把它叫做企业级SaaS产品的烟火气。
这时候你会发现，又有点像回到传统软件服务化模式了。这正好和以前我在其他文章中有提到的观点吻合了——在国内，企业级SaaS其实是产品和服务的交叉领域，这是一个非常复杂且精细化的业务形态，所以，只有把市场、产研、销售、运营、客服、技术支持、客户成功、用户体验管理等所有环节做到精细化协同和响应，才能具备更敏锐的业务体感和客户需求感知力，而且你会发现，这些产品和服务的职能环节正好分布在客户成长过程中的不同阶段，所以顺理成章的引出了文章的主题——客户成长旅程。
（1）被动引导旅程（侧重销售）
这是一条最传统的客户成长旅程，属于典型的销售和服务驱动型（准确的说应该是客户驱动型），其特点是产品体量重、技术壁垒深、客户业务依赖性强、客户相对稳定、客单价高、接入和迁移成本高、客户决策谨慎等，比如传统ERP软件、财务管理软件、产业化的数字化工具等。销售和交付团队、售后和技术支持团队在整个客户成长周期中扮演非常重要的角色，且必须做到有求必应、快速响应、贴心服务；
这种偏服务模式的客户旅程管理优势体现在高客单价的大客户获客、服务及留存，但其弊端也明显：
1、重服务模式就注定了产品标准化难度非常大，中小长尾客户很难覆盖到；
2、业务运营、客户触达和营销转化成本很高，边际递减效应非常明显；这也是传统软件需要向SaaS化转型的核心痛点；
（2）自发养成旅程（侧重产品和运营）
这是典型的互联网工具类产品的成长旅程，其特点是产品体量相对较小、解决痛点更简单直接、使用门槛低且易上手、协同依赖性不高，这类产品往往服务于小B（个体从业者或为解决工作问题的个人），客单价低但用户群体大、公司决策相对感性高效，总之正好和被动引导旅程特点相反。
这种重运营型的产品优势在于：
1、于平台可以短平快的快速验证市场需求和变现；
2、于用户则易上手，直接解决需求痛点，成本可控。
缺点也非常明显：基本c端消费互联网的弊端它都具备了，如运营成本高、客单价低、客户粘性差、留存低、竞争壁垒不高等。
（3）自发+引导养成旅程（市场+销售+产品+运营）：
这条成长旅程兼顾前面一和二各自的优势，是目前SaaS行业的相对健康的客户成长管理模式，也是本文观点比较推崇的管理模式，但国内因为各种原因，践行的比较成功的公司并不多。
国内真正意义上的全民数字化应该是起于互联网兴起的近20年。数据归因成为互联网行业津津乐道的运营和管理热词，但能做到真正意义上的数据运营、数据管理和数据辅助决策的并不多。
原因很多：比如数据样本基数太小、数据基础能力跟不上、数据获取难度太大、量化分析过程太繁琐和成本高、个体决策惯性等，最后80%的决策都成了个体拍脑袋或一群人各自拍脑袋，没有精细化的上下游数据化管理，是很难协同客户旅程中不同职能环节的工作有效性的。
那么，背负沉重传统软件交付模式历史包袱的SaaS行业，到底能不能做数据化客户旅程管理？如果能，该怎么做呢？？
职能部门：
1、销售：除了每天冲刺营收kpi之外，还要关注线索和商机运营、客户资源管理（CRM），以及客户服务满意度和NPS管理；
2、产研：除了交付效率和和交付质量之外，还要关注用户体验、产品可用性（SUS）、客户满意度和NPS管理；
3、运营：除了线索拉新、商机转化之外，还要关注用户生命周期运营和产品精细化运营；
4、市场：除了渠道运营和品牌建设之外，还要做市场研究和行业洞察；
协同部分：
准确的说，健康的数字化运营管理是各职能环节数据的正向流转和上下游的逻辑自洽，而不是各自把自己圈定的职责范围做到数据表现最好。
这时候，客户成长旅程巧妙的成为了一个衔接完整数据流的第三视角的切入点。它可以帮各职能环节打破专业和职责壁垒，把产具体的工作规划和落地执行真实嵌入上下游环节，在业务信息和工作目标完全对齐，且形成群体性认同的基础上，为上下游负责，成全上下游就是成全业务，成全业务就成全了最佳的客户成长体验。
付费客户交付响应重要，免费用户满意度和生命周期管理一样也很重要。
之前专门写过一篇如何克服SaaS产品运营中项目交付式思维的文章，这里不做太多赘述。b端产品客户角色比较复杂，具体可以看下图。这里主要是想强调一下基础用户的重要性，在to b行业，经营者会把核心资源和精力放在客户这个群体（推动者、筛选者和决策者），而忽略基础用户（具体使用者），这是商业本能，本无可厚非，但用户角色有三个重要变量需要重视：
变量1：免费用户和客户是动态转化的，因为企业是动态发展的，长久生意一定要遵循养成过程；
变量2：用户群体性裂变后的品牌涌现效应是非常可怕的，特定产品类型中，口碑沉淀和由下至上的汇报式采购决策对产品运营转化价值不可以低估；
变量3：在客户视角的用户是产品的具体使用者，使用者才是真实的基层执行者的需求来源；
所以，用户体验管理和用户生命周期运营其实是SaaS产品客户旅程中非常重要的前半程。
做产品即做业务，其实是一种经营行为，它不像研究理论方法论，所以现实情况必须充分考虑。在绝大多数情况下，企业得先生存再考虑业务健康度，得先实现短期目标再升级经营管理。所以对于产品和业务的特定发展阶段，客户旅程体验管理模式会有很大的差异，这是一个非常复杂的选择和践行过程，我举几个例子来简单说明一下；
例1: 如果您的业务属于标准化程度很高、且预期用户基数较大的通用b端工具类产品（至少初期产品形态是这样吧），且处在业务初始阶段，那么短期目标一定是快速裂变、验证市场。那么其客户体验旅程管理就可以直接参照c端互联网的用户旅程运营管理模式，产品+运营，两手都要硬；
例2: 如果您的业务属于行业门槛较高的数字化系统产品，且处于初始阶段，没有太多成功案例和行业品牌口碑。
那么短期目标一定是深入特定行业和客户需求场景，用专业能力去解决客户的业务场景的数字化管理上的具体问题，那么其客户体验旅程管理可能直接参照传统软件交付的服务模式最合适，业务发展路径可能需要遵循：拿下客户>解决问题>形成案例>沉淀口碑>泛化需求>产品标准化……
这将是在产品迭代周期中绕不开的一个问题。
结合上面的诸多观点，回归日常产品的规划和设计，无论是哪种旅程，在产品迭代过程中，我们都会面临一个矛盾：先做极致用户体验会降低使用门槛，快速实现产品转化，并能提升用户满意度，但打磨细节确实会消耗时间成本和局限客户价值面。
那么先满足功能完整度，虽然会覆盖更全的功能卖点，但同时也会提高产品使用门槛，而且容易陷入无限堆功能的死循环。功能庞杂导致门槛太高，用户信任度又不够，最后产品还是用不起来。
这似乎是一个很难确定对错的的两难选择，而且很多产研交付团队很容易在此出现决策失误的，导致用户或客户都不满意。这里如果我们结合产品自身的成长旅程的思路来拆解，可能就有答案了。
情形1：和上面的情况类似，如果您的业务处于初创期，没有任何存量客户包袱，又希望自己的产品快速获得用户。就可以围绕企业用户核心痛点需求及功能，用心打磨极致用户体验，不放过任何一个转化进来的新用户；
情形2：如果您的业务处于快速成长期，有一定的品牌口碑和用户基数，则可以充分挖掘客户需求，能力范围内尽量覆盖足够全面的产品能力，用户体验可以稍稍滞后，但后面必须优化迭代，不能直接跳过；
情形3：如果处在成熟期，有庞大的用户/客户群体在高频使用，且有较高的行业品牌口碑，则需要谨慎进行颠覆式的产品调整或超大版本的新功能迭代（可以看我以前的文章“TO B产品交互体系一次性推翻重构，代价很沉重”），可以考虑独立产品形态灰度试水，此时，极致用户体验则需要上升到公司目标级；
任何一种健康的产品模式都要遵循养成机制，而养成的过程则是一套完整的进化和成长的路径，当然，这既包括了客户的成长，也包括平台自身的产品和服务的迭代和成长，那些走着走着消失了的产品，其实都是和用户（客户）同行的过程中迷失或掉队了。
平生做好两件事：“做正确的事情”和“把事情做正确”。这篇文章本身是有局限性的，可能解释不了做正确的事情这一步（客户需求和产品能力的底层边界性问题），但至少在现阶段看来，我们是想努力的把事情做正确，至于结果会走向何方，就让时间告诉我们答案吧！
本文由 @产品体验设计边界 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。