文章转载自"ToB行业头条"
来源 / SaaS学姐 （ID：gh_5c7314bf3a9d）
作者 / 假装是运营
去特色，找共性的转变之路
SaaS系统的诞生初衷多种多样，但其中最特殊，当属由内部系统演变而来。根植在企业特定文化，带着特定的任务，有着特定的特色，从0到1的过程也是「去特色」，以及「找共性」的历程。平安科技，历时5年，烧钱不少，最终放弃了内部系统对外的战略。那么，内部系统转SaaS的路上，到底遇到多少难题，我们应该如何应对？“我们是时候做出新的改变了”，团队年会上，业务总裁一锤定音。背后的理由：“同样是一个领域，A细分市场已经有上市企业，B细分市场也被占领，而我们自己从事的，尚在发展的C市场一定也能走出一个技术独角兽。”负责内部系统实现的技术总裁应下任务。于他而言，这是一个从成本中心转成收入中心的机会，但摸不透老板有多坚决，于是几番权衡，定下策略：产品放手去试，但需要注意，控制研发成本。
读客户千遍也不厌倦
常年的业务积累让启动并不困难，系统里躺着成百上千个合作方，都可以当作广义的目标客户。走过一轮问卷发放，定量分析出炉。虽然这是一个较为传统的行业，有超过5成的客户没有使用过系统，但占比70%以上的客户愿意使用系统来改善当前的经营问题，希望解决的问题也有较好的一致性，至于他们的担忧，主要集中在信息泄漏和价格问题。再回过头来检查样本数量和质量，看到覆盖范围广泛，数据值得信任。团队被这样高的意愿度打上了强心剂，信心满满挑选有意愿的客户，开始一对一的定性访谈。“喂。。。你说什么。。。！@#¥%……”信号不佳，间或夹杂老板指挥下属干活的声音。“我们准备转行了，实在不好意思”很有礼貌，我们也祝福客户的选择。“行业太难了，这几年。。。”时局不好，不少客户都提过这句话，信息有效性被反复的情绪稀释。“你在哪里啊？哦哦，XX城市真是个好地方，我当年。。。”这是喜欢唠嗑发散的客户。“我们早几年就自己开发了统计和算账平台了，不然上游和下游根本算不过来”虽然客户已经超前实现了自己的信息化系统，但看到这样先进的意识，总让人欣慰。
欢迎来到真实的世界，五花八门的客户才是SaaS要去征战的市场。纷杂的信息就像沙砾，用结构化的框架，筛选出沙砾里的闪光金屑，接下来要做的是，呈现出这些金屑。
业务和产品的视角PK
约好了总裁们的时间，希望把过滤后的信息带给大家，谋求共识以及明确资源投入。深入了解：确认客户对系统化的定位以及诉求，了解不同客户的诉求和差距在哪些方面，了解诉求背后的不同客户画像 。初步了解阻碍实现目标的因素；初步了解市场竞争关系。基于获得的信息，帮助后续抽象用户需求，以及设计系统。1. 业务侧（业务规模、客户类型、团队规模、服务区域、发展意愿）2. 系统侧（客户对系统的定位和认识、使用顾虑、领导者意识）以对系统的定位+领导者意识为维度，区分不同场景下客户需要达成的目标和投资资源如上文所言，这次汇报主要是希望各方视角能对我们的客户有生动的认识，明确我们主要抓哪部分客户，为客户提供什么价值，以此确立我们自己的产品定位和边界。但汇报后，业务视角下给到的信息是：这些都是既定结论，根本不用去论证，客户对我们这类系统一定是有需要的，业务的同事们都在行业里那么多年了，这些事情还搞不清楚吗？这是一次业务和产品视角的PK，业务认为经验足够就能下判断，判断客户是否需要我们的系统，知道这些客户有什么特质并不重要。产品认为：所有需求都是从客户的业务目标而来，我们资源有限，必然无法同时满足所有客户的所有业务目标。在一个时间，只能服务于某一类客户，这类客户的难点是我们着重要解决的，我们要先定下客户是谁，再来看系统怎么做。另外，我们不能直接去拿现在的产品直接去找用户，没有企业面临的问题是一模一样的，就算找到和我们自己情况类似的企业，有些用户只需要其中的A模块，有些用户需要B模块，那我们应该做一个有强大的A模块的产品，还是做一个有强大B模块的产品呢？对于这两种观点，你的看法如何呢？欢迎留言。我们继续讲故事。
启动之难，难于上青天
调研沟通后，产研没有能从业务这里拿到足够拍板的信息，于是只有尽可能花小代价去做，最快的剪枝掉当前内部定制的能力，提供了一套简单的版本出来。开始对之前感兴趣的客户做demo，让客户亲眼看到系统样子和交互，明确客户是真的有需要。走到demo步骤的客户，大概有一半愿意接受产品到现场实施，指导员工使用系统。作息上、工作强度、工作规范性上老板几乎都没有太多的管理，一个人往往身兼多个角色，和系统上设计的角色分工也并不完全契合。大家设想的能提升人效，对老板来说基本不太重要，因为无法通过提升效率减少一个身兼多职的员工。老板们对数据的及时性并不像他们声称的那么看重，平时忙于飞来飞去谈业务，更习惯月初月末看看财务的账单。似乎推动系统进展，更像是老板一时热血的产物。事实证明了大家的猜想，在离开客户一两周内，大家还在就客户提出的问题，不断开发和优化，而客户，已经渐渐地不再登陆，甚至在通讯录上不再回复。在故事中，我们能看到以经验决策的老板，以及技术负责人，都有自己做事的目的和初衷。但产研视角和业务视角的天然不一致，以及层级的差距，让项目在落地的时候，往往缺少上层的方向指导。这种情况下的话，再高的自由度也都是枷锁。放弃极其高远的长期主义和宏观视角，要的是每一个阶段成功和失败的指标。例如上面的客户转化图，我们可以把每一次转化都视作当前的工作阶段，那我们每个阶段，如何定义自己的成功和失败？这是可以和老板探讨的内容。客户demo完成后，事实上应该由专职的销售或者客户成功介入。让客户使用有的时候更像是一个关系问题，而非如何体现产品价值的问题。故事中，我们采用了把企业内部个性化的内容删除，只提供通用能力的方案，另建了一套SaaS系统。例如改造当前系统的权限模块，给客户主要角色开设权限，每一个客户都作为一个业务主体，让客户能查看和管理自己业务范围内的数据。前期不需要让客户各个角色都参与进来，只需要主要角色能够尝试使用，跑通流程即可。内部系统最容易陷入的问题，就是拿着自己的雷神之锤，到处去找能下嘴的钉子。故事中的业务思维就是我们有啥，就去找类似的客户，而产品的思路是先找客户，再来在现有的产品上改造。我们要明确适用于内部的系统之所以好用，是有无数的管理流程和规范，无数技术支持和优化，才让他能产生对应的业务价值，也具备不错的体验。但我们把这么一个庞然大物都吐出给客户，能完美适配的又有几家？哪怕主要诉求相同，面对扑面而来的多种概念，很多客户一接触就晕掉了。我们还要明确的是，C端用户可以打痛点和痒点，而B端客户只能打痛点。老板每天要解决的事情林林总总，不痛的事情无法引起关注，哪怕短暂的进入todolist，也很快就会被遗忘。这就是为什么当很多客户体量大了，才会操心某些场景下的效率问题。例如大量的对账，算薪，在每天算10笔的情况下，无论是员工自己还是老板都承受得起，如果每天来到上千笔，业务吐槽工作量大，老板面临多请人带来的成本提升，相关人员收款慢，存在流失风险，同时公司还要承受错漏的情况，问题陡然变得严重。再拿这两年的出海热来说，其实是很多客户准备出海了，才会担心合规和安全问题，同时这类的产品才有立足空间。1. 现在产品的优势在哪里，哪些画像的客户最能理解和匹配我们的优势？
2. 我们的优势在客户的经营里，是多急需解决的问题？
3. 结合1，2点，我们是否需要另建优势？
而在另建优势的部分，是老板和业务同事更适合使用行业经验的部分，访谈他们经历的痛点，看看市场上的竞品，或许能给我们一些启发。
