定义、边界与相近类型

2.1 什么叫“垂直”

垂直SaaS的最小判定不是官网出现行业名称，而是同时满足：核心对象来自特定行业；关键工作流反映该行业真实责任；数据和集成模型围绕行业系统；实施知识能沉淀为复用配置；成功指标连接客户行业结果。若产品只提供通用审批、聊天或客户关系功能，而行业逻辑主要靠客户自己搭建，更接近通用SaaS或低代码平台。

01业务起点

02协作与交接

03结果与复盘

图 1：行业对象模型把“懂业务”变成可配置结构，也是销售、实施、权限、计量和分析共享的语言。

判定维度	垂直SaaS	通用SaaS	项目制软件	交易平台
核心价值	行业流程和知识产品化	跨行业通用协作能力	为单一客户完成特定系统	撮合、承载或管理交易
对象模型	门店、配方、批次、检查等行业对象	联系人、任务、文件等通用对象	按项目需求定义	商家、消费者、订单和结算
交付方式	标准产品+受控配置+集成	轻配置和自助采用	需求、设计、开发、验收	入驻、交易规则、风控运营
收入	订阅为主，实施/用量为辅	席位或套餐订阅	里程碑、工时、维保	佣金、广告、服务费等
主要风险	行业责任、数据、采用、续费	安全、可用、通用采用	范围、进度、验收、回款	平台责任、交易和消费者

2.2 四个容易串案的边界问题

正在绘制业务流程…

一是“接了外卖订单”不自动等于网络食品交易第三方平台，要看谁招募和审核商家、制定平台规则、承载交易、处理投诉和控制下架。二是“提供检查模板”不等于成为食品安全责任主体，要看谁设定制度、执行现场检查、判断风险并签字。三是“为客户配置工作流”不自动等于项目定制，要看是否在版本化参数边界内。四是“代发会员消息”不等于取得自由营销权，目的、指令、同意、退订和分包关系必须明确。

2.3 行味云的对象模型

稳定ID	对象	主键与关键关系	权威来源	不允许的替代键
TERM-I03-01	租户	tenant_id→合同客户	租户管理系统	客户简称
TERM-I03-02	品牌	brand_id→租户	主数据服务	商标文字
TERM-I03-03	门店	store_id→品牌、法人、区域	客户主数据+审批	门店名或地址
TERM-I03-04	菜品/配方	item_id→版本、生效日	产品主数据	菜名
TERM-I03-05	供应商资质	supplier_id→证照版本、有效期	客户采购系统	供应商简称
TERM-I03-06	批次/库存	lot_id→物料、门店、日期	进销存/接口	手工备注
TERM-I03-07	检查任务	task_id→模板版本、门店、责任人	任务服务	群消息
TERM-I03-08	异常事项	issue_id→任务、整改、关闭证据	风险工作流	截图文件名
TERM-I03-09	会员	member_id→租户、同意版本	会员服务	手机号明文
TERM-I03-10	部署波次	wave_id→门店清单、UAT、上线	实施系统	“第二批”文字

对象模型不是为了画ER图，而是决定价格单位、权限边界、迁移计数、计量去重、报表口径和退出删除。门店重命名不应生成新门店主键；品牌换法人需要有生效日的关系变更；配方改版要保留历史订单与检查当时使用的版本；会员手机号变更不能破坏同意与触达证据。

2.4 官方行业规则如何进入产品，而不被产品“写死”

市场监管总局关于连锁餐饮主体责任的现行规定可支持总部、分支、门店的工作制度与记录需求，但产品团队不能把某个时期的频率、表单名称或门店数阈值永久写入代码。正确做法是：法务/行业专家识别来源与适用事实；产品经理把规则拆成可配置参数；客户责任人批准自身制度；实施团队加载并UAT；变更发生时按租户和生效日迁移；审计能还原当时版本。

层级	由谁决定	产品怎么承载	证据
法律法规与监管要求	有权机关；企业据事实判断适用	来源登记、规则族、有效期	官方链接、核验日、适用性备忘
客户内部制度	客户授权责任人	频率、阈值、责任层级参数	客户批准单、版本记录
产品默认模板	行业产品负责人	可复制初始配置	发布说明、测试记录
门店执行	门店和客户管理链	任务、证据、异常、升级	时间戳、操作者、附件、关闭