导语：B端业务中常见的角色和主要工作内容 ， 同时展现了在平台生态下ISV的业务形态、组织架构 ， 以及他们跑通业务的方式 ， 本篇文章详细分析了ISV未来的发展趋势 。

文章图片

互联网行业的B端业务 ， 狭义上指为企业的日常经营、业务开展赋能 ， 为目前尚没有能力自行搭建各类平台或产品业务模块的企业第三方解决方案 ， 或是为那些在布局优先度上暂时无需内部孵化的企业第三方的嵌入式打包方案 。
在互联网生态下 ， 为企业产品服务 ， 尽管行业多种多样 ， 业务形态多种多样 ， 但是实现形式大概只有三种：私有化部署、云端服务、被集成 ， 这三种实现形式在一些情况下可能会交叉存在 ， 但也都于企业自身对第三方服务的需求 。
今天我们主要讨论的是B端业务中被集成这一业务形态的企业 ， 在云生态中 ， 它也被称为ISV—“独立”软件商 。
而过去的互联网行业的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整体团队通常小而美 ， 高度依赖生态的养分 。 团队由核心产品研发团队和营销团队构成 。分页标题#e#
在完成业务目标时 ， 团队遵循快准狠的原则 。
产品端：核心功能-迅速跑通-研究附加增值功能-打包整体解决方案 。
营销端：输出对外营销文档 ， 建立完整SOP ， 从用户添加应用起 ， 就开始按照效率最大化需求进行用户 。
这样的策略制定 ， 使得ISV能够以最小成本快速跑通业务逻辑 ， 如果策划得好 ， 运气好 ， 就能够很快实现自给自足 。

文章图片

当然 ， 这是非常理想化的状态 ， 实际上 ， ISV业务一旦运转起来 ， 接踵而来的各种问题 ， 才是限制ISV发展的重大阻力 。
二、ISV们面临的困境
通过思考我们可以感受到 ， ISV们在享受平台的相对完善的模块和业务框架 ， 甚至是平台的流量的同时 ， 也要面对平台带来的各种局限性 。
1. 跟随、适应平台规则 ， 承受平台带来的不便 ， 是ISV的原罪
在中国的市场环境下 ， 针对企业的云端服务产品的历史还非常短 ， 平台仍在不断完善中 ， 成长于平台护持下的ISV们 ， 必须要接受平台的不完美 。
一边做平台小白鼠不断帮助平台完成自我优化 ， 一边还要在平台框架下持续发展自己的业务 ， 提高用户体验 。
2. 对单一渠道的依赖过重 ， 会导致ISV的生存风险增加
ISV的生存风险既于平台内部对各应用服务商的规则变化；也于平台自身在商业环境中面临的风险 。
作为整个业务逻辑中的小虾米 ， ISV的话语权并不高 ， 在遭遇平台转嫁风险和压力时 ， 除了接收并努力调整解决方案 ， 似乎并没有其他的选择 。
3. ISV的定价规则及商业变现之路将会受到平台的一定制约
【ISV的运营特点和操盘解析】为配合平台自身的发展 ， 和平台对应用户的消费习惯 ， 平台将会对集成的ISV在定价上做出一定限制 ， 不同的发展时期 ， 遭遇限制的方式不尽相同 。
若是平台发展已经较为成熟 ， 进驻的ISV却处于需要大量吸引用户的初创阶段 ， 平台和ISV的矛盾就变成了家大业大的平台对商业变现的需求和初创ISV发展早期对用户积累的需求之间的需求不对等矛盾 ， 收费还是不收费、收多少 ， 成为一个需要博弈的问题；反之则反 。
三、ISV的特点和操盘解析 1. ISV的特点
服务链条长、涉及环节多 ， 是ISV业务形态的特点 ， 这样的业务形态决定了在项目的过程中 ， 尽可能提升每一环节的效率变得至关重要 。
2. ISV的操盘过程解析
1用户落地环节
从潜在用户到落地（在被集成的语境里 ， 落地可以理解为添加了这个应用）采用的方法大同小异 。 通常是在确定用户画像之后选取几个投放渠道 ， 不断进行渠道投放监测 ， 找到最优解决方案 ， 获取性价比最高的市场线索 ， 而这些市场线索最终会流入到团队的线索池中进行维护和回访 ， 直至成单 。
而在ISV被集成的语境和环境下 ， 用户落地环节会被异化为：品牌推广—集成平台合作洽谈—集成—获得平台流量 ， 洽谈到一个发展态势良好的平台 ， 就可以获得天然的平台流量 ， 解决了用户落地的问题 。
这一环节 ， 是一个+BD+产品打配合的过程 ， BD负责洽谈合作渠道 ， 负责优化落地场景 ， 产品负责集成工作 。
2用户体验环节
当用户成功进入到你优化好的落地环境中 ， 尽快让他体验产品 ， 并在体验之后下决心持续使用是这一环节的关键 。 到了这个部分 ， 基本上跟BD关系不大了 ， 完全是在补平台和产品的坑 ， 想方设法的通过手段降低平台和产品的使用门槛 ， 让整个产品看起来又聪明又好用 ， 一旦使用起来 ， 用户会感觉自己的工作效率得到了飞速的提升 。
以我现在在做的业务为例 ， 因平台特性的原因 ， 用户从添加到完成产品的首次体验 ， 中间涉及到一些配置工作 ， 对互联网感不那么强的传统行业用户来说 ， 学习门槛可能颇高 。分页标题#e#
在引导用户完成体验的过程中 ， 除了需要制作一些操作文档、操作以便能够更集中的处理用户不会用的问题之外 ， 为了提升这一环节的效率 ， 我调研了用户从落地到完成产品首次体验过程中所有过程和逻辑困难 ， 配置了一个只能识别完全匹配关键词的社群机器人 ， 将产品使用核心流程 ， 和其分支逻辑的每一步全部配置到机器人操作中 ， 这样不仅能够有效减少反复截图、重复打字说明的次数 ， 还能收到用户学习过程中每一步的反馈 ， 乃至了解用户操作更容易被卡在哪一个环节 ， 并返回给产品部门进行优化 。
另外我还设置了一些完成新手任务的奖励 ， 使用户更愿意完成产品的首次使用 。
总而言之 ， 在这一环节 ， 需要想方设法的让用户大步迈入产品体验流程 。
3用户使用/持续性使用产品环节
当用户完成了产品首次使用 ， 距离用户持续性使用产品就近了一大步 。 到了这个部分 ， 基本上跟普遍的用户生命周期和的思路一致：通过数据分析 ， 找到用户持续性使用产品的魔法数字 ， 并不断深化这个魔法数字的关键动作 ， 帮助用户养成持续性使用的习惯 。
只是在找寻用户行为的魔法数字过程中 ， B端产品稍稍多了一些需要多考虑的因素 ， 比如有的B端产品是一个低频产品（如人力、财务中的某些场景）持续性使用的观察周期和激励周期就要长得多；又比如一些教育类产品 ， 因为存在寒暑假 ， 活动或是动作就要考虑到是否会被假期中断的问题 。
4用户沉默和流失环节
当然 ， 无论产品或是做得有多好 ， 用户也会在使用过程中 ， 逐渐走到需要离开的那一天 。
从健康度、后期维护成本、用户感知等角度来看 ， B端深度沉默/流失用户都需要有一个好的归宿 ， 不要频繁发生唤醒动作 。

