商户增长模型（AAGRR）-供给篇

本文核心讲的是AAGRR模型里的第一个A(Acquisition，拉新)，作为一个餐饮平台，商家的供给几乎是决定了该平台最终规模以及竞争态势。
平台商户的获取途径和用户的获取途径完全不一样，用户可以靠流量、广告或者app本身的体验就可以获得大量用户。商家的话更多的是靠地面部队（销售、地推）去做拜访、签约。为何有这样的差异，商家更多的是聚集在怎么在平台上做好生意，围绕生意需要给商家普及平台准入、抽佣等一系列规则、指导平台工具使用以及其他经验性工作，这就好比开了一家公司其中的复杂性远超过在视频网站在看个视频，在交易网站上买个东西这么简单。
既然我们要做商家的拉新，那我们的商家信息怎么获取？怎么保证给到销售的信息是准确的，这两点很重要，在竞争的态势下谁先占有信息优势胜利的天平往往会往那个方向倾斜。所以我们会得出了两个重要的KPI，商户的数量以及质量。

在大部分的销售CRM里面会都会有线索的概念，餐饮行业也有这样的概念，不同的是除了客户姓名、电话，还需要有商户名、商户地址等信息。我们要构建的供给体系核心还是需要转化成销售线索给到销售。
POI概念：POI即point of interest，兴趣点，在餐饮平台的体系里面则为商户信息。

商家数量

众所周知餐饮商家的汰换率有八成，甚至有些街道三个月就跟换新的一样，我们需要做到能够及时快速的感知到线下新开了哪些店，这些店是什么品牌、类目等。
为此我们需要扩展了信息来源渠道，我们有很大的C端用户群体、销售人员以及骑手团队，在这些角色上我们做了不同的尝试，首先我们先标准化了商户信息入库的流程，基于这个核心流程上面，面向不同的群体我们给出稍不一样的信息录入页面，我们在C端的搜索无结果页、销售app以及骑手app上都投放了商户录入入口。上线后的一段时间，暴露了两个问题，1、数量少；2、信息不准确。用户几乎没有什么动力去费力的填写他遇到的商户，我们的销售人员因考核需求，填写虚假商户（数据质量问题）。
基于问题1，用户的任务激励体系是我们亟需解决的问题，为此我们做了几件事，打通营销、预算以及销售结算，在此之上自主构建了基于商户信息录入的任务、权益体系。于是我们就有了如下的系统架构。

POI核心能力

商家质量

还有一个问题需要解决，信息不准的问题，有些是为了考核需要填写虚假信息，有些是无意之举，所以我们需要一个审核机制，业务团队为此成立了外包审核团队，研发在一个月内为审核同学建设好了原始审核工作台，在数量不多的情况下还是能满足业务短期发展，随着量级越来越大，审核人员持续增加，人员及资金压力日增，此时也引入怎么给业务提效这个命题，分两个方向进行，流程上：引入先发后审机制，同时把审核规则前置保证用户在填写信息时就是准确的，这样整体上保证用户端了体验及效率；技术上引入机审流程，比如IVR(互动式语音应答)自动化的进行电话号码校验。
上述方向是对新入库的商户做质量保证，那针对存量商户怎么做呢？这更多的需要和数据及算法团队合作，比如僵尸商户的识别需要更丰富的在线交易及线下交易信息，信息补全需要融合多渠道商户信息、类目品牌等需要算法来训练识别。

信息gap

我们为很多业务提供了商户数据，业务获得商户后会有会在对应的业务上产品更多有价值的数据，比如外卖商户资质需要在开店后才会收集到，这实际上是越贴近商户的业务数据更准确，为了解决这样的信息割裂，需要建立标准的数据回流通道，实际建设中，更多的通过接入SOP来规范数据使用，使用我们提供的商户，则必须接入我们的标准变更流程，这样就做到了商户的数据在我们的体系内闭环。

商机：从业务的视角来看，对业务有价值的一类商户即为商机。

数据回流

业务转化

在建设好商家的量及质量后，还要去思考怎么把这些商家转化成各个业务的平台商户，此前都是各个业务BI拉出各自喜欢的商户通过excel直接下发到城市经理，再人工分摊到各个销售手里，这种效率可想而知。那怎么实现高效的数据分发呢？有三个核心模块需要重点提一下，一、丰富的商家标签；二、基于组织架构、业务线等分发能力；三、销售公私海池。

公私海是销售CRM里的重要概念，销售在公私海池里面捞取线索用于开展正常的业务拜访、签约等。公海是一个销售组织里的公共的池子，大家都能在公海里获取到线索，私海是单个销售的私人池子，为他独有。

于是我们构建了如下的转化链路，通过丰富的标签筛选能力，获取具有各自业务倾向性的商户，再由分发模块纷发到各业务的销售公海或者私海。

模型转化链路