Saas(ToB)产品推广的拙见
2021-05-30 / modified at 2022-08-07 / 2k words / 7 mins
️This article has been over 1 years since the last update.
ToB项目有着跟进周期长、高定制，客户内部复杂的特点，非常难做，本文分享低人力成本下的推广思路。
区分toC与toB的角色
企业产品（toB）与消费者（toC）的最大差别就是Sponsor
- toB产品中决策者、推动者与使用者不是一个人，决策者可能双手不沾泥，要做好案例工作，让决策者在Demo Day中能够意识到可以提高普通职工的ROI；
- toC产品（比如淘宝，微信）中，决策者是广告商，而消费者只要满足马斯洛的需求层次（工具/社交/自我实现）的工具人，是被个性化投喂的流量源。国内这种流量大部分是"民营医院/小额贷款/一刀999/教育培训"等机构的广告。
上述差别导致了用户体验并不是重点，比如
- 淘宝、滴滴为了养活KPI而做的极其臃肿，消费者的体验反馈无意义，只有3.75的绩效才有用
- HW手机/电视系统出现无法移除的广告，要提高收入
- IT系统中"流程合规"压倒一切体验问题
以下是更多的区别
| toB | toC | 共同点 | |
|---|---|---|---|
| 例子 | 金蝶ERP，Salesforce, CRM | 抖音，头条，淘宝，YouTube | |
| Sales | CSM（客户成功管理） | 买流量 | |
| Sponsor | 高级管理者 | 流量买家与作者 | |
| Consumer | 一般职员 | 大众用户 | 很难提需求 |
| Sponsor眼中的Consumer | 堆人天干活 | 流量投喂 | 都是数字指标 |
| 方法论 | 以客户为中心 | 马斯洛需求层次理论 | |
| 推广方式 | 典型案例 or 泰勒式金字塔强推 | 广告轰炸，地推，病毒式传播 | |
| 需求分析 | 需要催熟生态与场景，垂直复杂，陷入定制 | 场景单一，快速复制 | |
| 反馈链路 | 决策周期长，数据滞后 | 快速AB test |
可以看出，toB的软件费劲且难挣钱，想要挣快钱的公司很难有强意愿去做toB类型的产品，因为周期太长了，很容易拿着投资干了几年却成效一般
ToB项目的难点
从研发的角度，难点如下
| 分类 | 解释 | 难点 |
|---|---|---|
| 场景分析 | 需要形而上学（经验理性） | 无参考；考验逻辑能力 |
| 生态 | 需要与用户一起实践催熟生态，这导致了蛋生鸡的获客问题 | 从科普到落地 |
| 组织架构 | 企业组织内部派系会相互制约 | 要与推动者目的一致 |
| 技术门槛 | 技术门槛都不高，很容易被仿制 | 最终起了大早，赶了晚集 |
| 招聘 | ToB产品的IT类工资比互联网低了很多 | 招聘难做 |
| 人力 | 反复陷入补全细节、摘用户、做新功能的纠结中；会耗在管理细节 | 加人也不顶用 |
从销售的角度，难点如下（待完善）
| 分类 | 解释 | 难点 |
|---|---|---|
| 新用户导入 | 从零导入用户 | |
| 搬迁友商 | 本产品ROI比友商高 | |
| 加钱升级 | 升级License续费 |
角色与目的
toB推广面向的是客户公司，既然是公司就有官僚主义、亮点文化等大公司病，而不像toC消费品那样投喂即可，一定要明确客户内部的共赢情况
| 角色 | 个人目的 | 攻克方案 |
|---|---|---|
| 部门大领导 | 提高部门效率，但是对A、B、C等产品摇摆不定 | 做好科普与竞品对比（但不公开演示）工作，做好真正的典型案例 |
| 合作中层A | 通过引入工具，找“亮点”，提升自己的绩效 | 项目需求突破口，尽快POC后，拿到A的支撑，去内部递归MVP推广到普通职员 |
| 竞争中层B | 通过引入竞品工具，找“亮点”，提升自己的绩效 | 不主动否定与打压，不被抓住把柄，尽可能形成差异化 |
| 普通职员 | 简化操作和清晰易懂；自发试用分享 | 尽快输出MVP典型，要详细周到的Demo与支撑试用 |
综上，可以看出各个角色是相辅相成的，但是你的人力是有限的，难以一次落地。
这里最重要是几件事情
- 找到中层支持的动力，要让对方中层来内部递归推动，建立好内部定制流程，而不要让自己的人力去别人的地盘来克服这种阻力
- toB软件要明确主要提高效率，还是质量管控，这两种目标对象和推广流程完全不同
- 找典型场景，支撑1～2组典型用例即可，不要铺开过大，要能说服大领导不再动摇即可。
另外分享下我的失败流程
- 免费提供服务：容易导致对方不重视，需求过于宏观。绝对要让双方都有真心投入后，再决策实施。
- 盲目扩张用户数量：容易击穿人力，而且场景无法深入，导致谁也没试用好，口碑会下降。
- 没有持续改进：为客户介绍完产品后，客户的态度与自身的不足，需要持续反省与改进。
- 没有做竞品对比：会被质疑你开发的产品价值，可以参考这种gitlab vs github的写法。
- 典型案例做的太晚：成功案例都在你的脑子里，组员无法复制你的推广，可以参考这种写法。
- 与管理者讨论方案：只对管理者进行汇报，不要讨论细节，因为时间够呛
- 找低级职员讨论方案：绝对不要去找低级别的员工讨论“流程级”工作，只讨论效率/体验级的即可，这些讨论会让你
- 陷入业务细节的海洋中，最终很容易做成单点外包工具
- 很多人的脑子不清晰（全局逻辑观太弱），容易开无用的会议
典型案例非常重要，需要反复整理思考
- 客户间会有私下交流，要时刻为用户准备宣传材料
- 时刻思考A项目的成功与B项目有什么gap？为啥B项目的客户很"笨"？
- 如果不会写，就用最笨的before after去慢慢雕琢
推广：可复制的流程
背景
假如你同时兼容RD与Pre-sale，由于初始人力限制，你的时间相当程度地会耗在RD流程中，无暇顾及Pre-sale流程，新增客源速度缓慢。
招聘人后，怎么让大家快速干活？新人能分担什么工作？扩大到10个新人后能带的动吗？
这时无论是否招人，你都在矛盾中前进，这时就需要“”可复制“的流程
复制流程
蓝海期间，如果要加速获取用户，科普非常重要。
要会钻研写各种Presentation，可以参考其它SaaS公司的介绍流程
本侧要生产一堆PPT，虽然大家都不喜欢写，但是架不住领导多啊，还是很有用。
总结
虽然本人是RD角色，但是
- 日常接触了供应商的高级tech-sale，高级sales的逻辑能力是极强的
- 任何工作都愿意搞一下
因此也在RD工程中兼任了一些推广工作，本文记录了推广过程的坑。后续有时间继续完善相关推广细节。