美团O2O的CRM系统架构设计

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

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

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

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

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

6、D 大量的时间来维系老商家而无法及时拉新，老商家的满意度也无法保障。在这个背景下，我们建立美团的运营工作台- 中台 ;将合同、小品类逐渐从 BD 层过渡到运营层面。然而，就是这个小小的过渡， 就让我们取得了惊人的成绩 :在中台，平均每个运营人员能够覆盖 900 多个门店，1000 合同，是 BD 维护能力的 5 倍不止。地推模式转变到运营模式是一个必然，一方面从公司的角度上来讲，运营的效率惊人，另一方面，多年的O2O 教育 已经让商家越来越具备自助的能力，有更强的自主性。凡事有利必有弊，从实际的执行结果上来看，运营的破冰能力与地推相比还有很大差距，客户自助的品质相较之下，也略逊于地推团队的方案

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

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

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

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

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

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

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

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