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