科技猎交易平台类商家端的管理赋能产品设计模式
导读：我们常见的电商、生活服务领域，都可以归纳为交易平台，通过合作的或者自营的商家提供服务。平台商家端的产品，通常会有订单交易、商家营销的工具、供应链等给商家的服务、商家管理等部分。本文主要写商家管理赋能这一部分，作者从自己具体负责的项目出发，分享了商家端管理业务的产品设计的相关流程，供大家一同参考学习。
一、什么是商家的管理业务？
商家管理业务，指的是平台对商家服务的管控。商家是服务提供方，平台是规则制定方，因此商家在平台中需要遵循平台的游戏规则，包括商家的准入，引流，惩罚，退出等各方面。
举个例子，美团饿了么这些外卖平台中，商家指的是餐饮店和骑手。
首先，美团们会有对商家的要求，比如几分钟内需要接单，几分钟内要出餐，下单成功的菜不能售完等等，做得好的会给更多的流量以及其他的好处，做的不好的会减少流量，甚至要求商家退出平台。对骑手有接单数量、送达时间等要求。
然后，在每个城市都会有专人在线下通过沟通交流等各种形式，对商家和骑手进行管理，管理商家的角色可能属于市场部，管理骑手通常一个城市会有多个网点，每个网点有管理人员管理多个骑手。
根据平台性质不同，商家会有合作的和自营的，比如外卖中，餐馆商家是合作的，骑手是自营的。相比而言合作的商家管理会弱一些，自营的管理强一些，不过基本规则是类似的。外卖骑手、打车司机这类角色虽然名义上不叫商家，但他们也是服务提供方，在商家管理这个体系中，这类小b的管理也包含在内。
不同行业的管理力度也不同，像餐饮酒店这些行业，也不需要平台过多的管理。需要强管理的主要是两种类型，一是重销售、交易链路长的行业，比如买房买车装修，平台为了更多成交肯定需要介入销售过程，第二骑手司机这类小B，需要平台为他们制定专业规则。
这里的管理，和公司高层对公司员工的内部管理不是一回事，即使是自营的平台。公司内部管理领域是老板看业务数据，并不标准化，大部分公司是用BI系统解决。而线下管理通常是覆盖全国很多城市，一个网点管理多个商家，管理业务标准化，不是上级管下级的模式，所以需要线下管理的团队和给这些人用于管理赋能的产品。
管理业务本身是由公司负责商家端的业务部门制定规则，以线下的管理为主，这是一个偏向业务主导的领域。管理业务的产品面向线下的管理人员，将管理业务规则在线上跑通，并给他们提供商家的各项业务数据，辅助管理的功能。
产品主要的作用是赋能，核心目的是提升管理的效率，和减少管理人员的成本。通过线上数据的管理，比人工管理准确性和效率都会更高，管理效率高了之后，每个人能管理的商家数量可以从几家变成几十家，站在公司的角度能为公司节省人力成本。
二、管理业务规则和场景的调研分析
下文以我们公司的管理业务为例，复盘下整个管理赋能产品的迭代过程。
第一步是业务模型拆解
我们公司主营卖车业务，是一个销售导向型的业务，我们管理的内容自然是商家卖车的过程。我们属于自营的模式，由线下的门店提供服务，我们在各个城市都有线下管理人员负责管理门店，一个人管理十几二十家，这些管理人员属于线下渠道部门，叫做销售主管。每个销售主管有对门店减少引流和关闭的权力。
线下管理人员有大区经理-城市经理-销售主管这样的分级，每个销售主管会关注自己所属片区总体的情况，大区经理和城市经理也会关注他下面所有门店的情况。门店是小型社区店，店里一个店长加两三个销售人员，管理对象以店长为主，因此管理赋能产品主要针对线下管理人员——店长这一层。
第二步是业务规则对接
线下管理的依托是管理业务规则。我们对于门店的管理规则，主要在关店，引流权和实物奖励这几个方面。几项核心数据未达标的门店会被关引流权，更差的门店则会直接关店。部分外拓的数据达到目标值，会有实物奖励。
此外针对每个门店会计算一个分值判断门店经营的好坏，平台分派线索时，分值高的门店就会被分配更多的线索。管理人员和商家每日需要参考的数据，和需要重点关注的门店，都依据这些规则产生。
第三步是管理业务场景的调研
我们跟随管理人员一起来到线下，参与到管理业务中。具体的管理场景，按月维度依次是月初制定目标，月中临近月末时跟进催促，和月末总结复盘，按日则是每天白天执行各项销售过程，晚上总结，提交日报，表彰排行前几的门店。
管理的方式，平时每天会通过微信群进行线上管理，督促门店完成每日的过程指标，查看日报。定期会找做的不好的门店去线下巡店，或者组织店长开会，针对具体问题进行指导。其他还包括月度的总结，销售的培训，差的门店关店等。因为是重销售的模式，管理也会带一些打鸡血的方式。
通过调研，可以看出我们产品能给这些线下管理人员赋能的内容。
三、产品内容和迭代阶段
最初这一块产品是在一个融合其他业务的BI系统里，没有针对具体的场景设计，数据也不是很全，用起来很麻烦。为了提升管理效率，能让销售主管比较方便的管理多个门店，我们专门针对这块管理业务设计了管理赋能产品。
整个产品迭代分为了3个阶段，第一阶段基建，根据管理业务规则，提供核心数据的展示；第二阶段场景化，针对具体的管理场景优化功能；第三阶段赋能，通过数据给出各门店经营的分析总结。
刚上线时，需要能尽快满足查数据的需求，第一阶段提供的是基础的数据报表功能，给用户提供不同维度的数据展示。具体有数据报表模块：每个门店的历史数据，支持手动导出；实时数据模块，门店当天的核心数据统计；以及门店和销售人员的排行榜。这是最基础的部分，脱离了数据管理无从谈起。
第一阶段虽然满足了查数据需求，但本质上更像是一次迁移，使用起来还是和原来一样有不方便的地方。有些数据不全，有些数据比如昨日数据，一个个店看很麻烦，需要到PC上人工导出。很多管理的行为，还是停留在人工和微信群。
在第二阶段，我们拆解了用户和具体的管理场景，谁在什么环境下需要查看什么数据，管理什么，产品上做一些工具和数据报表的优化，帮助提升管理的效率。
第一，提供工具形态的功能 。门店每天需要提交日报，我们设计了销售和门店的日报功能，包含当天数据和用户自己写的部分，提交后销售主管能够看到，这样比在微信群里写日报要快捷的多。管理人员会给门店设置每月目标和每日过程数据指标，我们设计了目标设定功能，销售主管可以给门店设定目标，跟进完成情况，这个目标门店每天都看得到。
这一个部分虽然只是工具，但它们是线下管理场景在产品上的体现，比起只展示数据，这样能够引导门店认知PDCA这么一个每日工作流的模型，在销售主管的督促下去使用这部分功能。
第二，数据展示的场景化 。时间维度上，销售主管最常看的是当天，昨天，和当月累计这三个维度，所以把这3个维度单独提取出来。开始只简单的区分了实时数据和离线数据，每家门店有些维度的数据就很难直接查到，比如昨天的数据。具体的数据项，在原来的基础上继续拓展一些销售主管会关注的数据。
第三，每个门店的标签和筛选 。一个管理人员会管理十几二十家门店，有些门店是做得好的，有些是做的不好要重点关注的。之前只有一个简单的门店列表，每个门店没有任何区分标识，门店是否有引流的管理业务规则也没有体现。结合上一点，这一阶段重构了门店数据展示的页面，根据管理人员比较关注的核心数据，对数据差的、没做到规则的门店打标签，销售主管可以依据这个找到需要重点关注的门店，针对性的巡店拜访。
前两个阶段虽然有了数据，但不管销售主管还是门店店长，他们的数据分析能力并不是很强，他们会看每天的数据结果，但不太会分析，难以透过数据总结规律。所以第三阶段在第二阶段的基础上，增加了我们帮他们分析的部分。只有通过综合性的数据对比和分析，才能全盘地判断商家经营的好坏，产出有价值的管理建议。
这个阶段最开始，我们做了一些数据分析工具的工具，比如转化漏斗，客户来源分析等，后来发现这些功能最多只对管理层有用，销售主管们不一定看得懂，访问量很低。于是我们的思路从给他们数据分析工具，变成了帮助他们分析。
我们提供了门店经营分析模块，针对每个销售主管和门店产出一份经营报告，定期更新，利用各个过程数据给门店打分，并通过门店间横向的对比列出做得好和不好的地方，总结出提升点和提升方法。这个模块提供给每个管理人员和门店店长，可以在他们月度定期复盘的时候，全方位了解自己的经营情况。
除了门店，也有对每个销售人员的分析。我们利用各个过程数据，通过算法给每个销售人员评分，能较为客观的评价出销售人员的能力。之前销售主管管不到每一个销售，是因为销售人员数量太多，没法关注到每个人，现在有了评分后，销售主管就能直接管到每个销售人员，然后可以对差的销售进行针对性培训，人员更换等。
四、产品设计过程的注意点
管理赋能方向的产品有点类似于数据产品，在产品设计过程中，和用户端产品以及后台产品会有一些区别。产品设计的过程中的一些注意点如下：
- 确定数据统计的时间维度，用离线数据还是实时数据。这是两种数据统计类型，离线数据的大致原理是通过一段数据查询的指令，每天定时执行完成统计，通常用于统计历史数据。实时数据则是通过实时任务进行，常用于展示当天的几个核心数据，复杂度和出错率都比离线数据要高。
- 理清数据的查询逻辑，有几个查询规则，是否去重，触发/统计的时间点等。取数逻辑需要结合实际的业务需求和数据统计原理制定，有时候会有很多不那么容易想到的限定条件。比如跟进客户数这个数据，以什么操作作为完成一次跟进，同一个客户一段时间内被跟进多次是否要去重，客户被不是他的销售或门店跟进是否算一次跟进，等等。一旦遗漏了几个限定条件，遇到问题后数据就会不准。
- 保证各个平台的数据口径统一。每个数据有变动或者加新数据时，都需要和其他平台的产品一起确认。这是很重要的一点，同一个数据如果各方口径不统一，那不同用户看到的就不是同一个数据，理解错了对业务造成的影响会很大。
五、如何评估产品上线后的效果？
对于以报表为主的管理赋能产品，如何评估产品上线后的效果是一个难题。这块产品很难直接用数据表现效果，因为它并没有直接对业务本身产生影响，对业务只有间接的影响，而且用户的使用方式也只是查看数据为主，并不需要在页面上做更多的操作。
比如一个门店数据报表页面，我们只能统计到页面的pvuv，并没有像电商那样的下单转化率、活动参与人数这些类型的数据。从业务结果的角度，无法判断出这么一个数据报表页面对门店的订单量、新增客户数、客户回访数这些业务数据是否有提升。从公司人力成本角度，可以通过统计一个人管理门店数据看是否提升管理效率，但这是一个长期的数据，取决于公司决策。
所以这一块只能通过一些间接的方法来判断上线后是否有效果。我认为的几个相对可行的办法：
数据报表类，数据只能统计到页面的PVUV，有时候访问人数不能说明什么，因为报表该看的时候总得看，无法看出报表数据设计的是否合理。另外可以统计bug数量判断是否稳定。数据类产品主要是基建方面的作用，重在稳定性和准确性，所以可以通过统计bug来看是否准确和稳定，不过这一点是研发同学更关注的。
工具类，比如日报、目标模块，可以统计使用的人数/商家数和覆盖率，以提交日报/完成目标设置作为使用的标准。这项数据可以看有多少比例的用户接受、认可这个工具，如果使用人数少，很多人继续在微信群里提交日报之类的，那就需要对这块功能本身做一次复盘优化。
经营分析报告类，数据上能统计到的也只是pvuv，但这一块属于不是一定需要看的功能，可以参考访问人数来判定用户对这块功能的使用和接受程度。另外也可以通过用户的线下调研，询问用户对该功能是否满意，报告里提出的经营建议是否会被采纳等，看看用户真实的反馈。
#专栏作家#
潘帕斯雄鹰，人人都是产品经理专栏作家，进击、踩坑中的产品狗一枚，关注互联网，写过小说，看过哲学。简书：潘帕斯雄鹰。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash ，基于 CC0 协议。