智慧食堂云市场产品货架 V0.5

• Version: V0.5 cloud-market shelf review draft
• Date: 2026-07-19
• Planning object: 华为云云商店、阿里云云市场可搜索、可比较、可下单的商品货架
• Decision owner: 产品、销售、市场、云市场运营、交付、财务
• Evidence: A/B/C/D 分级；本版用于内部评审，不是已经审核通过的外部上架文案或正式报价
• Human review status: pending

0. 这次纠偏的结论

V0.4 解决了“产品线、场景、能力、规模、部署不能混在一起”的问题，但仍然没有完全站到云市场货架前看产品。

云市场客户不会先问：

我是单校还是集团，我应该买哪个版本？

他会先问：

我现在最急的是报餐餐补、称重结算、采购库存、食品安全、营养健康，还是多个食堂看不清？

因此，新的货架规则是：

一个主要购买任务，对应一个可独立搜索、比较、报价和验收的商品。

单校 / 集团 / 企业 / 园区是适用标签，SaaS / 独立部署 / 信创是交付配置，站点数 / 账号数 / 设备数 / 服务人群 / 购买年限是规格和计价单位，都不应继续充当第一层商品名称。

1. 云市场上的真实做法

1.1 同行页面主要有三种货架结构

1.2 平台官方规则给出的硬约束

• 华为云要求商品名称准确、与内容及软件著作权相符；同一商品的不同版本应通过“规格”区分，不需要重复发布多个商品。
• 华为云要求规格名有明确规则，不能只叫“规格1”“一套”“一年”；每个规格必须写清所含功能和服务。
• 阿里云 SaaS 商品允许按“版本 + 周期/次数 + 账号数 + 自定义属性”配置规格和额外计费项。
• 两个平台都把 SaaS、License、镜像、人工服务、硬件视为不同交付类型。商品交付类型必须和实质一致。

官方规则入口：华为云商品发布填写规范、华为云商品发布总览、阿里云发布 SaaS 商品、阿里云服务商管理规范。竞品页面与允许支持的结论详见本任务的 source-evidence.md。

因此，康比特不能只设计一张“版本价格表”，而要同时设计：

1. 客户搜索到的业务商品。
2. 商品内部可选择的规格 SKU。
3. 复杂项目需要关联购买的实施、接口和硬件交付商品。

1.3 不应盲目照抄同行

阿里云公开的“智慧食堂”SaaS 商品采用“标准版 300 元/月、3600 元/年”，页面显示近 180 天成交 0 笔。这个事实不能证明低价或大而全命名导致零成交，但至少说明：

上架、低价和功能齐全，不等于客户会买。

公开样本的价格从每月数百元到每年数十万元，甚至近百万元，交付形态也横跨 SaaS、License、镜像、硬件和人工服务。这些页面只能作为货架结构和价格带观察，不能直接当成康比特报价依据。

2. 康比特云市场四层商品模型

3. 建议上架的七个客户货架

七个货架按“客户第一句话”划分，而不是按客户组织类型划分。

4. 七个货架的对外描述草案

以下文案按“客户能否一句话理解并转述”编写。正式上架前仍需完成软著名称、真实页面、功能范围、价格、服务协议和交付证据核验。

4.1 货架 A：康比特食堂报餐与餐补结算系统

谁应该买： 已经有食堂，当前最急的是报餐统计、单位餐补、人员账户、消费结算和财务对账。

一句话简介： 把员工报餐、餐补发放、刷卡/扫码/刷脸消费、订单和财务对账放到一个系统里，让后勤少统计、财务少核对、员工吃饭更方便。

最多五条亮点：

1. 提前报餐，备餐更有数。
2. 餐补规则统一配置，发放和使用可追溯。
3. 多种消费入口统一形成订单。
4. 财务对账和补贴台账可导出。
5. 支持与组织、支付和一卡通系统按约定对接。

建议规格：

• 预约报餐包。
• 餐补结算包。
• 报餐结算一体包。
• 组织/一卡通接口增值项。
• 独立部署授权作为关联 License 商品，不混进 SaaS 商品规格。

主要验收： 报餐路径、补贴规则、订单完整性、对账差异、异常退款、权限和日志。

4.2 货架 B：康比特智能称重营养结算系统

谁应该买： 自选餐、称重餐、档口餐厅存在高峰结算压力，需要软件、秤台或识别终端联动。

一句话简介： 面向自选餐和称重餐场景，把身份识别、称重计价、餐品信息、消费结算和营养展示连接起来，减少人工计价环节并沉淀真实就餐数据。

最多五条亮点：

