To B业务的运营工作（下）

Darcy 1年前

既然讨论到ToB业务，产品迭代是重中之重。所以这一部分主要分析“如何让产品更好用”的问题。

涉及到产品的开发与优化，运营的对内工作，主要是和产品经理打交道；对外的话，一方面是直接联系客户，另外一方面需要经常咨询前线的业务团队。所以这一块也最大程度体现了运营的“承接器”作用。

其中，“翻译”是个很重要的能力。

客户讲出来的问题，不一定是真正的产品需求，可能只是脑子里臆想出来的，甚至大家在想问题时，或多或少地只考虑“我要怎样怎样”，只管当前想要实现的功能与场景，而没有进一步去问“最终目的”是什么。可能达成某一个最终目的，会有个更好的实现方式。

所以，耐心倾听对方的描述，是基础能力；追究到底，挖出更多细节，进一步提炼、总结，才是考验能力水平的关键。

“运营”在介入产品迭代时，大致的工作流程有以下几个部分（所列内容限于行业经验，实际工作中另外再看）。

一、用户调研

无论是初次上线，还是后期的功能升级，最好是做一次用户调研，拿到客户的典型反馈。

当然，某一块功能设计，可能压根就有bug，大家都心知肚明，问客户还显得自己傻，那就赶紧修掉，也没什么好说的。

做用户调研时，先确定对象是哪类人群。我们的产品，面临的用户人群和付费人群，可能就不是同一类。

比如，付费人群优先考虑的是成本问题，或者投资收益率。调研的问题，或者最终目的，就是为了确认对方能不能为我们的产品付费、续约。除了自己家的产品，还得考虑市面上的竞争对手，他们的产品功能和报价，对客户的吸引力到底如何。

用户人群，也就是天天用你这款产品的人，可能觉得某一块功能设计很别扭，但是没办法讲清楚细节，索性就不讲了。时间一长，就觉得你产品不好用，或者“就那样”。所以对于这类人群，应该是在产品迭代时重点咨询的对象，而且要定期去问，让用户感受到服务方的重视。

具体的操作上，一般会用问卷调查，目前比较推荐“腾讯文档”的在线表单功能，因为可以生成微信小程序、链接地址，应用上更广，也方便些。

相比较问卷，我更倾向于直接沟通，当面比电话好。运营工作，一定要见到客户当面，有条件一定要去找客户聊天，同时在现场观察他们是怎么用产品。一天下来的收获，比办公室里干一个礼拜要强。更关键的是，这类机会更好做客情，以后再找人家也方便些。

二、反馈汇总

产品使用上的问题，一定要建个稳定通道收回来。

按照对接客户的部门类型不同，各个通道收集信息的侧重点也不一样。

比如，客服部门，一般是在线接待一些紧急问题，多数情况下是bug，或者系统崩溃。那这类反馈，要求直接对接到各个模块的技术开发，马上排查定位，马上给出解决方案。运营在这里面作用不大，遇到集中爆发式的问题，可能会参与、分析、统计具体情况；但多数时候，给运营开个权限，能跟进具体进度即可。

如果前线团队、客户反馈的问题，更多是产品需求之类，无论是哪个部门收到的，最好是收到运营这边，形成统一的需求管理池。

这个需求池，我可能比较习惯用表格管理，列出的具体明细，包括日期、客户、地区、需求描述、功能模块、建议优先级、跟进人、进度状态等。可以每周一次对接产品经理，同步前先把没什么价值的、无理的需求做个筛选过滤掉。

收集通道的话，看各家公司的发展情况。大公司内，一般都有开发完善、直接能用的内部工具，这样最好，保密性高，也符合内部对接流程。中小型公司可以采购现成的工具，比如teambition，是一款不错的协同管理工具。初创型公司，最常见的还是比较原始的表格管理，三五个人之间来回传一传，倒也影响不大。

三、需求排期

最近和新同事对接、沟通时，讲到需求排期这一块产生了分歧。

我一直认为，运营要参与需求排期，理由很简单，运营熟悉客户和市场。但是对方认为这是产品经理的工作范畴，需求排期更多看内部的技术资源，而不仅仅是前线的缺口。

其实后来仔细一考虑，我的观点里，大前提是运营要懂客户和市场；但要是不懂的话，那就是“外行抢着领导内行”。至于对方讲的内部技术资源，我认为只是一个客观因素，产品经理来安排、协调，当然是最好，运营在其中能够不停传递压力即可。

说到底，运营在需求排期中，一直都是建议者的角色，拍板的还是产品经理。

一般情况下，这几类问题，我会把优先级提至最高：

影响客户开启、使用的。用都用不了，也就别谈什么细节了。
竞品抢单的功能。能让客户转用另一家产品的功能，一定是好功能，或者说，是很好的“买单”功能。一定要随时保持领先。
跟钱相关的。比如，客户能用来开单、增加营收、缩减成本等等，哪怕别的地方都很烂，但是能给客户省钱，甚至是赚钱，对方也会捏着鼻子认的。
提升工作效率的。这一点不好评判，因为提效，本来就见效慢，尤其面向B端客户。只是前期的对接、培训，就会花一定的时间，更别提对方能够稳定的用起来；还有一点，提效，意味着人力缩减，但凡有点脑子的员工，只要发现有抢饭碗的家伙，抵制是肯定存在的。

