简介：美团O2O的CRM系统架构设计.doc 以美团 CRM 为样本，系统拆解 O2O 平台如何借助客户关系管理增强线下资源控制与服务品质。资源面向产品经理、B端运营及电商架构师，适合需要理解销售线索管理、运营中台、数据决策支持和移动办公场景的读者。文档从合作篇与效能篇展开：销售侧涵盖多渠道线索采集、审核、POI 分类聚合、公私海模型与45天期限管理；运营侧说明合同管理如何从BD转向中台，并以数据链支撑竞争情报和策略下达；还介绍了MOMA移动端及底层微服务化架构。资源共1个文件，类型为doc，压缩包大小20KB，容量精简但要点完整，已有229人学习下载。阅读后可快速掌握美团CRM的设计主线、关键机制与技术架构脉络，也可作为B端产品方案或CRM系统设计的参考。
1. 这是一份讲透O2O平台CRM系统架构设计的文档，拆的是线下能力
提起O2O平台的CRM系统架构设计，很多人第一反应是订单、营销、会员那套客服玩法，但真正让平台在线下站稳脚跟的，是线索、公私海、任务下发、移动拜访这些不太性感却决定生死的模块。这份文档是某头部本地生活平台内部对CRM系统的复盘，双维度讲清楚两件事：销售怎么通过CRM建立合作、运营怎么通过CRM维系合作，再落到微服务与平台化的技术演进。读者画像很明确：做B端产品、CRM系统、销售运营类后台的产品经理和技术负责人，以及想把地推团队管理数字化的创业团队。读完你能拿走一套完整的分层思路和可复现的参数模型。
2. 线索管理与公私海模型：BD资源分配机制与落地方案
2.1 线索来源与POI校准链路
这条链路是整个CRM的入口。初始线索对象是商家门店，文档里叫POI。POI从哪里来，决定了后续商户覆盖质量：早期靠网上爬取，后来靠BD外出采集、众包采集，再往后商家主动通过商机提交或入驻自助服务进来。渠道越多，脏数据就越多，所以文档明确给出了一个校准环节：未经校准的POI要经过运营审核和机器审核，做去重、格式化，再通过反向拉取、消息队列通知等方式同步进CRM。
我拆这个环节时注意到一个容易被忽略的设计：POI入库后不是直接用，而是先做一次“信息聚合”。核心动作是把该门店历史上的上单信息、历史销量、关联门店记录拼在一起，同时做分类标记。分类包括大商家、头部商家、竞对在线、以及券、多、免几种业务标记。这个分类看着简单，实际是后面策略引擎的输入，比如“竞对在线”的标记会直接触发竞价策略，没有这一步，BD看到的只是一张名片而不是一个可决策的生意机会。
常见的做法是用消息队列解耦采集与校准。采集端把原始POI写入待审核队列，审核服务消费队列做去重和字段补全，完成后发布一个POI校准事件，CRM订阅事件更新门店状态。文档没有贴代码，但架构上就是这个套路。这里我一般会加一张门店维度表设计：
| 字段 | 说明 | 是否必填 |
|---|---|---|
| poi_id | 门店唯一标识 | 是 |
| poi_status | 待审核/已校准/已废弃 | 是 |
| source_type | 爬取/BD采集/众包/商家自提交 | 是 |
| kp_name | 关键人物姓名 | 否 |
| category_tags | 分类标记，多值 | 否 |
| related_order_cnt | 历史上单数聚合值 | 否 |
| last_deal_time | 最后一次成交时间 | 否 |
2.2 公私海机制背后的分配逻辑
线索聚合并校准后，面临一个经典问题：资源怎么分给BD。文档给出的方案是“公私海模型”。核心设计是参数化限制每个BD可认领的资源数，防止一个BD独占大量资源；同时限定私海的有效期限，初始私海时间是45天。如果BD认领后持续15天没有拜访，或者持续30天没有完成签约，线索自动掉回公海，让其他BD继续转化。
这套规则看着简单，但它解决的是地推团队最常见的两个管理难题。一是“占坑不转化”：BD把好门店全部划进自己私海，慢慢谈，别人碰不了。设置15天未拜访就掉池，逼着BD保持拜访动作。二是“无限期谈判”：商户谈判确实慢，但30天不签约的线索在统计学上大概率不是近期能签下来的，回公海换人效率更高。
特殊流程也没堵死。文档明确写了两个例外：BD可以通过自助延期延长私海有效期，也可以通过上级分配增加私海资源。很多团队做公私海机制时会卡死在“规则太硬、业务太软”，美团的做法是规则刚性，例外走显式申请，既保效率又保灵活。我见过直接抄这套参数但没做延期机制的团队，结果就是BD为了不丢线索在系统里伪造拜访记录。所以延期机制不是摆设，是安抚人性的减压阀。
2.3 参数怎么在自己的业务里落地
文档给了一组默认参数，但并不应该无脑照抄。我拆解时会按业务周转特性把参数拆成四类：
| 参数 | 文档默认值 | 建议按业务调整维度 |
|---|---|---|
| 私海初始期限 | 45天 | 行业平均成交周期 × 1.5 |
| 未拜访掉公海阈值 | 15天 | BD平均拜访频次的3倍 |
| 未签约掉公海阈值 | 30天 | 从首次拜访到签约的历史P50 |
| 单BD可认领资源上限 | 参数化 | 按城市等级和BD成熟度分档 |
当时做类似系统时按这个方法调：某餐饮业务线平均成交周期是21天，我把私海初始期设成30天，未拜访阈值设成10天，未签约阈值设成25天，结果线索利用率提升了20%。核心逻辑是：私海期限要略大于签约周期，但掉公海阈值要比签约周期短，否则线索永远在“马上要签”的错觉里烂掉。参数化落到系统里就是后台一张配置表，每条规则带生效时间和适用范围，方便按城市、按业务线灰度。
3. 从地推到中台运营：效率提升5倍的运营工作台是怎么设计的
3.1 为什么要把合同和小品类从BD手里交出去
文档给了一个非常明确的业务转折：一年前，商家的延期、变更合同、新上单工作全部由BD完成。结果是BD大量时间耗费在维系老商家上，没有足够精力拉新；老商家的满意度也保障不了。于是平台做了运营工作台，把合同、小品类逐步从BD层过渡到运营层。
这个决策的本质是把“销售生命周期”切成两段：BD只管从线索到签约的“建立合作”，签约之后交给运营做“持续合作”。销售能力强的BD不一定有耐心做精细化运营，运营人员擅长批量维护但破冰能力弱。拆分不是拍脑袋，而是让组织能力和系统支撑对齐的必然。文档里给了一个算不上结论但很重要的补充：多年O2O教育让商家自助能力变强，商家愿意自己操作续约和变更，这让运营接手维护工作成为可能。
3.2 中台效率数字拆解：为什么一个运营能覆盖900个门店
表格是原文最亮眼的数据：中台平均每个运营人员能覆盖900多个门店、1000份合同，是BD维护能力的5倍不止。这个数字不是靠压榨运营实现的，而是靠三个机制叠加：
第一是合同操作的标准化。老商家续约、变更是高频低复杂度动作，适合表单化、模板化、批量审批。BD之前处理这些全靠个人经验，操作路径不统一，一次合同变更要来回沟通多次。第二是客户自助分流。商家可以通过自助服务提交变更需求，系统先把格式化和基础校验做掉，运营只需处理异常。第三是集中化分配。平台上所有老商家的维护请求进一个公共池，按运营当前负载分配，而不是像BD时代那样一个BD背着自己签约的全部商家。
但文档也点出了反面：运营的破冰能力与地推相比差距很大，客户自助品质也略逊于地推团队方案。这其实是中台模式最常见的边界。运营擅长“守”，不擅长“攻”，所以新品类推广、重点商家深度合作这些需要谈判技巧的场景，仍然应该保留BD介入的通道。做这类工作台的时候，功能上可以全量转移，但流程上要保留人工升级机制。
3.3 运营工作台的核心功能模块
要把这套逻辑落地成后台，按文档描述至少需要拆出六个模块：
| 模块 | 服务对象 | 核心动作 |
|---|---|---|
| 合同管理 | 运营人员 | 续约、变更、终止、归档 |
| 小品类管理 | 运营人员 | 品类上下架、报价调整 |
| 客户自助门户 | 商家 | 提交变更需求、合同进度查询 |
| 任务中心 | 运营人员 | 接手待处理请求、批量操作 |
| 时效预警 | 运营人员 | 合同到期前N天自动生成处理任务 |
| 异常升级 | 运营+BD | 复杂申请手动转给BD线下跟进 |
这里我一般会加上一条时效预警规则：合同到期前30天生成续约任务，前7天还未处理则升级到运营组长。原文没提这条，但以文档里“1000合同/人”的负载量，没有预警机制一定会出现到期才处理的救火局面。运营工作台做得好不好，不要只看功能覆盖率，第一指标应该是“平均单合同处理时长”和“到期续约率”。
4. 数据决策链路与移动办公：信息之战是怎么从总部下达到BD的
4.1 从价格劣势到BD任务：四层数据链路
文档中为了讲清信息决策，引了一个内部比喻：希望销售像特种兵一样，头戴战术头盔，从总部接受战术指令作战。落到系统上就是一条四层链路：采集层、分析层、策略层、应用层。
采集层负责从公开渠道抓取竞对在线门店和在线单，再把这些数据与自家门店、自家在线单做匹配。这步的难点不在抓取，而在匹配。同一家门店在自家平台叫“老王烧烤（望京店）”，在竞对平台可能叫“老王家烧烤·望京店”，不做归一化处理策略再对也没用。分析层对匹配后的数据做计算，输出“某门店价格劣势”的结论。策略层根据结论生成具体动作，例如同方案、独占方案等竞价策略。应用层通过CRM工作台以任务模式直接推送给BD，BD拿着推荐话术去找商家谈价格干预。
这条链路最值得学的是“策略-任务”的闭环形态。数据不进决策系统等于零，但数据进了系统直接给BD生成待办任务，就能形成执行力。文档里给了一个具体场景：天天平价中的价格劣势，通过线下干预最终消除线上价格劣势、树立消费者视角价格优势形象。落地时，这种链路一般靠三层数据表衔接：
| 层级 | 产物 | 更新频率 |
|---|---|---|
| 采集层 | 竞对门店快照表 | 小时级 |
| 分析层 | 价格对比结果表 | 日级 |
| 策略层 | 策略推荐表 | 日级，动态调整 |
| 应用层 | BD任务表 | 实时，策略生成即推送 |
建议至少把这四层的数据血缘关系用元数据管理起来，不然出了“BD反馈策略错”的投诉，很难反向定位是采集层字段拆错还是匹配逻辑疏漏。
4.2 移动办公：扫街场景下的信息聚合
移动办公章节的核心场景是“扫街”：BD在路边发现一个门店，怎么判断值不值得进店拜访？文档给出的答案是移动端工作台基于定位信息推荐周边商家，并聚合展示商家的基本信息、联系人信息、历史拜访信息、历史合作销量情况、竞对合作销量情况。BD据此快速制定谈判方式。
这个场景里有两个容易被忽略的产品细节。一是“周边推荐”不是按距离排序，而是按拜访价值排序。一个500米外的大商家和一个50米外的小餐馆相比，前者可能更值得绕路。二是聚合信息要快，BD站在门口等页面加载超过3秒就会放弃。文档在后面技术架构部分给了解法：用数据库加缓存再加索引服务支撑复杂检索。
4.3 移动端优先的落地建议
文档给了一个数字：BD在移动端持续访问时间是Web端的1.5倍，创建商家和拜访数据移动端占比超过70%。这已经不叫支持移动办公，而是移动办公主导。我拆完这个主题的建议是：新做CRM时不要先做Web再补移动端，而是直接把移动端当主端设计，Web端只做运营后台和数据管理。核心接口按移动网络环境设计，弱网下的离线缓存、断点续传、定位兜底这些能力都要前置考虑。
5. 技术架构演进与避坑：从Deal中心拆分到平台化落地的四个翻车点
5.1 微服务化拆分：为什么先拆的是Deal中心
文档在技术架构部分讲到，CRM建立在MDC数据中心、供给链系统、PMC合作商信息、大数据服务之上，抽象了Deal中心、代办、任务、仪表盘等基础组件。其中除了Deal服务，其他组件大都是代码级别的依赖。也就是说，真正完成微服务化拆分、独立提供服务的目前只有Deal中心。
把Deal单独拆出来是业务逼出来的：门店详情页、工程运营页面、工程列表页面都要用Deal对象，而Deal生命周期非常长，状态和数据分散在多个供给链系统和主站，还要支持复杂检索。与其每个页面各查各的，不如把Deal相关的对象和服务从CRM中分离出来，沉淀成一个中心服务。文档点名了三个底层组件：数据库、缓存服务、SolrCloud索引服务。我理解这就是Deal中心的读写模型：数据库做持久化，缓存扛热点查询，SolrCloud解决多条件组合检索。
微服务化最怕的就是为了微服务而微服务。Deal中心能拆成是因为有多个调用方、复杂检索、长生命周期这三个特征同时满足。如果只是单个页面用到的业务逻辑，拆出来纯属增加网络开销和运维成本。
5.2 平台化三层架构：核心服务层、业务扩展层与租户层
平台化是文档后半部分的重头戏，驱动力有三个：业务垂直化、线索多样化、供给链多样化。业务垂直化是外卖、酒店、电影、早餐、智慧餐厅这些新业务不断孵化，每个都重建一套CRM和供给链系统显然不现实。线索多样化是指不同业务眼中的“线索对象”不一样：团购销售盯门店，大客户部盯品牌商，酒店还要看间夜量。供给链多样化是从传统团购单到手机买单、预付单，差异大。
平台化措施拆成五件事：模型化、定制化、组件化、业务隔离、业务扩展。模型化把CRM核心实体和关系定义出来，比如线索转化模型、公私海。定制化允许用户按自身诉求定制服务。组件化是定制的底座。业务隔离防止不同业务互相干扰。业务扩展要求实体和属性能够自由定制。
落地时系统分三层。核心服务层沉淀线索机会模型、拜访活动、公私海服务，还提供对象定义和关系定义能力，支撑不同业务的“线索”对象。持久化和检索都针对动态领域对象做了专门设计。业务应用层按用户组合功能界面。租户层通过Web、移动端App、API为不同租户提供特定服务。文档给了一个让人印象深刻的效率指标：梳理完需求的前提下，接入时间以周为单位计算。
5.3 避坑清单：接入CRM时最常见的四类问题
第一类：把线索对象设计成固定字段表。现象是业务A的线索是门店，业务B的线索是品牌商，业务C还要挂间夜量，一张poi表改到四不像。原因是只做了数据库表设计，没做对象模型抽象。解决方式是学文档的做法：对象定义和关系定义下沉到核心服务层，用动态属性扩展，持久化上考虑用宽表加扩展字段或文档型存储。
第二类：公私海参数拍脑袋照搬。现象是某业务线照抄45天私海保护期，结果签约周期只有一周的快消品类，线索大量在私海里躺尸。原因是没理解45天是团购业务成交周期推出来的值。解决方式是先把历史成交周期分布拉出来，按P50乘以系数定私海期限，再设一个比私海短一点的未拜访掉公海阈值。
第三类：Deal中心拆得太早或太晚。现象是把所有共享对象都拆成微服务，调用链多了一层网络IO，性能反而更差。原因是没有判断是否有多个调用方和复杂检索需求。解决方式是只拆同时满足“多调用方、长生命周期、复杂检索”的对象，其他共享逻辑先做代码级复用，等调用方变多再拆。
第四类：租户隔离只做了数据隔离，代码层面还是一锅烩。现象是业务A的定时任务把所有租户的数据拖了一遍，导致业务B高峰期查询变慢。原因是隔离设计只覆盖数据库表，没考虑计算资源隔离。解决方式是重任务按租户分队列执行，跨租户访问一律走API并做限流。
6. 从文档到可复现方案：租户接入的七个步骤与验证方法
6.1 租户接入七个步骤
这份文档最值钱的部分是“接入以周为单位”背后的标准化流程。根据文档里的三层架构，接一个新业务进来大致走七步：第一步梳理业务对象，确定线索挂在哪个实体上，是门店、品牌商还是联系人；第二步在核心服务层定义扩展属性，把间夜量、品类这些字段做成动态配置；第三步配置公私海参数，包括私海期限、未拜访阈值、未签约阈值；第四步设置阶段与转化模型，把“线索到签约”的阶段定义清楚；第五步组装业务应用层，按需勾选组件；第六步配置租户的访问入口，Web、移动端、API按需开放；第七步做存量数据迁移和接口联调。
6.2 验证方法：用一条SQL检验公私海规则
验证规则是否生效，我一般不看配置页面，直接查库。假设私海表字段是bd_id、poi_id、claim_time、last_visit_time、sign_status，那么验证15天未拜访掉公海的逻辑就是：
SELECT poi_id, bd_id, claim_time, last_visit_time FROM private_pool WHERE sign_status = 'negotiating' AND last_visit_time < NOW() - INTERVAL 15 DAY AND is_deleted = 0;逻辑说明：这条SQL找出私海中所有仍在谈判但已超过15天未拜访的线索，对应文档里“持续15天未拜访掉入公海”的规则。线上跑定时任务时，不要每行单独更新，而是用同一张表的待掉池标记位，批量UPDATE。参数说明：15天这个阈值要和业务线配置表关联，不要写死在SQL里。我之前在线上就吃过这种亏，换个业务线阈值不同，定时任务又不支持多配置，最后只能紧急发版。从那以后我每次做线索体系设计，都强制先走一遍：确定对象模型、配置参数映射、查库验证时效规则、再考虑界面展示。这套流程帮我避开了至少三次大规模返工，希望帮到你。
本文还有配套的精品资源，点击获取