1. 支持称重、自选餐和档口结算流程。
2. 统一身份、菜品、重量、金额和订单数据。
3. 支持卡、码、脸等入口按项目边界接入。
4. 结算终端异常和交易记录可追查。
5. 为菜品营养展示和后续膳食分析提供数据入口。

建议规格：

• 称重结算软件授权。
• 每新增结算点授权。
• 设备协议接入服务。
• 现场安装联调服务。
• 智能秤台、识别终端和外设作为独立硬件商品或明确 BOM。

主要验收： 设备型号、协议、计价规则、断网/重传、退款、日志、交易一致性和现场联调记录。未形成真实 benchmark 前，不对外承诺识别准确率和峰值速度。

4.3 货架 C：康比特食堂采购库存与成本管控系统

谁应该买： 食堂采购、验收、入库、领料、盘点和成本核算仍靠 Excel 或多套系统。

一句话简介： 把供应商、采购、验收、库存、领料、菜谱用料和经营报表连起来，让食材从买进来到用出去有记录，成本和损耗有依据。

最多五条亮点：

1. 供应商、商品和资质集中管理。
2. 采购、验收、入库、出库和盘点全程留痕。
3. 临期、库存和价格异常按规则提醒。
4. 菜谱、用料和采购计划可关联。
5. 采购、库存、成本和供应商报表可复盘。

建议规格：

• 采购库存基础包。
• 询价比价协同包。
• 菜谱 BOM 与成本分析包。
• 智能验收秤接入项。
• 供应商协同账号或站点阶梯。

主要验收： 库存准确、单据闭环、批次追溯、权限、成本口径和导出一致性。没有真实经营数据前，不承诺具体降本比例。

4.4 货架 D：康比特食堂食品安全台账与巡检系统

谁应该买： 食安记录分散、检查靠纸、异常整改没有统一责任和闭环证据。

一句话简介： 把人员健康、晨检、留样、消毒、环境、设备、食材追溯、巡检和整改记录集中起来，帮助食安责任人快速发现问题并留下处理证据。

最多五条亮点：

1. 常用食安台账统一电子化。
2. 食材批次、供应商和出入库信息可追溯。
3. 巡检问题可分派、整改和复核。
4. 温湿度、留样柜和视频设备可按白名单接入。
5. 监管报表和检查证据可按权限导出。

建议规格：

• 食安电子台账包。
• 食材追溯与整改闭环包。
• 明厨亮灶/物联设备接入包。
• AI 巡检增值包，待算法指标、误报处理和人工复核通过后开放。

主要验收： 台账字段、记录完整率、异常闭环、设备在线、权限、审计和导出。系统只提供记录、提醒、关联和证据，不替代食安责任主体。

4.5 货架 E：康比特膳食营养分析与健康服务平台

谁应该买： 工会、人力或健康负责人希望把食堂从“提供一顿饭”升级成可持续的员工营养服务。

一句话简介： 把菜品营养、实际就餐记录、群体膳食分析和营养运营服务连接起来，为单位开展非医疗的营养宣传、菜单优化和体重管理主题活动提供工具与服务。

最多五条亮点：

1. 菜品和菜单营养信息统一管理。
2. 个人授权后可查看膳食记录和提示。
3. 管理者可查看脱敏的群体趋势。
4. 支持营养主题活动和内容运营。
5. 可配置营养师服务和周期报告。

建议规格：

• 菜品营养标识包。
• 群体膳食分析包。
• 年度营养运营服务包。
• 体重管理主题活动包。

主要验收： 数据授权、最小化采集、脱敏、报告样张、服务频次、参与和使用记录。不得使用诊断、治疗或保证健康效果的医疗化表述。

4.6 货架 F：康比特多食堂经营监管平台

谁应该买： 总部或区域管理部门已经管理多个食堂，但站点数据、补贴、经营、食安和设备状态无法统一查看。

一句话简介： 把多个食堂的组织、站点、经营、补贴、食安、设备和异常信息汇总到一个管理平台，让总部看见差异、发现问题、下发标准并跟踪整改。

最多五条亮点：

1. 多组织、多区域和多食堂统一纳管。
2. 总部指标与站点经营数据分级查看。
3. 食安、设备和经营异常统一升级处理。
4. 支持跨站点对标和审计导出。
5. 站点保留授权范围内的独立运营。

建议规格：

• 经营监管基础包。
• 食安监管增强包。
• 站点阶梯包。
• 数据接口和主数据治理服务。

主要验收： 站点纳管、主数据一致、权限隔离、指标口径、异常闭环和跨站点导出。没有稳定站点数据时，不先卖“总部大屏”。

4.7 货架 G：康比特智慧食堂一体化建设服务

谁应该买： 新建、搬迁或整体改造食堂，需要方案、软件、设备、接口、实施、培训和验收统一协调。