四、产品设计

老实讲，某个产品的不同生命周期，运营在“产品设计”的参与程度上，也是不一致的。从我个人的感官上来判断，产品起步、扩张期，要重点参与。

这部分的工作，主要还是产品经理的职责，运营起支援、辅助作用。如果遇到很有经验的产品经理，那几乎是不用操什么心。

而运营在这里面起作用，也是依据前线实情、客户反馈等信息来参与，而不是拍脑袋、乱参谋。“我觉得……”这类话不应该随便冒出来；而应该是“我通过……得出的判断是……”。

对于某一块的功能设计，大体上产品经理的思路，一般问题不大；但是最终上线后的样子，要是出现照猫画虎的例子，可能就是开发的锅。所以运营在产品设计、开发中，起到的是监督、督促检查的作用。盯好时间节点、做好验收工作就可以。

特殊情况下，比如产品经理业务多，精力跟不上，而某个需要更新的功能，又不需要大修大改，那运营可以代理完成产品设计，对接开发前给产品经理同步一下，也不是不可以。前提是熟悉产品设计的流程、工具、对接方式和人选，尽量不要造成额外的打扰，否则便是越界。

五、测试上线

产品设计、开发完成后，一般会在测试环境内走一遍，这里面产品经理、测试工程师都会参与。

运营也需要，主要目的不是为了看功能怎么样，而是快速摸索操作方式，整理出对应的使用文档，方便上线后对外做内容输出、培训。

每接触一款产品，运营一定要开个自己的后台权限，尽可能丰富地搭建每一个功能服务场景。在日常对接客户时，每遇到新的使用场景时，最好是自己亲自试一遍，不要怕麻烦，总比被别人怼了要强。

上线前的对内产品培训，操作方法什么的，其实也很简单，把基本逻辑讲清楚，现场演示一遍就差不多了。

但是运营在培训时，更多需要重点突出的内容是“为什么要这么设计”。因为每一个产品需求，最初背景都是来源于客户反馈，更进一步说，是市场环境的倒逼（原谅我到现在还没遇到哪个产品经理有让人惊艳的前瞻思维）。

能把这个点讲透了，才算是把真正有价值的核心内容，灌输到前线那里。

六、手册编写

上线前的测试工作，是为了方便自己掌握所以产品细节；除了自己会用，还得教给别人会用，那就需要出一个手册之类的文档。

编写使用手册，有几个工作要点：

章节目录要尽可能细分。每个小模块的讲解，阅读文档不超过三分钟，观看视频不超过五分钟。
功能介绍，要明确列出背景、参数、配置路径，一定要带图片展示。
文字要凝练、准确，尽可能全部用中文表达。减轻用户的阅读门槛。
部分复杂的模块，文字不好表述的，可以录制GIF图片格式，或者视频。但最好是文字表达。
每完成一次编写、更新，交由最新入职的同事来预览。以小白身份来检测文档的适用性。推荐一个内部制度：每位新入职的运营，都要参与产品文档的更新，自己制作的部分，都要接受后来者的检验。
对外发布的内容，统一用pdf格式，或者只开“阅读权限”。

七、数据监控

做数据方面的挖掘和监控，也是运营工作中相当重要的一部分。

具体监控的几个指标，参考如下：

客户合作情况：包括签约数（每日增长书）、续费率、每月回款金额，对应各区的分布占比。有条件的可以监测合作竞品的客户名单。
客户使用情况：打开率、使用时长、核心功能的产出效益（挣不挣钱、省不省事），具体维度不做详细展开。
重点客户名单：合作单价高、圈内影响大、转介绍多、日常积极配合的，都可以列为重点客户。这个名单内要看的数据维度，起码要每周更新一次，还得同步到具体跟进人。
待续费客户名单：可以按月来做统计、跟进。需要明确的是，续费沟通，一般要提前1-2个月展开工作。比如现在是6月份，就要盯8月份的续费名单和具体续费进度。没续费的原因要挖出来，因为产品使用不便的，核查需求排期和bug进度表，提优先级。

小结

关于运营要参与产品更新的工作内容，我能罗列出的大致就是这些。零零碎碎的其实还有一些，但也属于可有可无，此处不做具体阐述。

To B业务，因为客户对象的复杂性，导致运营工作也相对繁复起来。我在文中也多次强调，这类工作需要投入的精力很大，前期积攒的经验、教训都很宝贵，时刻做好记录是一件很有必要的事。

在职业规划中，运营的成长性也比较高，因为要和客户打交道，所以还需要在客情上多做储备。某些看起来很难做的事，或者很难实现的指标，技术攻关不一定能很快完成，但是通过运营手段可以。

最后借用一句话做结尾：“不要觉得运营工作多简单，假如这个生意交给你，你要这么做？”

相关链接：

To B业务的运营工作（上）

To B业务的运营工作（中）

本文由 @段琛授权发布于运营派。未经许可，禁止转载