交易平台类商家端的管理赋能产品设计模式

0 评论 6295 浏览 7 收藏 19 分钟

导读:我们常见的电商、生活服务领域,都可以归纳为交易平台,通过合作的或者自营的商家提供服务。平台商家端的产品,通常会有订单交易、商家营销的工具、供应链等给商家的服务、商家管理等部分。本文主要写商家管理赋能这一部分,作者从自己具体负责的项目出发,分享了商家端管理业务的产品设计的相关流程,供大家一同参考学习。

一、什么是商家的管理业务?

商家管理业务,指的是平台对商家服务的管控。商家是服务提供方,平台是规则制定方,因此商家在平台中需要遵循平台的游戏规则,包括商家的准入,引流,惩罚,退出等各方面。

举个例子,美团饿了么这些外卖平台中,商家指的是餐饮店和骑手。

首先,美团们会有对商家的要求,比如几分钟内需要接单,几分钟内要出餐,下单成功的菜不能售完等等,做得好的会给更多的流量以及其他的好处,做的不好的会减少流量,甚至要求商家退出平台。对骑手有接单数量、送达时间等要求。

然后,在每个城市都会有专人在线下通过沟通交流等各种形式,对商家和骑手进行管理,管理商家的角色可能属于市场部,管理骑手通常一个城市会有多个网点,每个网点有管理人员管理多个骑手。

根据平台性质不同,商家会有合作的和自营的,比如外卖中,餐馆商家是合作的,骑手是自营的。相比而言合作的商家管理会弱一些,自营的管理强一些,不过基本规则是类似的。外卖骑手、打车司机这类角色虽然名义上不叫商家,但他们也是服务提供方,在商家管理这个体系中,这类小b的管理也包含在内。

不同行业的管理力度也不同,像餐饮酒店这些行业,也不需要平台过多的管理。需要强管理的主要是两种类型,一是重销售、交易链路长的行业,比如买房买车装修,平台为了更多成交肯定需要介入销售过程,第二骑手司机这类小B,需要平台为他们制定专业规则。

这里的管理,和公司高层对公司员工的内部管理不是一回事,即使是自营的平台。公司内部管理领域是老板看业务数据,并不标准化,大部分公司是用BI系统解决。而线下管理通常是覆盖全国很多城市,一个网点管理多个商家,管理业务标准化,不是上级管下级的模式,所以需要线下管理的团队和给这些人用于管理赋能的产品。

管理业务本身是由公司负责商家端的业务部门制定规则,以线下的管理为主,这是一个偏向业务主导的领域。管理业务的产品面向线下的管理人员,将管理业务规则在线上跑通,并给他们提供商家的各项业务数据,辅助管理的功能。

产品主要的作用是赋能,核心目的是提升管理的效率,和减少管理人员的成本。通过线上数据的管理,比人工管理准确性和效率都会更高,管理效率高了之后,每个人能管理的商家数量可以从几家变成几十家,站在公司的角度能为公司节省人力成本。

二、管理业务规则和场景的调研分析

下文以我们公司的管理业务为例,复盘下整个管理赋能产品的迭代过程。

第一步是业务模型拆解

我们公司主营卖车业务,是一个销售导向型的业务,我们管理的内容自然是商家卖车的过程。我们属于自营的模式,由线下的门店提供服务,我们在各个城市都有线下管理人员负责管理门店,一个人管理十几二十家,这些管理人员属于线下渠道部门,叫做销售主管。每个销售主管有对门店减少引流和关闭的权力。

线下管理人员有大区经理-城市经理-销售主管这样的分级,每个销售主管会关注自己所属片区总体的情况,大区经理和城市经理也会关注他下面所有门店的情况。门店是小型社区店,店里一个店长加两三个销售人员,管理对象以店长为主,因此管理赋能产品主要针对线下管理人员——店长这一层。

第二步是业务规则对接

线下管理的依托是管理业务规则。我们对于门店的管理规则,主要在关店,引流权和实物奖励这几个方面。几项核心数据未达标的门店会被关引流权,更差的门店则会直接关店。部分外拓的数据达到目标值,会有实物奖励。