一句话简介： 为智慧食堂新建和改造项目提供需求梳理、方案设计、软硬件选型、接口确认、现场实施、培训和验收服务，减少多家供应商之间的交付扯皮。

最多五条亮点：

1. 售前需求、现场条件和接口先完成清单化确认。
2. 软件、设备、网络和服务责任边界统一拆分。
3. 标准实施计划、风险清单和变更机制可复用。
4. 联调、培训、验收和交付证据统一归档。
5. 支持按项目选择云端、独立部署或信创适配路径。

建议规格：

• 建设咨询与方案设计服务。
• 标准实施交付服务。
• 接口与数据迁移服务。
• 现场驻场与培训服务。
• 设备和基础设施按独立硬件商品/BOM报价。

主要验收： 范围、假设、排除项、设备清单、接口清单、计划、变更、培训、上线和验收证据。该货架属于项目型服务，不用虚假低价 SaaS 引流。

5. 客户如何在十秒内选对货架

6. 商品、规格和交付不要再混在一起

6.1 商品名称应该写什么

建议公式：

品牌 + 核心对象 + 主要购买任务 + 产品形态

例如：

• 康比特 + 食堂 + 报餐与餐补结算 + 系统。
• 康比特 + 食堂 + 采购库存与成本管控 + 系统。
• 康比特 + 多食堂 + 经营监管 + 平台。

名称不写价格、电话号码、夸大承诺，不写“最新版”，也不堆“AI、大数据、区块链、物联网”等技术词。

6.2 规格应该写什么

规格名直接写客户买到的范围：

• 预约报餐包，不叫“基础版”。
• 餐补结算一体包，不叫“专业版”。
• 食安电子台账包，不叫“旗舰版”。
• 10 站点经营监管包，不叫“集团版”。
• 年度营养运营服务包，不叫“健康高级版”。

6.3 适用对象应该放在哪里

企业、园区、机关、学校、医院、运动队用于：

• 商品简介中的适用对象。
• 搜索关键词和标签。
• 客户案例分类。
• 规格适用说明。

它们不是默认的产品货架。只有当某个行业存在不同的预算、责任、流程、验收和产品边界时，才值得单独拆商品。

7. 上架优先顺序

第一批：让客户看懂我们卖什么

1. A 报餐与餐补结算。
2. C 采购库存与成本管控。
3. D 食品安全台账与巡检。

原因：三个任务都容易被客户用一句话描述，也更容易形成独立演示路径、规格、验收和搜索关键词。

第二批：建立康比特差异化

4. B 智能称重营养结算。
5. E 膳食营养分析与健康服务。

原因：差异化更强，但依赖设备联调、算法指标、数据授权、非医疗边界和持续服务证据。

第三批：承接复杂项目

6. F 多食堂经营监管。
7. G 一体化建设服务。

原因：这两类合同额可能更高，但交付复杂度也更高。应建立在前五个标准商品已经形成稳定边界和可复用数据之上。

8. 每个商品上架前必须通过的门禁

9. 本版明确否定的做法

1. 不再用“单校版、集团版、企业版、云端版、本地版、信创版”作为第一层产品货架。
2. 不再上架一个“智慧食堂大礼包”，然后在详情页堆几十项功能。
3. 不再把 SaaS、硬件、现场实施、定制接口和营养师服务混成一个模糊价格。
4. 不再用“标准版/专业版/旗舰版”掩盖真实范围差异。
5. 不因为竞品公开价低就跟价；公开页面的成交、成本、交付和续费证据不足。
6. 不把 AI、营养、健康、食安效果和设备性能写成未经验证的保证。

10. 管理层需要拍板的五件事

1. 是否批准七个任务型货架，停止用客户类型和部署方式做第一层命名。
2. 第一批是否只上 A、C、D 三个边界最清楚的商品。
3. 每个货架对应哪一个现有软著、系统版本、演示环境和产品 owner。
4. 哪些能力作为标准规格，哪些必须转成接口、实施、硬件或人工服务商品。
5. 云市场运营指标是否从“上架数量”改为“有效访问 -> 咨询 -> 报价 -> 成交 -> 开通 -> 续费”。

11. 当前证据边界

• A/B：现有产品能力矩阵、设备 intake、历史项目/收入材料可以支持货架方向，但不能证明七个商品均已达到上架和外部承诺标准。
• C：华为云、阿里云公开商品页和官方发布规则支持货架结构、规格、交付类型和公开价格观察。
• D：本版七个货架、SKU 名称、优先级和对外文案均为策略草案，需要产品、销售、财务、交付、法务和云市场运营共同评审。

本版结论为 review-ready，不是 final。