美团O2O的CRM系统架构设计

美团 O2O 的 CRM 系统架构设计 众所周知，O2O（Online To Offline） ，是指将线下的商 务机会与互联网结合，让互联网成为线下交易的前台。但是 O2O 平台自身并不提供用户最终享受的商品、服务，这些服 务都来自线下商户提供的服务，换句话说平台只是服务的搬 运工。 线上风景固然靓丽， 但是并不像看到的那样风光， 就拿“团购” 来讲，美团、点评、百度糯米的APP 在功能布局、操作体验 等方面差异化越来越小，这样极大的降低了用户使用门槛， 作为理性逐利的 C 端用户来讲，最长见的结果谁便宜就会用 谁。那么问题来了，如何在这场纷争中抓住用户，最终胜出 呢? 对，线下能力! 线下的能力包括线下资源的控制能力和线下服务品质的控 制能力。线下能力最终决定了平台能够提供给线上用户的服 务和服务品质,只有能够提供丰富、实惠、高品质的服务，来 能够帮助平台在线上赢得用户， 取得成功。 美团之所以成功， 就在于强大的地面、运营团队所建立起的线下能力。而这些 团队背后所依赖的，就是我们称之为秘密武器的 B 端产品。 CRM，就是其中之一。CRMCRM 系统，立足于帮助美团解决 线下资源控制的能力。 CRM 通过商家关系的建立和维系客户 关系，同时借助于新技术、和方法改进来提升工作效率，从 而达成链接美团和商户的使命! 接下来我会从两大维度四个方面来介绍一下美团 CRM 的特 点:合作篇 销售(建立合作)、运营(持续合作) 效能篇 信息之战(数据)、移动办公(场景支持)销售（建立合作）众所 周知，在 CRM 系统中线索是非常重要的资源，提供丰富、 有价值的线索是 CRM 系统的首要职责。在美团，线索对象 通常指商家门店(POI)，通过对门店关键人物(KP)的拜访和机 会转化，最终为美团提供合作商家(可上单的商家)。 线索通过多种渠道获得： 网上数据爬取 (初期) BD(业务拓展人员)采集 商家创建 众包采集 美团数据中心(MDC)将信息收集完成后，POI 将会进入审核 环节，未经校准的 POI 会经由人工(运营审核、众包采集)、 机器审核进行校准、去重工作，通过反向拉取、消息队列通 知等方式，线索数据最终会同步到 CRM。 基于美团的大数据服务，在 CRM 中的 POI 数据将会被标记 分类(300 大商家、头部商家、竞对在线、券、多、免 )和信息 聚合(历史上单信息、历史销量信息、关联门店记录)。随着 美团的影响力逐渐扩大，更多的商家也会主动寻求和美团的 合作，目前商家可以通过商机(提交合作信息)和入驻(自助服 务)来寻求美团合作，这些 机会 信息会直接作为线索进入到 CRM 的机会转化模型中来。 有了丰富的线索资源之后，还需要设计一个有效的线索管理 模型来帮助线下团队完成资源的合理分配、线索到机会的快 速转化。 首先，系统提供一个公私海模型，并且通过参数化限制每个 BD 可认领的资源数，这样可以防止一个 BD 独占大量资源。 其次，限定了私海的有效期限，一个资源在 BD 私海的初始 期限被设置为 45 天，在此期间，如果 BD 持续 15 天未拜访， 或者持续 30 天没有完成签约，线索都会掉入到公海中。其 他 BD 可以继续做资源的转化。当然，如果在特殊情况下， 比如商家谈判的确很慢， 恰巧私海的保护期又到了， 那么 BD 还是可以通过自助延期或者上级分配的方式来延长私海有 效期。通过上述的模型，CRM 对完成了对销售阶段的支持。 运营（持续合作）销售发现商家，运营维系商家 ;与美团合作 的商家，也需要一系列的维系工作，如延期、变更合同、新 上单;这部分工作在 1 年前是由 BD 来完成的， 不仅消耗了 BD 大量的时间来维系老商家而无法及时拉新，老商家的满意度 也无法保障。在这个背景下，我们建立美团的运营工作台- 中台;将合同、小品类逐渐从 BD 层过渡到运营层面。然而， 就是这个小小的过渡，就让我们取得了惊人的成绩:在中台， 平均每个运营人员能够覆盖 900 多个门店，1000 合同，是 BD 维护能力的 5 倍不止。 地推模式转变到运营模式是一个必然，一方面从公司的角度 上来讲，运营的效率惊人，另一方面，多年的 O2O 教育 已 经让商家越来越具备自助的能力，有更强的自主性。凡事有 利必有弊，从实际的执行结果上来看，运营的破冰能力与地 推相比还有很大差距，客户自助的品质相较之下，也略逊于 地推团队的方案。因此，运营还有更长的路要走。信息之战 （数据）美团的 COO 阿干(干嘉伟)曾经在内部沟通中讲，希 望美团的销售有一天能够像美国的特种兵一样，头戴战术头 盔，从总部接受战术指令进行特种作战。 而今这个期望已经成为现实，通过竞争情报、策略分析、应 用执行等多层服务系统化的数据链条，各种“决策命令”由机 器 人工的方式在总部动态制定，再经CRM 系统基于系统设 定的处理流程下发到城市端，最后由城市进行快速的跟进辅 助其做出正确处理。在处理过程中，城市端也可以通过任务 系统及时的反馈问题至总部以获取更多的决策信息来辅助 其做出正确处理。对于城市无法及时处理的“决策命令”，总 部项目运营团队甚至可以直接进行干预，例如直接调整在线 项目的价格。 拿天天平价中的 价格劣势 来讲， 通过基础层采集竞对的在线 门店和在线单并与美团的门店和在线 Deal 进行匹配， 通过分 析层对数据进行进一步的分析，会输出一系列的策略(同方 案、独占方案等竞价则略)，这些策略会通过应用层 CRM 的 工作台以任务模式直接推送到 BD，BD 则可以根据推荐的策 略与商家沟通，进行价格干预，最终帮助美团消除线上价格 劣势、树立消费者视角价格优势形象。移动办公（场景支持） 移动办公在 BD 层面是是一个场景性的问题，试想一下一个 BD 在 扫街 过程中，发现路边有一个门店，他如何去进行有 效的拜访呢? 早在 2013 年，美团就推出了团购行业的第一个客户关系管 理客户端 MOMA(Mobile Meituan APP)。BD 在扫街过程中， 基于定位信息，MOMA 可以快速推荐出 BD 所在位置的周边 商家。 对于指定的商家，MOMA 提供的详细页面汇聚了商家 的基本信息、联系人信息、历史拜访信息、历史合作销量情 况、竞对合作销量情况，通过这些信息，BD 可以快速判断 并制定谈判的方式，促成合作的达成。 MOMA 端还集成了待办事项中心、活动页面，这些功能能够 帮助 BD 快速获取任务，便于销售人员进行客户关系管理， 提升工作效率。 到现在， 美团 BD 在 MOMA 上的持续访问时间已经是在 Web 上访问时间的1.5倍;从创建商家、 用户拜访数据上看， MOMA 的占比已经超过 70%。 技术架构 CRM 系统，建立在底层服务的支撑 MDC(美团数据中心)、 供应链(合同、上单)、PMC(合作商信息)、大数据服务之上， 同时抽象了一部分基础组件服务：Deal 中心、代办、任务、 仪表盘(遗憾的是，除了 Deal 服务，其他的基础组件大都是 代码层级的依赖，这也是我们下面要做平台化的原因之一)。 在应用层，根据业务的特点，又狭义的定义了面向销售的 CRM 系统和面向运营的中台系统，在这篇文章里，我们统称 它们为