美团O2O地CRM系统架构设计

1、美团020的CRM系统架构设计众所周知，020 (Online To Offline ),是指将线下的商 务机会与互联网结合，让互联网成为线下交易的前台。但是 020平台自身并不提供用户最终享受的商品、服务，这些服务都来自线下商户提供的服务，换句话说平台只是服务的搬 运工。线上风景固然靓丽，但是并不像看到的那样风光， 就拿“团购” 来讲，美团、点评、百度糯米的 APP在功能布局、操作体验 等方面差异化越来越小，这样极大的降低了用户使用门槛， 作为理性逐利的C端用户来讲，最长见的结果谁便宜就会用 谁。那么问题来了，如何在这场纷争中抓住用户，最终胜出呢？对，线下能力！线下的能力包括线下资源的控制能

2、力和线下服务品质的控 制能力。线下能力最终决定了平台能够提供给线上用户的服 务和服务品质，只有能够提供丰富、实惠、高品质的服务，来 能够帮助平台在线上赢得用户，取得成功。美团之所以成功， 就在于强大的地面、运营团队所建立起的线下能力。而这些 团队背后所依赖的，就是我们称之为秘密武器的B端产品。CRM，就是其中之一。CRMCRM系统，立足于帮助美团解决 线下资源控制的能力。CRM通过商家关系的建立和维系客户关系，同时借助于新技术、和方法改进来提升工作效率，从而达成美团和商户的使命！接下来我会从两大维度四个方面来介绍一下美团CRM的特点:合作篇销售（建立合作）、运营（持续合作）效能篇信息之战（数据

3、）、移动办公（场景支持）销售（建立合作）众所 周知，在CRM系统中线索是非常重要的资源，提供丰富、 有价值的线索是 CRM系统的首要职责。在美团，线索对象 通常指商家门店（POI），通过对门店关键人物（KP）的拜访和机 会转化，最终为美团提供合作商家 （可上单的商家）。线索通过多种渠道获得：网上数据爬取（初期）BD（业务拓展人员）采集商家创建众包采集美团数据中心（MDC）将信息收集完成后，POI将会进入审核 环节，未经校准的 POI会经由人工（运营审核、众包采集）、 机器审核进行校准、去重工作，通过反向拉取、消息队列通 知等方式，线索数据最终会同步到CRM。基于美团的大数据服务，在CRM中的P

4、OI数据将会被标记分类（300大商家、头部商家、竞对在线、券、多、免）和信息聚合（历史上单信息、历史销量信息、关联门店记录）。随着美团的影响力逐渐扩大，更多的商家也会主动寻求和美团的 合作，目前商家可以通过商机 （提交合作信息）和入驻（自助服 务）来寻求美团合作，这些机会'信息会直接作为线索进入到 CRM的机会转化模型中来。有了丰富的线索资源之后，还需要设计一个有效的线索管理 模型来帮助线下团队完成资源的合理分配、线索到机会的快 速转化。首先，系统提供一个公私海模型，并且通过参数化限制每个BD可认领的资源数，这样可以防止一个BD独占大量资源。其次，限定了私海的有效期限，一个资源在BD私

5、海的初始期限被设置为45天，在此期间，如果BD持续15天未拜访， 或者持续30天没有完成签约，线索都会掉入到公海中。其 他BD可以继续做资源的转化。当然，如果在特殊情况下， 比如商家谈判的确很慢，恰巧私海的保护期又到了， 那么BD 还是可以通过自助延期或者上级分配的方式来延长私海有 效期。通过上述的模型， CRM对完成了对销售阶段的支持。 运营（持续合作）销售发现商家，运营维系商家；与美团合作的商家，也需要一系列的维系工作，如延期、变更合同、新 上单;这部分工作在1年前是由BD来完成的，不仅消耗了 BD 大量的时间来维系老商家而无法及时拉新，老商家的满意度 也无法保障。在这个背景下，我们建立美

6、团的运营工作台-中台;将合同、小品类逐渐从 BD层过渡到运营层面。然而， 就是这个小小的过渡，就让我们取得了惊人的成绩：在中台，平均每个运营人员能够覆盖 900多个门店，1000合同，是 BD维护能力的5倍不止。地推模式转变到运营模式是一个必然，一方面从公司的角度 上来讲，运营的效率惊人，另一方面，多年的020'教育'已经让商家越来越具备自助的能力，有更强的自主性。凡事有 利必有弊，从实际的执行结果上来看，运营的破冰能力与地 推相比还有很大差距，客户自助的品质相较之下，也略逊于 地推团队的方案。因此，运营还有更长的路要走。信息之战（数据）美团的C00阿干（干嘉伟）曾经在部沟通中

7、讲，希望 美团的销售有一天能够像美国的特种兵一样，头戴战术头盔， 从总部接受战术指令进行特种作战。而今这个期望已经成为现实，通过竞争情报、策略分析、应 用执行等多层服务系统化的数据链条，各种“决策命令”由机 器人工的方式在总部动态制定，再经CRM系统基于系统设定的处理流程下发到城市端，最后由城市进行快速的跟进辅 助其做出正确处理。在处理过程中，城市端也可以通过任务 系统及时的反馈问题至总部以获取更多的决策信息来辅助 其做出正确处理。对于城市无法及时处理的“决策命令”，总 部项目运营团队甚至可以直接进行干预，例如直接调整在线 项目的价格。拿天天平价中的'价格劣势'来讲，通过基础层