此外针对每个门店会计算一个分值判断门店经营的好坏,平台分派线索时,分值高的门店就会被分配更多的线索。管理人员和商家每日需要参考的数据,和需要重点关注的门店,都依据这些规则产生。

第三步是管理业务场景的调研

我们跟随管理人员一起来到线下,参与到管理业务中。具体的管理场景,按月维度依次是月初制定目标,月中临近月末时跟进催促,和月末总结复盘,按日则是每天白天执行各项销售过程,晚上总结,提交日报,表彰排行前几的门店。

管理的方式,平时每天会通过微信群进行线上管理,督促门店完成每日的过程指标,查看日报。定期会找做的不好的门店去线下巡店,或者组织店长开会,针对具体问题进行指导。其他还包括月度的总结,销售的培训,差的门店关店等。因为是重销售的模式,管理也会带一些打鸡血的方式。

通过调研,可以看出我们产品能给这些线下管理人员赋能的内容。

三、产品内容和迭代阶段

最初这一块产品是在一个融合其他业务的BI系统里,没有针对具体的场景设计,数据也不是很全,用起来很麻烦。为了提升管理效率,能让销售主管比较方便的管理多个门店,我们专门针对这块管理业务设计了管理赋能产品。

整个产品迭代分为了3个阶段,第一阶段基建,根据管理业务规则,提供核心数据的展示;第二阶段场景化,针对具体的管理场景优化功能;第三阶段赋能,通过数据给出各门店经营的分析总结。

刚上线时,需要能尽快满足查数据的需求,第一阶段提供的是基础的数据报表功能,给用户提供不同维度的数据展示。具体有数据报表模块:每个门店的历史数据,支持手动导出;实时数据模块,门店当天的核心数据统计;以及门店和销售人员的排行榜。这是最基础的部分,脱离了数据管理无从谈起。

第一阶段虽然满足了查数据需求,但本质上更像是一次迁移,使用起来还是和原来一样有不方便的地方。有些数据不全,有些数据比如昨日数据,一个个店看很麻烦,需要到PC上人工导出。很多管理的行为,还是停留在人工和微信群。

在第二阶段,我们拆解了用户和具体的管理场景,谁在什么环境下需要查看什么数据,管理什么,产品上做一些工具和数据报表的优化,帮助提升管理的效率。

第一,提供工具形态的功能。门店每天需要提交日报,我们设计了销售和门店的日报功能,包含当天数据和用户自己写的部分,提交后销售主管能够看到,这样比在微信群里写日报要快捷的多。管理人员会给门店设置每月目标和每日过程数据指标,我们设计了目标设定功能,销售主管可以给门店设定目标,跟进完成情况,这个目标门店每天都看得到。

这一个部分虽然只是工具,但它们是线下管理场景在产品上的体现,比起只展示数据,这样能够引导门店认知PDCA这么一个每日工作流的模型,在销售主管的督促下去使用这部分功能。

第二,数据展示的场景化。时间维度上,销售主管最常看的是当天,昨天,和当月累计这三个维度,所以把这3个维度单独提取出来。开始只简单的区分了实时数据和离线数据,每家门店有些维度的数据就很难直接查到,比如昨天的数据。具体的数据项,在原来的基础上继续拓展一些销售主管会关注的数据。

第三,每个门店的标签和筛选。一个管理人员会管理十几二十家门店,有些门店是做得好的,有些是做的不好要重点关注的。之前只有一个简单的门店列表,每个门店没有任何区分标识,门店是否有引流的管理业务规则也没有体现。结合上一点,这一阶段重构了门店数据展示的页面,根据管理人员比较关注的核心数据,对数据差的、没做到规则的门店打标签,销售主管可以依据这个找到需要重点关注的门店,针对性的巡店拜访。

前两个阶段虽然有了数据,但不管销售主管还是门店店长,他们的数据分析能力并不是很强,他们会看每天的数据结果,但不太会分析,难以透过数据总结规律。所以第三阶段在第二阶段的基础上,增加了我们帮他们分析的部分。只有通过综合性的数据对比和分析,才能全盘地判断商家经营的好坏,产出有价值的管理建议。

这个阶段最开始,我们做了一些数据分析工具的工具,比如转化漏斗,客户来源分析等,后来发现这些功能最多只对管理层有用,销售主管们不一定看得懂,访问量很低。于是我们的思路从给他们数据分析工具,变成了帮助他们分析。