文章图片

在这里稍稍拆解一下在ISV的场景下 ， 用户活跃的定义 。
不同于C端中对活跃的定义：单位时间内用户的使用次数 ， B端产品的使用频率跟随企业中某场景的使用频率 ， 盲目提升一个周频率、月频率的产品的用户使用次数 ， 也许不能解决产品持续性使用和产品商业化的问题 。 所以可以尝试在B2B2C的业务场景中 ， 将B端用户活跃和C端用户活跃用拆解又合并的方式来进行观察 。
先看B端活跃情况：它决定了企业中的业务核心人对产品的使用情况 ， 哪怕是一个低频使用的产品 ， 只要了解在使用周期内用户的使用次数 ， 就能判断B端企业是否能很好的使用产品各项功能 。
最后 ， 将两者的产品使用轨迹起来看 ， 对一个健康的B端产品来说—产品有B端决策人决定采用、有核心使用人根据工作场景持续性使用、员工或是相关人对产品有感知、且有相当一部分在持续的从C端角度使用产品 ， 这是最理想化的状态 。
所以为了把握业务形态的健康度 ， 我们需要将B端活跃和C端活跃起来观察 ， 一家企业仅核心使用人在频繁使用产品 ， 而员工及其相关人对产品毫无感知 ， 这样的业务肯定不太健康 ， 那么到底员工感知/活跃度占比到达多少 ， 我们才能断定这是一个健康的业务形态呢？
这一点很难确定 ， 需要在长期的数据观察之后才能下断言 ， 不过可以肯定的是 ， B端产品在C端相关人使用率这个数据上 ， 一直不太高 。
四、大胆分析下ISV的未来
前文我们分析了很多ISV目前的困境和的操盘经验 ， 我们会发现 ， ISV业务的破局之道：
游走于各个云生态之间 ， 拓展各种有实力或是有潜在实力的渠道入口 。
立足于自身 ， 努力平衡和生态的关系 ， 提升用户从落地-持续性使用的效率 。 而后者的得当又能够反哺到前者的拓展过程中 。
【ISV的运营特点和操盘解析】孤立无援注定难以为继 ， 我们可以大胆推测 ， 为提高落地-持续性使用的效率 ， 会有一些相同用户画像、相似业务形态 ， 甚至于说处于企业业务上下游关系的ISV联合起来 ， 相互作用、相互影响 ， 结成类联盟的松散关系 。分页标题#e#

文章图片

最终 ， 会有被集成模式下的行业龙头 ， 打穿云生态中的平台壁垒 ， 成为某些场景下的用户首选 ， 无论用户自身业务场景如何变迁 ， 一旦他在这一细分场景上有需求 ， 想到的就是那个别无选择的ISV 。
本文相关词条概念解析：
用户
用户 ， 广泛的含义是使用者 ， 即使用你的产品或服务的一方 。 一般是指城镇、农村接受社会某种有偿服务的客户 。 如：供水、宽带、通信、供暖、煤气等客户 。 用户分为电脑登录用户 ， 每一个电脑登陆用户都是采用个人的设置 。 用户：某一种技术、产品、服务的使用者 ， 使用某种产品的人 。 用户：在计算机里还指人、帐号、进程等 。 信息通信技术的发展使得创新不再是科学家和技术研发人员的专利 ， 用户对与科技创新的重要性被日益认识 ， 用户参与的创新2.0（面向知识社会的下一代创新）模式正在逐步显现 ， 用户需求、用户参与、以用户为中心被认为是新条件下创新的重要特征 ， 用户成为创新2.0的关键词 ， 用户体验也被认为是知识社会环境下创新2.0模式的核心 。

来源：(未知)

【】网址：/a/2020/0721/kd308142.html

标题：ISV的运营特点和操盘解析