编辑导语：B端产品基本都是功能类软件，服务于一个利益共同体；但在下沉市场的用户对这类软件不不感兴趣，在操作过程中会遇到很多困难；本文是作者的一个真实经历，做一个B端下沉项目遇到的问题，我们一起来看一下。

身处于执行层面，总是习惯基于合理性来考虑问题：B端软件基本都是功能类软件，操作难度大，使用场景范围小，核心指标应该为交易额而非流量；而下沉市场用户对“效率”并不上心，对复杂软件缺乏耐心，付费意愿与付费能力低。

所以2B的软件下沉是一个悖论，吃力又不讨好，但KPI、政策等因素会催生一些跑偏的决策。

抛开路线是否合理，只关注如何执行，以下是思路和方案：

一、解题思路

1. 困难

首先我们需要明确，在项目中我们可能会遇到哪些困难。

在正式推进之前，我们的团队在某个欠发达的县城做过一个demo项目，尝试让一所学校使用产品，其中遇到许多比较有创意的困难：

• 用户（老师）对软件的学习能力非常差，普遍缺乏探索新功能的兴趣。
• 让用户（老师）使用新软件，必须得让他们丢掉旧习惯，这令他们非常不安。
• 用户（老师）对互联网的了解不够，导致缺乏判断能力，防备心过强。
• “效率”对用户（老师）的吸引力不足，导致产品的吸引力不足。
• 客户（校领导）要求用户使用产品，用户的态度非常被动、消极。
• 客户（校领导）拒绝外人干涉他们的内部管理，技术支持团队难以发现他们使用中的问题对他们提供指导。

最大的困难都集中在用户层面；当用户与产品不那么匹配时，如何令产品为用户创造价值呢？

2. 解题

• 针对用户特点建立完善的客户服务体系，不局限于客服回复用户问题，也包括各种能帮助客户使用产品的措施。
• 在产品无法更改的情况下，基于场景，筛选出对用户来说较为有用的功能，阐述功能的作用，通过与传统方式对比，体现出新产品功能的优势。
• 在以活跃为核心指标的前提下，通过公关等方式，让校领导设置一些软件上的规则，教师必须使用软件才能遵守规则，例如每日签到等。
• 展示其他客户使用产品的案例，重点展示客户领域的重量级同行，例如一些教育领域的知名高校、权威机构也在使用本产品，让客户解除戒备。
• 使用客户可以理解的方式来阐述产品与功能，减少互联网名词的使用，尽量避免电子文件，使用纸质材料，推广时以线下为主。

二、具体执行策略

1. 支持

• 设立便于联系的客服，创建技术支持群，或对接到每一位客户。
• 制作完善的操作指导手册，以解决用户使用过程中的困惑，或为用户提供操作指导。
• 制作直观有吸引力的功能清单，让客户知道这些功能的存在。

2. 推广

• 重新设计描述产品的方式，从0让用户理解产品。用一句话或者一张图，把产品精准贴切地阐述给从未接触过它的用户。
• 组织培训，培训中演示功能。
• 发放直观的营销资料，让客户对先进的产品有向往。

3. 公关

• 借助当地资源，减少推广过程中的困难。
• 请校领导规定教师必须使用软件。

三、关于价值的思考

1. 真实需求

根据逻辑，我们根据用户的需求设计出功能，再将功能用于实现用户需求时，理应是匹配的。

在一线城市中，客户大多数情况是已经了解自己的需求与产品的定位，在多个同类产品中作对比来判断自己需要哪一款。

所以，我们习惯用市场的眼光来看产品，做竞品分析，差异化设计，优化流程与体验，令我们的产品在对比中看起来优越。

事实上，我们应当关注用户的真实需求，老师希望学生把知识学懂，领导希望员工提高产出，员工希望工作更轻松愉快；这些想法可以拆分成为一个个目标，由功能去实现，但没有人的目标是“使用功能”。

2. 测试

整个项目可当作对产品的易用性、可用性的一次极端的测试，就像我们在零下四十度测试设备能否正常工作那样。

在较为严格的环境中测试产品功能是否有价值、操作是否简单，结构是否明晰，往日被忽略的小问题会凸显放大。

3. 传递价值的方式

产品应当根据用户的特征去设计，产品价值也应当根据用户的特征去传递。

抛弃晦涩的互联网词汇后和计算机术语后，寻找简介直观的表达方式向用户解释“云端存储”、“离线工作”。

将产品的优势功能链接于用户切身处地经历着的场景，他们更能理解产品对他们有什么意义；否则这个产品只是来自遥远大城市的复杂玩具。

本文由 @Ual 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议