我们提供了门店经营分析模块,针对每个销售主管和门店产出一份经营报告,定期更新,利用各个过程数据给门店打分,并通过门店间横向的对比列出做得好和不好的地方,总结出提升点和提升方法。这个模块提供给每个管理人员和门店店长,可以在他们月度定期复盘的时候,全方位了解自己的经营情况。

除了门店,也有对每个销售人员的分析。我们利用各个过程数据,通过算法给每个销售人员评分,能较为客观的评价出销售人员的能力。之前销售主管管不到每一个销售,是因为销售人员数量太多,没法关注到每个人,现在有了评分后,销售主管就能直接管到每个销售人员,然后可以对差的销售进行针对性培训,人员更换等。

四、产品设计过程的注意点

管理赋能方向的产品有点类似于数据产品,在产品设计过程中,和用户端产品以及后台产品会有一些区别。产品设计的过程中的一些注意点如下:

  1. 确定数据统计的时间维度,用离线数据还是实时数据。这是两种数据统计类型,离线数据的大致原理是通过一段数据查询的指令,每天定时执行完成统计,通常用于统计历史数据。实时数据则是通过实时任务进行,常用于展示当天的几个核心数据,复杂度和出错率都比离线数据要高。
  2. 理清数据的查询逻辑,有几个查询规则,是否去重,触发/统计的时间点等。取数逻辑需要结合实际的业务需求和数据统计原理制定,有时候会有很多不那么容易想到的限定条件。比如跟进客户数这个数据,以什么操作作为完成一次跟进,同一个客户一段时间内被跟进多次是否要去重,客户被不是他的销售或门店跟进是否算一次跟进,等等。一旦遗漏了几个限定条件,遇到问题后数据就会不准。
  3. 保证各个平台的数据口径统一。每个数据有变动或者加新数据时,都需要和其他平台的产品一起确认。这是很重要的一点,同一个数据如果各方口径不统一,那不同用户看到的就不是同一个数据,理解错了对业务造成的影响会很大。

五、如何评估产品上线后的效果?

对于以报表为主的管理赋能产品,如何评估产品上线后的效果是一个难题。这块产品很难直接用数据表现效果,因为它并没有直接对业务本身产生影响,对业务只有间接的影响,而且用户的使用方式也只是查看数据为主,并不需要在页面上做更多的操作。

比如一个门店数据报表页面,我们只能统计到页面的pvuv,并没有像电商那样的下单转化率、活动参与人数这些类型的数据。从业务结果的角度,无法判断出这么一个数据报表页面对门店的订单量、新增客户数、客户回访数这些业务数据是否有提升。从公司人力成本角度,可以通过统计一个人管理门店数据看是否提升管理效率,但这是一个长期的数据,取决于公司决策。

所以这一块只能通过一些间接的方法来判断上线后是否有效果。我认为的几个相对可行的办法:

数据报表类,数据只能统计到页面的PVUV,有时候访问人数不能说明什么,因为报表该看的时候总得看,无法看出报表数据设计的是否合理。另外可以统计bug数量判断是否稳定。数据类产品主要是基建方面的作用,重在稳定性和准确性,所以可以通过统计bug来看是否准确和稳定,不过这一点是研发同学更关注的。

工具类,比如日报、目标模块,可以统计使用的人数/商家数和覆盖率,以提交日报/完成目标设置作为使用的标准。这项数据可以看有多少比例的用户接受、认可这个工具,如果使用人数少,很多人继续在微信群里提交日报之类的,那就需要对这块功能本身做一次复盘优化。

经营分析报告类,数据上能统计到的也只是pvuv,但这一块属于不是一定需要看的功能,可以参考访问人数来判定用户对这块功能的使用和接受程度。另外也可以通过用户的线下调研,询问用户对该功能是否满意,报告里提出的经营建议是否会被采纳等,看看用户真实的反馈。

#专栏作家#

潘帕斯雄鹰,人人都是产品经理专栏作家,进击、踩坑中的产品狗一枚,关注互联网,写过小说,看过哲学。简书:潘帕斯雄鹰。

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

题图来自 Unsplash ,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!