美团O2O的CRM系统架构设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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