B端业务中ISV的生存困境和用户运营操盘解析.docVIP

B端业务中ISV的生存困境和用户运营操盘解析 / 互联网行业的B端业务，狭义上指为企业的日常经营、业务开展赋能，为目前尚没有能力自行搭建各类平台或产品业务模块的企业提供第三方解决方案，或是为那些在管理布局优先度上暂时无需内部孵化的企业提供第三方的嵌入式打包方案。 在互联网生态下，为企业提供产品服务，尽管行业多种多样，业务形态多种多样，但是实现形式大概只有三种：私有化部署、云端服务、被集成，这三种实现形式在一些情况下可能会交叉存在，但也都来源于企业自身对第三方服务的需求。 今天我们主要讨论的是B端业务中被集成这一业务形态的企业，在云生态中，它也被称为ISV——“独立”软件开发商。 而过去的互联网行业的B端运营工作，其实分为品牌运营和销售运营两种： 品牌运营：开展或是参加市场活动，帮助企业获取市场线索； 销售运营：通过自上而下的销售政策宣导+销售辅助动作，促进成单。 在这样的运营逻辑下，似乎并没有一个角色为用户体验、用户活跃、用户使用情况买单，如果非要从B端企业管理架构中找出这样一个角色，可能只有后端销售（售后），在续费的目标导向下，会稍稍关注一些。 那用户体验、用户活跃、用户使用情况对于B端业务是否重要呢？这个问题根本是毋庸置疑的。 即使现在做好B2B2C业务流程中每一环节每一类型用户的体验，对短时销售结果来说意义不大，但是对未来的用户续费、用户推荐、新版本、新功能的成功发布与推进都意义重大。 B端产品的运营工作，可借鉴现在常见的AARRR模型来开展，但是在实际工作中，B端运营面临的状况要复杂得多。我们在遵循AARRR模型来探讨B端用户从哪来到哪去时，会发现B端业务链条相较于C端业务，要长得多。 现在的很多B端平台，甚至延伸出B2B2B2C的业务形态，且在各个业务链条中又存在相互联结合作的情况出现。 举个例子：因2020年年初疫情而大火的钉钉和企业微信（第一个B），就是国内平台的典型，在基于钉钉和企业微信的业务框架和开发框架下，有数以十万计的ISV紧密围绕在这两个平台的生态周围，基于平台的产品生态开发自己的Saas产品（第二个B）。这类ISV，有擅长客户管理的，有擅长销售管理的；有擅长做人力资源系统的，有擅长做办公团队协同的，还有各种各样满足企业经营过程中的工具。这些ISV在平台下，走完用户（最后一个B）的添加-试用-使用-持续性使用的全生命周期，而这业务链条最末的B端用户，又会在上游B端的赋能下，完成自己B2C的业务流程。 我们总结这冗长的业务形态，会发现相较于C端业务形态，B端业务的决策层级真的很~多，业务链条真的很~长；所以身处于B端的运营工作者的日常，应该是既心累又无力的吧。 今天我们拆解那些身处于钉钉、企业微信生态下的ISV的业务形态和面临的困境，给出一些实操方案，同时也大胆推测一下ISV的未来。 一、ISV们的业务形态 如上文介绍，ISV整体团队通常小而美，高度依赖生态的养分。团队由核心产品研发团队和客服营销团队构成。 在完成业务目标时，团队遵循快准狠的原则。 产品端：开发核心功能-迅速跑通-研究附加增值功能-打包整体解决方案； 营销端：输出对外营销文档，建立完整SOP，从用户添加应用起，就开始按照效率最大化需求进行用户转化。 这样的策略制定，使得ISV能够以最小成本快速跑通业务逻辑，如果策划得好，运气好，就能够很快实现自给自足。 当然，这是非常理想化的状态，实际上，ISV业务一旦运转起来，接踵而来的各种问题，才是限制ISV发展的重大阻力。 二、ISV们面临的困境 通过思考我们可以感受到，ISV们在享受平台提供的相对完善的开发模块和业务框架，甚至是平台提供的流量的同时，也要面对平台带来的各种局限性。 1. 跟随、适应平台规则，承受平台带来的不便，是ISV的原罪 在中国的市场环境下，针对企业的云端服务产品的历史还非常短，平台仍在不断完善中，成长于平台护持下的ISV们，必须要接受平台的不完美。 一边做平台小白鼠不断帮助平台完成自我优化，一边还要在平台框架下持续发展自己的业务，提高用户体验。 2. 对单一渠道的依赖过重，会导致ISV的生存风险增加 ISV的生存风险既来源于平台内部对各应用服务商的规则变化；也来源于平台自身在商业环境中面临的风险。 作为整个业务逻辑中的小虾米，ISV的话语权并不高，在遭遇平台转嫁风险和运营压力时，除了接收并努力调整解决方案，似乎并没有其他的选择。 3. ISV的定价规则及商业变现之路将会受到平台的一定制约 为配合平台自身的发展，和平台对应用户的消费习惯，平台将会对集成的ISV在定价上做出一定限制，不同的发展时期，遭遇限制的方式不尽相同。 若是平台发展已经较为成熟，进驻的ISV却处于需要大量吸引用户的初创阶段，平台和ISV的矛盾就变成了家大业大的平台对商业变现的需求和初创ISV发展早期对用户积累