1.总体思路及关键决策
图1：总体思路
借鉴秦始皇统一六国时的治理思路“车同轨、书同文”，因此平台建设之初要优先统一规范，识别全局关键问题，并统筹管理。
关键决策一：定义系统边界
平台之间存在边界问题需要解决，由于过往不同业务间对职能的边界定义存在差异，在新的平台化方向，首先定义了边界划分标准：
1）是否有利于沉淀平台的核心领域能力，一个能力一个地方建设。
2）是否有利于降低成本（人员数量，沟通成本，机器成本）。
3）是否有利于提升长线业务迭代效率（端到端研发迭代效率）。
4）是否有利于组织协同及团队管理、人员培养。
5）是否有利于业务间协同和创新。
6）是否有利于提升资金安全（仅泛交易）。
各平台按照上述标准先各自梳理涉及的功能模块以及上下游关联平台，然后平台间相互对齐，划清边界和职责。对于无法一次划分清楚的通过架构组委员会讨论决策。系统边界的划分对于整个系统架构演进方向及团队协作效率都会有深远的影响。
关键决策二：统一概念及建设标准
各业务独立发展的时候，不同的系统在各自业务里有自己的概念和术语。平台化后，同一领域模块合并为一个系统，各自业务里带来的概念、术语层次不齐，理解不一致，会导致系统设计层面及团队协作层面的各种问题。
首先，定义统一的业务认知和对应概念：
1）业务（业务线）：主观，业务活动开展实体，美团内部组织划分，有对应的KPI、责任，如到餐，到综，住宿度假。
2）品类（行业）：客观，如餐饮，酒店，门票，温泉等，代表一个客观的行业。
3）业务与品类之间是N:N的关系，不同业务可以开展统一品类的经营活动，例如到综有丽人、休娱等多个品类，到餐，住宿都有餐饮品类。
4）商家应该感知到品类，跟美团合作，然后卖餐、卖票、卖酒店，不应该过多的感知到业务线，比如商家是在跟美团的到餐事业部、到综事业部合作。
图2：概念分层示意
其次，同领域不同业务的术语需要统一，比如合同、产品、资源、订单、优惠、计费、战区、权益等。详见附录一。
再次，建立统一的实施规范，如：统一平台接口规范，包括http规范和RPC规范，定义平台公共字段、类型及含义；统一平台数据库规范，包括建表规范和公共字段。统一平台命名规范以及一些代码层面的如commit log规范。
关键决策三：明确业务组织方式
- 目标：
1）业务串联：同一个业务在全平台的逻辑用统一的方式进行串联。
2）业务隔离：业务之间逻辑隔离，独立迭代。
3）能力复用：业务之间复用模型、流程、逻辑。
4）业务互通：业务之间可高效协同，促进横向产品落地。
- 方案：
1）业务身份标识：一个业务身份标识，对应一个身份识别规则，对应一套业务逻辑+业务配置，各平台根据业务身份标识，组织差异化的业务逻辑/业务配置。
图表3：业务身份的定义
| 业务识别规则 | 业务身份标识 |
|---|---|
| 品类=餐&模式=团购 | 0001(到餐团购) |
| 品类=KTV&模式=预订 | 0002(KTV预订) |
| 品类=酒店&模式=预订 | 0003(住宿预订) |
| 品类=酒店&模式=预订&卖家=海外 | 0004(海外住宿预订) |
图4：业务身份的示例
2）全平台根据业务标识进行业务串联，并且业务间通过业务标识实现逻辑隔离。
3）平台提供通用能力，业务通过继承、扩展、配置的方式实现复用+定制。
4）业务主要通过三个层面进行复用：
- 基础能力复用：在系统视角，以单个系统所提供的能力为基础进行复用、扩展，例如下单，支付，退款，库存扣减。
- 业务能力复用：在业务视角，以跨系统商业能力为基础进行复用，例如预订交易(跨下单、退款、结算、营销、商品、接单)等。
- 工具产品复用（面向横向业务、新业务）：为不同业务提供统一的解决方案，例如打包、购物车、秒杀等，其逻辑可以与具体品类解耦。
5）业务逻辑落地方式
a）平台提供统一的抽象流程，例如通用团购流程，退款流程。
b）业务方对平台抽象流程进行配置、继承、扩展，实现具体的垂直业务逻辑，例如团购退款，预订退款。
c）子业务可以在父业务的基础上进行配置、继承、扩展，实现子业务定制化逻辑，例如剧本杀预订继承自到综预订。
d）对于一些与具体品类关联不大的业务逻辑，例如拼团、秒杀、搭售等，可以以横向业务的形式，与垂直业务进行组合，实现业务逻辑扩展。例如：在团购的基础上组合拼团，在预订的基础上组合搭售。
图表5：业务逻辑落地方式
垂直业务 vs 横向业务（工具产品）：垂直业务和横向业务之间没有绝对的界限，本质上就是复用方式/层级的差别。我们既可以把拼团这 种逻辑直接打散的到垂直业务中，形成到餐团购，到餐拼团，但这样的两个业务之间复用层级就会比较低；也可以试图把预订，团购抽到横向业务中，但这个横向业务与品类相关度较大，很难干净的剥离出来。所以跟品类相关程度较大的逻辑比较适合放在垂直业务中，可以与品类解耦，相对标准化的逻辑适合放在横向业务中，各个垂直业务可即插即用。
图6：垂直业务 vs 横向业务(工具产品)
| 垂直业务 | 横向业务(工具产品) | |
|---|---|---|
| 业务逻辑 | 具体逻辑与品类相关程度较大，例如：不同品类的预订逻辑是差异较大的，所以到综预订和酒店预订就是两个垂直业务 | 具体逻辑与品类基本无关，例如拼团，秒杀，搭售等，只更改售卖逻辑，所以拼团，秒杀就可以作为横向业务 |
| 商品归属 | 不同的垂直业务间商品隔离 | 垂直业务和横向业务间商品互通，例如同一个商品可以同时/先后参加团购和拼团 |
| 复用方式 | 通过继承扩展，业务继承自平台框架流程，子业务继承自付业务 | 通过组合扩展，多种垂直业务可以组合同一种横向业务，一种垂直业务也可以组合多种横向业务 |
| 复用层级 | 基础能力，流程框架层面复用 | 业务流程层面复用 |
| 其他 | 垂直业务流程比较像一个Default的流程 | 横向业务流程比较像是Optional的，需要叠加在Default流程之上，实现业务逻辑扩展 |
关键决策四：明确北上部署方式
- 交易、结算、供应链、商品、营销：双写双读，按业务路由，到餐、住宿度假路由到北京，到综路由到上海，两边数据做同步。
2. 商品、营销平台：一部分单写（商品录入，活动创建），一部分双写（库存扣减，活动扣减）。
-
客户、门店（未启动）：单写北京侧，北上双读。
-
CRM、商家平台：在北京侧单写单读。
图7：北上部署方式
关键决策五：明确业务需求的协作方案
-
平台建设初期我们主要是1.0大闭环的协作方式，后期会逐步向2.0小闭环过渡。
-
2.0小闭环的核心是平台、业务分离。平台开放能力，业务自行定制。平台通过标准化能力建模，能力抽象，能力可视化等方式，降低业务自行定制的难度。业务定制的方式可以从系统能力SDK逐步过渡到跨平台能力SDK。
图8：业务需求的协作方案示意
关键决策6：明确迁移整体思路
- 迁移的核心原则
1）老系统可回滚：老系统全程保留100%双写流量，保证老服务的数据是全量+最新的，确保全链路可回滚至红色链路。
2）底层系统解耦：营销/结算/客户/权限，新API向下兼容(新API->老服务)，保证新老API都可以读到全量+最新数据，对外屏蔽内部系统/数据迁移，与其他系统解耦。
3）交易链路协同切换：供应链+商品+交易作为整体进行切换，商品新API不做向下兼容(新API->老服务)，商品将数据逐步同步至新服务(老服务->新服务)，整体按照客户ID维度切换至新链路，出问题整体回滚。回滚方案可根据实际情况调整：例如交易故障可只回滚交易，供应链故障可只回滚供应链+交易，商品故障全部回滚。
- 迁移阶段划分
1）双写验证阶段：①各平台内部通过双写进行验证，对外响应以老系统为准，新系统只作为验证；②全链路新系统串联验证，对外响应以老系统为准，新系统只作为验证。
2）双写灰度阶段：小流量切换至新系统(如图中1%)，该部分对应的响应以新系统为准，老系统保留100%流量，作为backup。
- 迁移依赖分析
1）供应链+商品+交易作为整体，营销/结算/客户/权限各自独立，整体作为5个分组。
2）供应链+商品+交易的切换依赖营销/结算/客户/权限新API能读取到对应客户分组的数据。
图9：迁移示意
关键决策7： 明确一体化方案
1.概念：
1）业务：对应一个业务组织，有自己的KPI，产品运营，例如餐BU，综BU，住宿BU，度假BU，丽人SBU等。
2）业务流程：一个业务对应的代码逻辑，例如餐的上单流程，餐的下单流程。
3）业务和业务流程不一定强绑定，例如住宿BD发布的餐商品，在住宿频道卖，但走的供应链/交易流程还是餐。
2.方案：
1）客户一体化：客户以同一套身份与多个业务合作[标识唯一，数据复用]。
2）商家一体化：商家以同一套账号、权限与多个业务合作。
3）门店一体化：不同业务共用同一个物理门店[身份唯一，数据复用]。
4）供给/售卖一体化：不同业务的BD可以交叉上单，不同业务可以交叉售卖，例如住宿的BD可以上餐，住宿频道可以卖餐。
图10：供给/售卖一体化
6）商品一体化(存疑)：A业务流程上的单，B业务流程可以卖；到餐、点餐共享菜品数据；现付、预付共享商品信息、库存[商品数据跨业务复用还是互通？]。
7）营销一体化：跨业务营销。
8）结算一体化：跨业务结算分账。
9）CRM一体化：跨业务商家合。
2.平台整体架构
图11：平台整体架构图
- 基础平台层：以系统视角，提供系统能力，比如交易提供下单能力，供应链提供商品录入功能。可以再分两层：
1）交易营销平台包括供应链、商品、交易、营销、结算等5个平台，主要面向佣金类等泛交易系统。
2）客户、商家、门店、CRM等平台除了支持泛交易系统之外，还需支持推广类、增值类等其他所有到店服务场景。
-
跨平台能力层：以业务视角，将分散在各个子平台的系统能力进行整理、归纳、抽象，整合成符合业务语言的跨平台能力，构建业务平台的能力地图，让业务平台提供的能力对业务可视。跨平台能力抽象是个过程，不求一次到位，可以逐步从系统能力过渡到跨平台能力。
-
解决方案层：以两种方式对业务提供能力的具体解决方案。
-
产品运营平台：相对标准、通用的能力就以平台的方式直接提供给业务线的产品运营，比如营销平台。
-
二次开发平台：相对灵活，需要定制的部分就以SDK的方式提供给业务线的研发，进行二次开发扩展。
3.建设策略及演进路径
1.本次平台化整合需要在同一个时间段内完成，但平台间存在多层依赖关系，所以将按照依赖关系自底向上建设对接：
1）最底层依赖是商品和客户平台。这两个平台不依赖别的平台，但被其他平台所依赖。
2）中间层依赖是供应链、商家、CRM、营销和结算平台，这五个平台主要依赖商品和客户平台。
3）最上层是交易平台。其建设依赖营销、结算和商品平台等多个外部平台，而不被其它平台依赖。
图12：平台依赖关系
- 平台整体演进方式（见图13），每个平台均从状态A开始，沿着不同路径演进到E：
- A：现状，完全按业务独立的几套系统。
- B：页面/入口/流程按业务独立，底层复用基础系统能力。
- C：页面/入口/流程平台统一，不同业务定制扩展，底层复用基础系统能力。
- D：页面/入口/流程/系统平台统一。
- E：全平台流程打通，业务基于商业能力进行扩展，底层复用基础系统能力。
图13：平台整体演进方式
- 各平台可以根据自己的实际情况选择合理的演进路径(见图14)，总体可以分为三个阶段演进：
1）第一阶段：
- A→B，大部分系统比如客户、供应链、商家、CRM、营销、结算等平台，因为不同业务的页面/交互/流程差异较大，短期难以抽象统一，完成底层系统能力整合。
- A→C，小部分试验田比如交易流程（交易+商品），因为页面/交互比较轻，会直接尝试统一流程，在平台管控下扩展，进行业务抽象和框架设计朝C演进。
2）第二阶段：
- B→C，比如供应链，对交互/流程进行抽象复用，支持业务定制扩展
- B→D，客户、商家、CRM、营销、结算等平台，从系统能力整合到流程整合，达到D
3）第三阶段：
- C,D→E，基于抽象建设的面向业务的跨平台能力，所有平台统一对外进行能力开放和扩展，业务全流程视角统一。
图14：各平台演进路径
| 平台 | 演进路径（始于A，到达E） |
|---|---|
| 商品 | A->C->E |
| 客户 | A->B->D->E |
| 供应链 | A->B->C->E |
| 商家 | A->B->D->E |
| CRM | A->B->D->E |
| 营销 | A->B->D->E |
| 结算 | A->B->D->E |
| 交易 | A->C->E |
4.附录
附录1：平台统一定义的术语
| 领域/维护方 | 名词 | 英文 | 解释 | 示例 |
|---|---|---|---|---|
| 全领域 | 业务线 | |||
| 产品 | Product | 美团点评对商家提供的可以达成合作，对商家或对消费者有一定价值的物体或无形的载体 | ||
| 业务 | biz | 集团内部成立的独立业务团队，负责研发某类具有相同特性的产品 | ||
| 租户 | Tenant | 到综、到餐、住宿、度假每个业务线接入平台时都要带上一个标记来区分是哪个业务线，这个目前我们称之为租户，主要用于做数据上的隔离（该点暂时存疑，是否需要做租户的数据隔离，是否做到店跟外部的数据隔离） | ||
| 门店id | poiIdshopId | 目前有两个维度的门店id，poiId是美团这边的门店id，shopId为点评的门店id，建议以后还是维持这个现状处理 | ||
| 商家自促 | MerchantSelfPromotion | 商家自主设置促销 | ||
| 商家报名 | MerchantApply | 商家主动在美团报名参加各类营销活动 | ||
| 客户 | 资质 | Qualification | 与美团点评合作的客户所提供的相关证明文件 | 例如：身份证、营业执照等 |
| 业务客户 | 客户在与美团点评的交易中所承担的角色 | 例如：到餐客户、到综客户、住宿客户、旅游客户、C端用户等 | ||
| 通行证 | Passport | 客户在使用服务提供商的产品时的登录账号，主要维护用户的登录信息和登录验证 | 例如：Epassport账号、点评账号、C端用户账号等 | |
| 签约人 | SignPerson | 代表客户进行电子合同签约的法律主体 | 例如：个人客户本人、企业客户法人、代理人等 | |
| 供应链 | 产品分类 | ProductCategory | 对于产品所属行业的定义，区别与分类 | 美食->火锅->重庆火锅、休娱->足疗、度假->门票、酒店 |
| 产品 | Product | 与用户进行交易的实体，承载了交易的内容（商品、服务、契约等） | 双人下午茶（美食）、泰式SPA30分钟（休娱）、颐和园门票（度假）、房型价（酒店）？ | |
| 方案 | 客户域的概念，面向产品管理的功能权利与约束，逻辑产品与之有关联关系 | |||
| 合同 | 客户域的概念，线下签约的合作实体，上单流程中会与之有依赖 | |||
| 交易 | 买方 | Buyer | 指在交易过程中提供资金的一方 | 美团会员、美团商家 |
| 卖方 | Vendor | 指在交易过程中提供货物或者服务的一方 | 美团商家（团购券）、美团（saas服务） | |
| 订单 | Order | 买方向卖方发出的订货凭据，在订单确认时会固化商品、服务、佣金等快照信息 | ||
| 结算 | 结算指令 | SettlementCommand | 交易平台和结算平台的对接协议，交易在发生支付、退款、消费等动作时往往需要和商家进行结算，在这些动作发生时交易要发送结算指令到结算平台，支付动作对应支付指令，消费动作对应消费指令以此类推。 | 支付指令、预定成功指令、未消费退款指令、消费指令、已消费退款指令 |
| 结算信息 | SettlementInfo | 结算账户的生成规则，对账单的生成规则，付款的周期等用于结算处理的规则或信息统称结算信息。一般在商户入驻或供应链上单环境明确，也有部分由结算运营维护。 | ||
| 结算流水 | SettlementTrace | 每一笔结算指令都会转为至少一笔结算流水，结算流水描述了一笔结算指令分账后的结果，结算流水能描述清楚商家所得，美团所得，优惠成本等信息 | 支付流水、预定成功流水、未消费退款流水、消费流水、已消费退流水 | |
| 计费 | Clear | 基于结算指令做分账，算清楚一笔消费美团应得多少，商家应得多少的过程叫做计费，计费结束后生成结算流水 | ||
| 对账单 | Statement | 周期内会计主体同其他单位或个人之间发生的的债权、债务明细 | 周期可为周、月等 | |
| 结算账户 | Account | 结算账户是用以核算和监督本会计主体同其他单位或个人之间发生的债权、债务结算情况的账户。 | 到综结算账户的定义为客户+POI+业务类型（团购、预定、闪惠） | |
| 财务报账 | Deliver | 负责将业务数据转换为财务报表所需的标准格式 | ||
| 营销 | 规则 | Rule | 一类通用判断的抽象 | 50<= 价格 < 80; 用户规则（新老客）、商户规则（POI）、商品规则（Deal）、LBS规则（定位过滤） |
| 行为 | Action | 活动执行完毕后的最终动作 | 公共Action：发券、发短信、发Push、发微信消息、投放素材 业务域内Action：订单优惠、券优惠 | |
| 事件 | Event | 用户或系统的一个触发时机 | 收集用户事件（浏览、收藏等），计算时间窗口（N分钟内），下发事件 | |
| 智能感知 | Trigger | 负责平台针对用户和商户的主动触达系统 | 感知用户事件并根据不同的规则触达用户，触达行为包含：Push发送、券发送、短信发送、资源投放等 | |
| 订单优惠 | Discount | 指订单流程中的优惠行为 | 立减、满减、折扣、一口价、返现、返券 | |
| 营销方法 | Activity | 各类活动的统称 | 一类运营方法的称呼：如落地页称大促活动；立减活动等 | |
| 物料 | Materiel | 投放的最小单元 | 可以是 图片、语音、文本、数据等内容 | |
| 成本 | Cost | 一次运营活动需要的资金 | 营销成本，各类和预算相关的逻辑 | |
| 成本归属 | ProductType | 预算成本承担方 | 酒店预付、点评预付、门票、跟团、酒景等 | |
| 库存 | Stock | 活动在各维度的数量限制 | 各类活动数量限制相关的逻辑 | |
| 招商 | MerchantEnroll | 大促、常规活动面向商户的拉供给的渠道，通过运营发布招商规则，商户可以选择合适的物料参与活动 | 运营发布大促活动的入选条件 ，商户进入后台查看可报名的活动，并报名参与 ，经过机器审核／运营审核后，物料可进入报名池，报名池与大促活动数据源打通，招商数据变更会准实时同步到大促活动中 | |
| 优惠券 | Coupon | 美团主动发送给用户的优惠券，用于支付时减免支付金额。 | 酒旅红包、mis券、opt券、到餐券 | |
| 核销 | consume | 各类消耗美团营销资金的成本扣减 | 优惠和券的成本及库存的扣减 | |
| 退回 | rollback | 各类退回美团营销资金的成本返还 | 优惠和券的成本及库存的返还 | |
| 策略中心 | StrategyCenter | 基于机器学习算法的智能化营销策略 | 特征收集、模型训练（特征集+训练算法）、模型预测、分流分层、预测服务 | |
| 价格竞争力 | PriceCompetitiveness | 保证美团的价格策略优于竞对，营造美团全网最低价 | 感知竞对侧的商品价格，通过营销手段调整美团侧的最终售价以达到追平 or Beat竞对价格的目的，营造全网最低价的现象。 | |
| 商家自促 | MerchantSelfPromotion | 商家自主设置促销 | 商家承担成本的订单优惠活动。 | |
| 商家优惠券 | MerchantGiftcard | 商家自出设置优惠券 | 商家承担营销成本的券。 | |
| 商家报名 | MerchantApply | 商家主动在美团报名参加各类营销活动 | 通过招商信息吸引商家报名参与各类活动。如订单优惠、券、大促玩法等 | |
| 预算 | Budget | 各类活动预算的统称，和营销费用相关。 | 集团龙门服务 | |
| 优惠码 | CouponCode | 平台或商家发放给用户的一种不记名的优惠兑换凭证，用户兑换后可获得一张优惠券 | 广告平台的推广券码、猫眼的通兑码 | |
| 平台促销 | platform | 公司承担成本的订单优惠 | 公司承担成本的订单优惠 | |
| 商家 | 商家 | merchant | 服务或者商品的提供者，等于客户平台中的客户概念中的(商家、代理商) | |
| 账号 | Account | 商家登录各个后台系统的凭证，有epassport提供服务 | ||
| 主账号 | AdminAccount | 在账号基础上形成的业务概念： 主账号拥有最大权限，可以查看所有业务、创建普通账号、给普通账号授权等。 一个客户只能有一个管理员账号，新开通业务或者功能之后，管理员默认具有相关的权限。 | ||
| 子账号 | Account | 在账号基础上形成的业务概念： 拥有部分权限的商家账号，通常由主账号创建。普通账号创建之后，如果客户再开通新业务，默认没有新业务的权限 | ||
| 角色 | Role | 一组功能权限的组合并给与一定的身份标识 | 比如财务管理，能查看财务报表、能操作提款、能修改银行卡等。 | |
| 功能权限 | FunctionPermission | 针对产品功能的授权 | 能访问某个菜单 | |
| 数据权限 | DataPermission | 针对业务数据的授权 | “只能访问最近7天的订单数据” | |
| 系统 | system | 将系统资源组织后展示给请求者的入口，各个UI和PORTAL | 比如酒店EB、开店宝、酒店APP等 | |
| 菜单 | menu | PORTAL上的功能点，商家可见的功能 | 比如订单管理、促销管理 | |
| 主体 | subject | 权限业务概念 访问系统的人或组织，权限的实行者，通常为一个商家账号，也可以是其他账号或组织体系 | 比如BD、商家等，通常是账号 | |
| 操作 | action | 权限业务概念 主体对资源 所执行的动作，比如敏感读，普通读，编辑，审核，删除等。针对不同类型的资源，action 的集合是不同的 | ||
| 策略 | policy | 权限业务概念 主体访问/操作资源过程中，可以有非常复杂的路径和所属判断，该判断路径整体上被称为策略 | 比如合同签署审核权限，当主体是商家主责BD、战区经理等角色时，可以拥有权限；关于该权限路径的整体表达叫策略 | |
| 品牌馆 | BrandHall | 品牌馆是餐饮连锁品牌的线上品牌店，它汇聚品牌信息，是品牌线上营销的阵地，平台以此为载体可为品牌提供全方位的增值服务。我们需要进行内容呈现+营销。我们希望通过本次项目，完善品牌馆产品，使品牌馆成为一个可以向战略KA、KA客户大规模推进的完善产品。 | ||
| B端商城 | 2BMall | 商家能够进行线上交易的平台 | ||
| B端商品 | 2BProduct | 商家在B端商城上能购买的商品 | ||
| B端交易 | 2BOrder | 商家在B端商城上进行的交易 | ||
| 课程 | course | 供给侧发布的内容载体，包括图文、视频等，统称为课程。 | 到综：图文课程、系列课程、专题课程 美酒：公开课程、店长课程 | |
| 入驻 | Settled | 广义的签约合作，比如第三方培训机构跟平台合作；或者个人讲师跟平台合作。 | 到综：第三方机构通过销售，签署电子协议入驻商家学院平台； 美酒：讲师招募，入驻商家学院平台； | |
| 讲师 | Teacher | 职责：承担学院会议/课程计划内的授课分享工作 提供培训课程内容产出，讲师有一定的等级，和讲课激励机制 | 例如： | |
| 手艺人 | Technician | 有技能的一批人，可以理解为一种人维度的POI；具备的信息管理、自营销、营销等能力； | eg:发型师、美甲师、健身教练 | |
| KOL | Key Opinion Leader | 意见领袖，指一些大V、网红 | ||
| 积分 | 2BPoint | 一种商家货币，由商家完成任务、在线经营目标等情况下获得； 积分是商家维度； 积分可以进行消耗，获取到平台资源或者服务 | ||
| HOS | HOS | 酒店商家综合经营能力的评估标准，分值是0~5.5分 dxw.sankuai.com/cms/content… | ||
| 销售支持 | 产品 | Product | 美团点评对商家提供的可以达成合作，对商家或对消费者有一定价值的物体或无形的载体 | 团购、买单、代金券、预订、CPC、CPS、小白盒、二维码、收银机、酒店预订、PMS、智能门锁、门票、民宿等 |
| 业务 | Biz | 具有相同特性的产品集合 | 团购买单代金券统称为交易业务； CPC、CPS、霸王餐等统称为推广业务； 小白盒、二维码、POS机等统称为收单业务； | |
| 公海 | PublicSea | 每个业务都有一个目标资源范围 （可以合作某业务的资源全集） | 业务目标是团购买单合作，限定POI为餐饮和综合商场品类全国的门店 | |
| 战区体系 | 资源划分方式 | 到餐的交易战区以GIS的图层要素为依据划分； | ||
| 战区 | BattleZone | 为销售组织划分的资源范围 | orgunit：虚拟销售管理行政单元 | |
| 销售组织 | Org | 针对销售管理设置的组织结构 | 以org代替实现 | |
| 私海 | PrivateSea | 在公海内个人圈定的资源集合 | 交易私海 | |
| 门店组（暂定） | PoiGroup | 符合一定条件的门店的集合 | 大客户门店组、城市小连锁门店组； 到综的轮转租 | |
| 阶段 | SaleStage | 销售动作在签约、维护等不同时机的划分 |
