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

彭兔子做运营 2023-08-12 20:44:49

互联网行业的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发展早期对用户积累的需求之间的需求不对等矛盾，收费还是不收费、收多少，成为一个需要博弈的问题；反之则反。

三、ISV的运营特点和操盘解析

1. ISV的运营特点

服务链条长、涉及环节多，是ISV业务形态的特点，这样的业务形态决定了在项目运营的过程中，尽可能提升每一环节的转化效率变得至关重要。

2. ISV的运营操盘过程解析

1）用户落地环节

从潜在用户到落地（在被集成的语境里，落地可以理解为添加了这个应用），采用的方法大同小异。通常是在确定用户画像之后选取几个投放渠道，不断进行渠道投放监测，找到最优解决方案，获取性价比最高的市场线索，而这些市场线索最终会流入到销售团队的线索池中进行维护和回访，直至成单。

而在ISV被集成的语境和环境下，用户落地环节会被异化为：品牌推广—集成平台合作洽谈—集成—获得平台流量，洽谈到一个发展态势良好的平台，就可以获得天然的平台流量，解决了用户落地的问题。

这一环节，是一个运营+BD+产品打配合的过程，BD负责洽谈合作渠道，运营负责优化落地场景，产品负责集成工作。

2）用户体验环节

当用户成功进入到你优化好的落地环境中，尽快让他体验产品，并在体验之后下决心持续使用是这一环节的运营关键。到了这个部分，基本上跟BD关系不大了，完全是运营在补平台和产品的坑，想方设法的通过运营手段降低平台和产品的使用门槛，让整个产品看起来又聪明又好用，一旦使用起来，用户会感觉自己的工作效率得到了飞速的提升。

以我现在在做的业务为例，因平台特性的原因，用户从添加到完成产品的首次体验，中间涉及到一些配置工作，对互联网感不那么强的传统行业用户来说，学习门槛可能颇高。

在引导用户完成体验的过程中，除了需要制作一些操作文档、操作视频以便能够更集中的处理用户不会用的问题之外，为了提升这一环节的转化效率，我调研了用户从落地到完成产品首次体验过程中所有过程和逻辑困难，然后配置了一个只能识别完全匹配关键词的社群机器人，将产品使用核心流程，和其分支逻辑的每一步全部配置到机器人操作中，这样不仅能够有效减少反复截图、重复打字说明的次数，还能收到用户学习过程中每一步的反馈，乃至了解用户操作更容易被卡在哪一个环节，并返回给产品部门进行优化。

另外我还设置了一些完成新手任务的奖励，使用户更愿意完成产品的首次使用。

总而言之，在这一环节，需要想方设法的让用户大步迈入产品体验流程。

3）用户使用/持续性使用产品环节

当用户完成了产品首次使用，距离用户持续性使用产品就近了一大步。到了这个部分，基本上跟普遍的用户生命周期管理和运营的思路一致：通过数据分析，找到用户持续性使用产品的魔法数字，并不断深化这个魔法数字的关键动作，帮助用户养成持续性使用的习惯。

只是在找寻用户行为的魔法数字过程中，B端产品稍稍多了一些需要多考虑的因素，比如有的B端产品是一个低频产品（如人力、财务系统中的某些场景），持续性使用的观察周期和激励周期就要长得多；又比如一些教育类产品，因为存在寒暑假，运营活动或是运营动作就要考虑到是否会被假期中断的问题。

4）用户沉默和流失环节

当然，无论产品或是运营做得有多好，用户也会在使用过程中，逐渐走到需要离开的那一天。

从系统健康度、后期维护成本、用户感知等角度来看，B端深度沉默/流失用户都需要有一个好的归宿，不要频繁发生唤醒动作。

产品经理，产品经理网站

被集成的ISV形态的B端业务，看似很“轻”，但是在运营过程中却容易处处掣肘，承受平台、产品、用户的多重压力；但是只要抓住了用户活跃这个关键密码，用户持续性的使用会让整体业务插上翅膀，获得更多被集成的机会。

在这里稍稍拆解一下在ISV的场景下，用户活跃的定义。

不同于C端运营中对活跃的定义：单位时间内用户的使用次数，B端产品的使用频率跟随企业中某场景的使用频率，盲目提升一个周频率、月频率的产品的用户使用次数，也许不能解决产品持续性使用和产品商业化的问题。所以可以尝试在B2B2C的业务场景中，将B端用户活跃和C端用户活跃用拆解又合并的方式来进行观察。

先看B端活跃情况：它决定了企业中的业务核心人对产品的使用情况，哪怕是一个低频使用的产品，只要了解在使用周期内用户的使用次数，就能判断B端企业是否能很好的使用产品各项功能。
再看C端活跃情况：它决定了除了企业关键决策人、关键使用人之外，其他相关人对产品的感知和使用情况。特殊：在B端业务中持续关注C端用户的使用情况，甚至有助于发掘新的使用场景和商业机会。

最后，将两者的产品使用轨迹联系起来看，对一个健康的B端产品来说——产品有B端决策人决定采用、有核心使用人根据工作场景持续性使用、员工或是相关人对产品有感知、且有相当一部分人也在持续的从C端角度使用产品，这是最理想化的状态。

所以为了把握业务形态的健康度，我们需要将B端活跃和C端活跃联系起来观察，一家企业仅核心使用人在频繁使用产品，而员工及其相关人对产品毫无感知，这样的业务肯定不太健康，那么到底员工感知/活跃度占比到达多少，我们才能断定这是一个健康的业务形态呢？

这一点很难确定，需要在长期的数据观察之后才能下断言，不过可以肯定的是，B端产品在C端相关人使用率这个数据上，一直不太高。