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

简介：我们常见的电子商务和生活服务领域可以概括为通过合作或自营业务提供服务的交易平台。平台商户端的产品通常包括订单交易、商户营销工具、供应链等服务、商户管理等。本文主要撰写商业管理授权部分。作者从具体负责的项目出发，分享了商业管理业务产品设计的相关流程，供您参考和学习。 一、什么是企业管理业务？ 业务管理业务是指平台对业务服务的控制。商家是服务提供商，平台是规则制定者。因此，商家需要遵循平台的游戏规则，包括准入、排水、惩罚、退出等。 比如美团饿了么这些外卖平台，商家指的是餐厅和骑手。 首先，美团会对商家有要求，比如几分钟内接单，几分钟内吃饭，成功下单的菜卖不完等等。如果做得好，会给更多的流量等好处。如果做得不好，会减少流量，甚至要求商家退出平台。骑手有接单数量、送货时间等要求。 然后，每个城市都会有专人通过线下沟通等形式管理商家和骑手。管理商家的作用可能属于市场部。管理骑手通常在一个城市有多个网点，每个网点都有管理者来管理多个骑手。 根据平台的不同性质，商家会有合作和自营。例如，在外卖中，餐馆商家合作，骑手自营。相比之下，合作企业的管理会更弱，自营企业的管理会更强，但基本规则是相似的。虽然外卖骑手和出租车司机的角色名义上不叫商家，但他们也是服务提供商。在商业管理系统中，这种小b的管理也包括在内。 不同行业的管理力度也不同，餐饮、酒店等行业不需要太多的平台管理。需要强有力的管理主要有两种类型。一是重销售、交易环节长的行业，如买房、买车、装修等。为了更多的交易，平台必须干预销售过程，第二个骑手和司机B，平台需要为他们制定专业规则。 这里的管理与公司高层员工的内部管理不一样，即使是自营平台。在公司内部管理领域，老板看业务数据，不规范。大多数公司使用它BI系统解决方案。离线管理通常覆盖全国许多城市。一个网点管理多个业务，管理业务标准化，而不是上级和下级管理模式。因此，需要离线管理团队和产品来管理这些人。 管理业务本身是由公司负责业务的业务部门制定的，主要是线下管理，这是一个以业务为主导的领域。管理业务的产品面向线下管理人员，在线运行管理业务规则，为他们提供业务数据和辅助管理功能。 产品的主要作用是授权，其核心目的是提高管理效率，降低管理成本。通过在线数据管理，它将比手动管理更准确、更有效。管理效率高后，每个人可以管理的业务数量可以从几个变成几十个，从公司的角度可以为公司节省劳动力成本。 二、管理业务规则和场景的研究分析 以我公司的管理业务为例，对整个管理赋能产品的迭代过程进行了回顾。 第一步是拆解业务模型 我公司主要从事汽车销售业务，是一种以销售为导向的业务，我们管理的内容自然是企业销售汽车的过程。我们属于自营模式，由线下商店提供服务。我们有线下管理人员负责管理各城市的商店，一个人管理十几二十家，属于线下渠道部门，称为销售总监。每个销售总监都有权减少商店的排水和关闭。 线下管理人员包括区域经理-城市经理-销售总监。每个销售总监都会关注他所在地区的整体情况，区域经理和城市经理也会关注他下面所有商店的情况。商店是一家小型社区商店。商店里有一个商店经理和两三个销售人员。管理对象主要是商店经理。因此，管理授权产品主要针对线下管理人员-商店经理。 第二步是对接业务规则 线下管理依赖于管理业务规则。我们的店铺管理规则主要集中在店铺关闭、排水权和实物奖励等方面。几个核心数据不符合标准的商店将被关闭排水权，而较差的商店将直接关闭。一些扩展数据将获得实物奖励，以达到目标值。 此外，对于每个商店计算一个分数来判断商店的运营质量，当平台分发线索时，分数较高的商店将分配更多的线索。管理者和企业每天需要参考的数据和需要关注的商店都是基于这些规则。 第三步是调查管理业务场景 我们跟随管理人员离线参与管理业务。具体的管理场景，按月维度依次是月初设定的目标，月中临近月底时跟进催促，月，每天白天实施销售流程，晚上总结，提交日报，表彰顶级商店。 管理模式，通常每天通过微信群进行在线管理，督促商店完成日常流程指标，查看日报。定期找不好的商店离线检查商店，或组织商店经理会议，指导具体问题。其他还包括月度总结、销售培训、关闭差商店等。因为这是一种强调销售的模式，管理也会带来一些打鸡血的方式。 通过调查，我们可以看到我们的产品可以赋予这些线下管理者权力。 三、产品内容及迭代阶段 本产品最初是在其他业务的整合中BI在系统中，没有具体的场景设计，数据也不是很完整，使用起来很麻烦。为了提高管理效率，方便销售总监管理多家门店，我们专门为该管理业务设计了管理授权产品。 整个产品迭代分为三个阶段，第一阶段基础设施，根据管理业务规则提供核心数据显示；第二阶段场景，具体管理场景优化功能；第三阶段，通过数据分析总结。 刚上线的时候，需要尽快满足功能，为用户提供不同维度的数据显示。具体的数据报表模块：每个商店的历史数据，支持手动导出；实时数据模块，商店当天的核心数据统计；以及商店和销售人员的排名。这是最基本的部分，没有数据管理是不可能的。 虽然第一阶段满足了数据检查的需要，但本质上更像是一次迁移，使用起来和以前一样不方便。有些数据不完整，有些数据，比如昨天的数据，很麻烦，需要去商店PC人工导出。许多管理行为仍然停留在人工和微信群中。 在第二阶段，我们拆除了用户和具体的管理场景，谁需要检查什么数据，在什么环境下管理什么，优化一些工具和数据报表，以帮助提高管理效率。 一是提供工具形式的功能。商店需要每天提交日报。我们设计了销售和商店的日报功能，包括当天的数据和用户自己写的部分。提交后，销售总监可以看到，这比在微信群中写日报要快得多。经理将为商店设定月度目标和日常流程数据指标。我们设计了目标设置功能。销售总监可以为商店设定目标，并跟进完成情况。这家目标商店每天都能看到。 虽然这部分只是工具，但它们是线下管理场景在产品中的体现。与只显示数据相比，它们可以引导商店的认知PDCA在销售日常工作流模型，在销售主管的监督下使用这部分功能。 第二，数据显示的场景。在时间维度上，销售总监最常看到的是当天、昨天和当月的三个维度，所以他们单独提取了这三个维度。一开始，实时数据和离线数据的区别很简单，很难直接找到每个商店的某些维度的数据，比如昨天的数据。具体的数据项，在原始数据的基础上继续扩展一些销售总监将关注的数据。 第三，标签和筛选标签和筛选。经理会管理十几二十家门店，有的门店做得好，有的做得不好要重点关注。以前只有一个简单的店铺列表，每个店铺都没有区别标志，也没有反映商店是否有排水管理业务规则。结合最后一点，现阶段重构了门店数据显示页面。根据管理者关注的核心数据，对数据差、不规则的门店进行标签。销售总监可以找到需要关注的门店，并根据这一点进行有针对性的巡逻。 虽然前两个阶段有数据，但无论是销售总监还是商店经理，他们的数据分析能力都不是很强。他们会查看每天的数据结果，但他们不太擅长分析，很难通过数据总结规则。因此，第三阶段在第二阶段的基础上增加了我们帮助他们分析的部分。只有通过综合数据比较和分析，才能充分判断业务运营的质量，产生有价值的管理建议。 在这个阶段开始时，我们制作了一些数据分析工具，如转换漏斗、客户来源分析等。后来，我们发现这些功能最多只对管理有用，销售总监可能不理解，访问量很低。所以我们的想法从给他们数据分析工具到帮助他们分析。 我们提供了商店业务分析模块，为每个销售总监和商店制作业务报告，定期更新，使用每个过程数据对商店进行评分，并通过商店之间的水平比较列出好的和坏的地方，总结改进点和改进方法。该模块提供给每个经理和商店经理，他们可以在每月定期恢复时全面了解自己的业务状况。 除了商店，还有对每个销售人员的分析。我们使用每个过程数据，通过算法对每个销售人员进行评分，可以更客观地评估销售人员的能力。以前，销售不能负责每个销售之前，因为销售人员太多，不能关注每个人，现在得分后，销售总监可以直接负责每个销售人员，然后可以进行有针对性的销售培训、人员更换等。 四、产品设计过程的注意事项 管理授权方向的产品与数据产品有点相似。在产品设计过程中，与用户端产品和后台产品会有所不同。产品设计过程中的一些注意事项如下： 确定数据统计的时间维度，使用离线数据或实时数据。这是两种数据统计类型。离线数据的一般原理是通过一段数据查询指令每天定期执行，通常用于统计历史数据。实时数据通过实时任务进行，通常用于显示当天的几个核心数据，比离线数据更复杂和错误。 澄清数据的查询逻辑，有几个查询规则，是否，触发/统计时间点等。数字逻辑需要结合实际业务需求和数据统计原理来制定，有时会有许多不那么容易想到的限制。例如，跟踪客户数量的数据，完成跟进的操作是什么，同一客户是否在一段时间内多次跟进，客户是否不是他的销售或商店跟进是否是跟进，等等。一旦遗漏了几个限制，遇到问题后数据就不准确了。 确保每个平台的数据口径统一。当每个数据发生变化或添加新数据时，需要与其他平台的产品一起确认。这一点非常重要。如果同一数据的口径不统一，不同的用户看到的不是同一数据，错误的理解将对业务产生很大的影响。 五、产品上线后如何评价效果？ 如何评于报告的管理授权产品，如何评估产品上线后的效果是一个难题。该产品很难直接用数据来表达效果，因为它不会直接影响业务本身，只会间接影响业务，用户的使用方式主要是查看数据，不需要在页面上做更多的操作。 例如，我们只能统计一个商店数据报表页面的页面pvuv，没有像电子商务这样的订单转换率和活动参与者数量的数据。从业务结果的角度来看，无法判断这样的数据报表页面是否改善了商店的订单量、新客户数量和客户回访数量。从公司劳动力成本的角度来看，根据公司的决策，可以统计一个人管理商店的数据来看是否提高管理效率。 所以这一块只能通过一些间接的方法来判断上线后是否有效。我认为有几种相对可行的方法: 数据报表类别，数据只能统计到页面上PVUV，有时候访问者的数量不能说明什么，因为报告应该看的时候总要看，看不出报告数据设计是否合理。此外，可以统计bug数量判断是否稳定。数据产品主要是基础设施，注重稳定性和准确性，可以统计bug看是否准确稳定，但研发学生更关注这一点。 工具类，如日报和目标模块，可以统计用户数量/业务数量和覆盖率，以提交日报/完成目标设置为标准。这个数据可以看到用户接受和识别这个工具的比例有多大。如果用户数量少，很多人继续在微信群中提交日报，需要对这个功能本身进行复制优化。 业务分析报告类，数据只能统计pvuv，然而，该功能不一定需要查看。用户可以参考访问者的数量来确定该功能的使用和接受程度。此外，您还可以通过离线研究询问用户是否对该功能感到满意，报告中提出的业务建议是否会被采纳，以查看用户的真实反馈。 作者 潘帕斯鹰，一只进攻和踩坑的产品狗，关注互联网，写小说，读哲学。简书:潘帕斯鹰。 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。如有侵权行为，请联系网站管理员删除，。