8、采集竞对的在线 门店和在线单并与美团的门店和在线Deal进行匹配，通过分析层对数据进行进一步的分析，会输出一系列的策略（同方案、独占方案等竞价则略），这些策略会通过应用层 CRM的工作 台以任务模式直接推送到 BD，BD则可以根据推荐的策略与 商家沟通，进行价格干预，最终帮助美团消除线上价格劣势、 树立消费者视角价格优势形象。移动办公（场景支持）移动 办公在BD层面是是一个场景性的问题，试想一下一个BD在'扫街'过程中，发现路边有一个门店，他如何去进行有效的 拜访呢？早在2013年，美团就推出了团购行业的第一个客户关系管理客户端 MOMA（Mobile Meituan APP）

9、 。BD在扫街过程中， 基于定位信息，MOMA可以快速推荐出 BD所在位置的周边 商家。对于指定的商家，MOMA提供的详细页面汇聚了商家 的基本信息、联系人信息、历史拜访信息、历史合作销量情 况、竞对合作销量情况，通过这些信息，BD可以快速判断并制定谈判的方式，促成合作的达成。MOMA端还集成了待办事项中心、活动页面，这些功能能够帮助BD快速获取任务，便于销售人员进行客户关系管理， 提升工作效率。到现在，美团BD在MOMA上的持续访问时间已经是在 Web 上访问时间的1.5倍;从创建商家、用户拜访数据上看，MOMA 的占比已经超过 70%。技术架构CRM系统，建立在底层服务的支撑MDC（美团数

10、据中心）、供应链（合同、上单）、PMC（合作商信息）、大数据服务之上， 同时抽象了一部分基础组件服务：Deal中心、代办、任务、仪表盘（遗憾的是，除了 Deal服务，其他的基础组件大都是 代码层级的依赖，这也是我们下面要做平台化的原因之一）在应用层，根据业务的特点，又狭义的定义了面向销售的CRM系统和面向运营的中台系统，在这篇文章里，我们统称它们为CRM系统。美团的CRM是随着业务发展逐渐演化而 来的，架构也在不停的优化之中。微服务化就是我们在架构 改进中的策略之一，例如Deal中心就是这个过程的一个产物。 在需求开发过程中，我们发现在门店详情页、 项目运营页面、 项目列表页面都需要使用到“

11、Deal ”对象，而eal对象由于生 命周期非常长，很多状态或数据分别存在于多个供应链系统、 主站，并且在系统功能层面上提供复杂的检索支持。基于数 据库、CCache服务（美团Medis）、索引服务（SoIrCloud）等技 术，我们将Deal涉及到对象、服务从 CRM中分离并沉淀为 一个Deal中心服务。通过分解巨大单体式应用为多个服务方 法解决了复杂性问题，这就是微服务化所带来的收益。平台 化 美团正处于高速发展期，高速发展所来带的业务发展和变化给系统建设带来了巨大的挑战：业务垂直化在公司的T型战略指引下，美团的垂直业务不断在孵化中，目前的垂直业务 诸如酒店、外卖、猫眼、早餐、智能餐厅等等

12、，都给系统支 撑带来了很多挑战。如果没有平台化的系统支持，那么每个 业务都要完整地重建一套 CRM、供应链系统，这不仅仅浪费 人力成本，系统建设效率往往也很难与业务发展匹配，严重 制约着业务发展。线索多样化在业务层面，与客户相关的角 色不断被细化与重组，与美团合作的对象也有不同。从定义 上讲，线索对象是一名片，或者是联系人。但实际情况这个 联系人需要附着在一个业务实体上，例如团购在销售眼中的 销售对象是门店（POI）、大客户部关注的线索对象则是品牌商。 即便是门店对象，酒店、餐饮关注的信息也不完全一致，例 如酒店关注的门店信息要包含间夜量信息，在做这类信息的 聚合上也需要兼顾不同的数据源供应链

13、多样化供应链系统 在不同的业务群里差异较大， 从传统的团购单、到手机买单、 预付单。作为“门户”，CRM也需要建立不同的标准，对接多 样化的业务系统。平台化做什么？模型化在模型化层面上，是要将CRM业务领域的核心实体以及核心实体的关系定义出来，将业务模型从复杂的业务需 求中剥离出来；同时需要在抽取的基础上考虑到业务自身所 具有的可扩展性。通常这个模型就是CRM的线索转化、公 私海。定制化用户可以基于自身诉求， 对所需服务进行定制。 组件化不同的业务，对服务的要求也是不一样的，因此对于 功能来讲，应该可以组件化定制。组件化是定制化服务的基 础。业务隔离承载不同的业务，诸如团购、酒店、早餐、智能餐

14、 厅等，需要对不同的业务进行隔离，避免相互干扰。业务扩展业务是发展的，因此要具备对业务进行扩展的能力， 这一个对技术的要求更高。不同的业务，对实体的要不一样 的，实体乃至实体的属性应该能够自由定制。在建设过程中，我们将系统分成三层：核心服务层、业务扩展层（应用层）、租户层；核心服务层主要沉淀 CRM的线索机会模型、拜访活动、公 私海服务；同时为了支持不同的业务“线索”对象，核心服务层 还将对象定义、关系定义服务纳入进来。由于在这一层需要 提供动态的领域对象服务，因此在持久化、检索服务上，都 分别做了设计来支持对象的扩展能力。业务应用层主要是对租户业务进行支持，在这个层面上，用 户所需的功能被组件化，基于核心服务层定义出的对象和服 务，业务应用层能够根据不同的用户组合不同的功能界面。租户层，通过 Web、MOMA（移动app）甚至是API为不同的 租户提供特有的服务。 今天，CRM服务的业务方只需要在系 统中