两层 Workspace：全局经营与单客户服务
日期：2026-09-29。状态：prototype-implemented（两层结构与服务事项）；完整业务闭环仍为设计中。
方向依据：用户明确提出两层工作区——顶层管理全部用户、配货和后台经营；下钻到具体用户后，集中呈现能帮助该用户办理的全部工作。当前视觉暂定沿用；本文件定义信息架构与办理方式；两层工作区已接入当前预览，具体实现边界见文末。不是REQ锁定或权限政策批准。
上游：运营支撑审查、交易严谨性、一周无忧。全局管理覆盖十个业务上下文及系统公共能力，单客户视图按归属聚合相同事实与操作。
2026-09-29 方向澄清：固定采用全局经营管理＋单客户下钻结构，为小程序运营提供完整管理能力。客服故事仅用于改进具体功能的操作与异常处理；不新增“我的工作”、接待或交班体系，不按个人工作过程组织后台。全局和客户视图复用同一业务能力，以权限控制数据范围和动作。
1. 定位：客服能在一个上下文里办完一件事
全局工作区回答：今天整个经营盘面怎样，哪些用户或履约批次需要处理，资源怎样安排。
客户工作区回答：这位客户遇到了什么，我有权帮他做什么，办理到哪一步，下一步归谁，客户看到什么。
“全部工作”包括受理、代填、取得授权、执行合法业务动作、提交审批、跨岗协作、异常恢复与结果解释。客服没有资金或质量权限时，可以在同一案件中提交复核、看到接手与进展；不会因为本人无权执行就失去服务闭环，也不能因此取得无限权限。
顾客不便操作的功能，需要受托协助；不允许顾客直接操作但存在合法经营需要的功能，需要有权工作人员处理；任何人都不能做的事，例如伪造到账、复活已取消订单，仍不开放。
2. 两层信息架构
flowchart TD
G[全局经营工作区] --> G1[今日运营 / 异常与待办]
G --> G2[客户与服务队列]
G --> G3[需求备货 / 配货与履约]
G --> G4[商品内容 / 资金核算 / 组织系统]
G1 -->|受影响客户与事项| C[单客户工作区]
G2 -->|选择客户| C
G3 -->|订单或配送对应客户| C
C --> C1[服务总览 / 当前案件]
C --> C2[餐桌计划 / 购买订单 / 配送安排]
C --> C3[资金与结算 / 售后补救]
C --> C4[资料偏好 / 授权与服务历史]
C1 -->|协作任务与源对象引用| G3
C1 -->|复核任务与资金目标| G4
进入客户工作区后，左侧导航切换为该客户的工作导航。顶部持续显示客户身份和返回入口。全局管理仍可返回，当前客服事项保持可恢复。不能只在旧82页上增加一个“客户筛选框”就认定完成改版。
2.1 全局经营工作区
| 工作区 | 日常工作 | 进入客户工作区的落点 |
|---|---|---|
| 今日运营 | 待确认与正常安排概览；到期漏处理、变更冻结、资金未知、履约受阻、无人接手与超时 | 对应客户＋具体异常/服务案件 |
| 客户与服务 | 按受权客户标识、订单号、服务号检索；来电/线上请求受理；业务进度、异常、必要复核 | 客户服务总览或已有案件 |
| 需求与备货 | 区分草稿、已付未确认、已确认需求；按日期/物料/规格汇总；到货与缺口协调 | 查看受影响客户及其安排 |
| 配货与履约 | 按区域/时刻/作业批次配货，物料与质量门禁、切配、称重、封包、交接、配送 | 客户当前配送或售后补救 |
| 商品与经营内容 | SKU/合法规格、价格版本、菜谱映射、鲜讯、定时发布/撤回 | 受影响购买与客户告知事项 |
| 资金与财务 | 原款/退款异常、购买批次结算、对账、账务核算；经营资金与会计分别表达 | 客户资金明细及对应原交易 |
| 经营分析与治理 | 经营指标、渠道、组织权限、政策、通知/调度/审计/受限恢复 | 受影响事项；平台不改业务事实 |
这些是任务组织分区，不是新建七个事实Owner。顶层保持统一全局管理结构，客服、配货、财务等岗位通过权限控制数据和操作；“全局”指跨客户工作范围，不表示每个员工能查看所有客户或所有数据。
2.2 单客户工作区
| 导航 | 必须能看清 | 集中办理的工作 |
|---|---|---|
| 服务总览 | 当前诉求、近期与下一餐、待确认、履约异常、资金未决、我的责任与等待方 | 开始服务、继续案件、邀请核对、移交接收、升级、告知结果 |
| 餐桌与计划 | 按日/餐次的菜品、规格、份数；计划、购买、配送三条独立事实 | 协助编排未付草稿、复用菜卡、处理规格失效；已付换菜进入变更案件 |
| 购买与订单 | 购买批次、独立订单/行、已购快照、原单/后继关系 | 代填购买草稿、取得客户接受；取消、改量、替换、改址/改期；核对每一步结果 |
| 配送安排 | 每次覆盖餐次/数量、地址、期望时刻、授权/费用、承接和实际进度 | 提醒、查证确认、获准的受托申请、重新安排、延误/失联/拒收/部分交付处置 |
| 资金与结算 | 每笔原款及分配、占用、实际消费、待结算、退款预留/实退；争议与未知 | 解释钱款、提交符合依据的退款/差异处理、申请退出、查询原请求、跟进复核/结算 |
| 售后与补救 | 问题商品/订单行/包裹/批次、诉求、证据、方案与分项执行 | 代录售后、部分退款、补送新单、回收、质量核验、执行结果告知 |
| 资料与偏好 | 联系点、地址簿、常用时间、家庭偏好、个人菜卡、用途授权/限制 | 受托更正、授权管理、隐私请求受理；不得回写已成交快照 |
| 服务记录 | 全部案件、客户授权、经办/复核/接手记录、拒绝原因及原请求回执 | 继续原事项、核验未知、跨岗交接；沟通完成与业务完成分开 |
个人菜卡可从“餐桌与计划”直接编辑授权草稿，“资料与偏好”提供完整维护入口；两处引用同一对象。资金页面展示可解释去向，不做可充值通用钱包。工作区与小程序看同一业务事实，后台保留更多诊断、证据与协作信息。
3. 页面结构与上下文
← 返回客户队列 客户：林女士 · 尾号0182 · 城南 查找 / 切换客户
服务上下文：本次来电咨询 · 案件 CASE-… · 经办 小陈 · 身份核验状态
─────────────────────────────────────────────────────────
左侧：本客户导航 中间：当前任务与事实 按需侧栏：正在办理
服务总览 今天 / 明天的餐次 换菜申请
餐桌与计划 原计划、购买、配送 当前步骤与等待方
购买与订单 当前未完成事项 客户授权 / 影响核对
配送安排 精确对象与源时点 执行 / 复核 / 回执
资金与结算
售后与补救
资料与偏好
服务记录
- 客户身份常驻：显示脱敏姓名、稳定标识、区域及必要区分信息，同名客户不能仅凭姓名选择。涉及出货/资金的确认面再次显示客户与具体目标。
- 在客户工作区内切换页签，客户、案件、已选目标保持；所有列表默认且强制属于该客户及员工有效范围。
- 案件不是强制每次只读浏览都新建：纯查询保持用途访问记录；需要代办、承诺跟进或跨岗协作时，建立/关联服务案件。
- 办理面可用侧栏，复杂替换/结算用主内容区；保持相同客户和案件标识。页面容器不是业务状态机。
- 从全局异常进入某客户后，自动定位原异常；返回保留全局筛选、分页/滚动和日期。不会返回空白首页。
- 切换客户时，有未提交内容则明确“保存草稿 / 放弃 / 留在当前客户”；草稿属于原客户，不带入新客户。已提交未知请求继续挂在原案件。
- 对象路由使用显式类型及ID，例如
/customers/{customerId}/service/{caseId}；链接对象必须再次校验归属和范围，不依赖姓名匹配、前端筛选或拆字符串猜对象类型。 - 同时打开多位客户时，各页签有独立上下文；旧标签页提交仍核验客户、对象、授权和版本。不能用一个全局可变
currentCustomer决定写入目标。 - 来源暂不可用时只标缺失分区及时间，不把客户所有信息清空，也不把没查到的款项写成未付款。
4. 客服办理能力分级
| 类别 | 例子 | 办理方式 | 用户参与及约束 |
|---|---|---|---|
| 读取与解释 | 查进度、解释收费、查原款/包裹 | 按岗位/用途读取；缺源保留待核验 | 不要求为普通查询反复授权；遵循已有隐私边界 |
| 代填草稿 | 安排餐次、代选商品、填写新地址/变更目标 | 保存独立草稿和来源，发给客户核对 | 草稿不付款、不确认、不触发切配 |
| 受托申请 | 用户已明确要求改时、取消、换菜；符合政策的替代授权 | 记录身份核验与具体授权，预览影响，再调用受控命令 | 内容、范围、费用、时效明确；电话等替代授权方式待业务决定 |
| 工作人员专属办理 | 核实现场、接受观察、受权售后裁决、处理账单差异 | 对应岗位权限和必要复核，保留依据；执行回到事实Owner | 不是每次都让客户确认内部技术步骤；改变其承诺/费用仍需适用授权 |
| 跨岗协作 | 资金复核、质量放行、配送重新调度 | 客服从案件提交，专业岗接手，结果自动回到原案件 | 不能让客服手抄结果或替专业岗点成功；接收前责任不消失 |
| 禁止绕过 | 修改订单终态、直接标到账/退款成功、忽略质量门禁 | 不给通用状态编辑器；明确拒绝及合法替代路线 | 管理员同样受限；若应继续服务，创建合法新目标而非复活旧单 |
用户无法操作时，后台应能受理并推进到可合法完成的位置。如果剩下的唯一条件是政策未允许的授权方式，界面必须显示等待原因、责任人及替代方案；不能仅有“无权限”且无服务出口，也不能擅自把问题改成已完成。
5. 一件事的办理容器
服务案件负责客户沟通和协作索引；变更、退款、补送、质量等仍由原业务对象拥有各自生命周期。不能把所有业务合成一个万能Case状态。
每个正在办理的事项至少呈现：
- 诉求与范围：客户要什么，涉及哪天/餐次/订单行/数量；如何进入案件，是否重复诉求。
- 当前事实：计划/资金/授权/执行分别是什么，来源与时点，已经发生的物理事实。
- 可以怎么办：可行方案、不可行原因、受影响金额/时间/其他安排；可选择的替代路线。
- 所需授权/复核：客户已同意什么，哪步仍待客户或专业岗，不把已有授权无限扩大。
- 分项进度：每个步骤的目标、负责人、状态、等待年龄、下一步；未知可查询原请求。
- 办理结果：成功、明确拒绝、部分完成或继续等待；钱和货分别交代，客户能读懂的说明。
- 客户回看：小程序对应餐次/订单/售后显示同一结果；通知失败只影响告知，不重做业务。
“沟通已结束”可以是一个交流记录的结果，但原退款未完成时服务总览仍展示待办和责任。专业岗位接手不等于客服可以把客户诉求丢到另一个模块。
6. 必须先画通的实战故事
下表是本次信息架构的结果验收输入，不取代尚未修订的正式 stories.md/flows.md。后续并入同一模块的规范场景，不复制第二套长期测试目录。
| ID | 触发与入口 | 用户工作区办理路径 | 可观察终点与异常 |
|---|---|---|---|
| WS-01 | 用户来电：已付款为什么没送；客户检索 | 服务总览→当日安排→授权与资金→解释/登记后续诉求 | 说明本次不送的真实原因、钱款状态和后续；没有确认不能归责为商家已送 |
| WS-02 | 用户不会操作，想安排几餐 | 餐桌与计划→代填草稿→客户核对→购买 | 客户接受后形成明确购买与待逐日确认；拒绝/失联草稿不执行 |
| WS-03 | 临时不做饭，取消明晚一餐 | 购买→选明细→停止条件/影响→客户请求→协调进度 | 只处理目标餐次；源停止/资金各自可见；开工已发生走专属处置 |
| WS-04 | 已付青椒肉丝改排骨 | 计划→换菜→原款/差价→旧执行停止→后继新单→新授权 | 沿原餐次看更换结果；补款未知查原目标，不复活旧单或双做 |
| WS-05 | 已确认后改地址/时间 | 配送→选本次→新范围与费用→必要授权→承接结果 | 地址簿与本次变更分开；超范围/已出发明确拒绝或转补救 |
| WS-06 | 到期未确认，现在又想送 | 配送→旧结果→请求重新安排→新目标/报价/授权 | 旧尝试保持终态，新尝试合法接受；原款不可用时解释原因 |
| WS-07 | 用户无法使用小程序，但希望确认 | 服务总览→身份核验→获准授权路径/客户核对邀请→受理 | 合规业务政策下可完成；方式未批准时有等待/替代路线，不默认为同意 |
| WS-08 | 收了配送费，却没显示接受 | 资金→原费用目标→核验→安排接受或补偿 | 资金、授权、安排结果分别清楚；仍未知有责任与继续查询 |
| WS-09 | 少送一件或质量问题 | 售后→选具体行/包裹→方案与复核→退款/补送/回收 | 分项核验、部分完成可见；补送新目标，不恢复已完成原单 |
| WS-10 | 用户想退出余下安排 | 购买批次→可处置范围→停止/结算依据→退款进度 | 无争议及待核验部分区分；政策不明不虚构到账承诺 |
| WS-11 | 配货发现整批质量问题 | 全局质量/配货→受影响客户→各自补救案件 | 一个全局事件关联多客户，逐客跟进；其他客户信息不泄漏到当前工作区 |
| WS-12 | 退款跨班仍未知，原客服下班 | 原案件→交接→接收岗/人员→原目标查证→结果告知 | 接收前不失责；案件不因沟通完成关闭资金义务 |
| WS-13 | 实际已切配但系统无回执 | 全局异常→客户案件→现场核实→接受证据或处置 | 不重派同份切配；现场未知维持受控阻断 |
| WS-14 | 用户改菜卡但相关商品停售 | 个人菜卡→影响范围→替代草稿→客户决定 | 未付草稿可修订；已付餐次须独立变更；不改全部历史 |
| WS-15 | 同名客户、切错用户、多人同时办理 | 检索区分→客户常驻→确认面→版本/授权检查 | 不跨客户提交；保存草稿归原客户；冲突返回原案件继续处理 |
| WS-16 | 客户账号受限/隐私请求，但仍有退款 | 资料限制→授权解释→受限服务案件→资金恢复 | 不扩大访问用途、不遗弃既有义务；无资格客服可提交接手而非强行执行 |
7. 两层之间怎样协作
- 跨客户事务留在全局：批次召回、统一延误、备货调整、价格改版和批量通知在顶层办理；单客户视图只看当前客户所受影响及其选择。
- 单客户动作回到其案件：客服不必离开工作区去找“退款列表”重新手录一条；点击申请后生成对应资金目标/复核任务，回执回流。
- 专业岗可以同样下钻：财务从全局退款队列进入该客户原交易，质量从召回进入受影响包裹；仍只获得自身权限，不继承客服或管理员权限。
- 批量操作逐项裁决：操作前列客户和对象范围，提交时逐项检查版本/权限，返回成功、失败、未知及原因；不能假装整批全成功。
- 接手不是重新做：全局恢复队列与客户工作区指向同一原请求和业务目标，不能分别新发一次退款或配送。
8. 从现有82页迁移的原则
| 现有能力 | 全局落点 | 单客户落点 |
|---|---|---|
| Customer档案、地址、计划、菜卡、服务事项、同意限制 | 客户检索、服务分派及治理队列 | 客户导航主要内容，按真实客户引用聚合 |
| Commerce订单、报价、支付、退款、变更、替代、售后、权益 | 全局交易/资金例外、定价经营 | 客户的购买、资金、售后及办理面 |
| Demand确认、承诺、费用、能力、周期服务 | 全局确认/到期监控、政策与能力 | 客户当前安排、费用依据、授权及重新安排 |
| Fulfillment任务、称重、包裹、配送、回收 | 配货和专业作业 | 当前客户执行事实、受控请求、异常/补救进展 |
| Supply接收、物料、质量、召回、追溯 | 供给、质量、经营准备 | 相关实物证据和处置影响；不在客户侧直接改库存 |
| Catalog商品、菜谱、内容、发布 | 经营管理与发布 | 可选商品/历史规格及受影响内容引用 |
| Finance核算、Channel集成、Analytics指标 | 专业全局工作区 | 只暴露解释服务所需来源与结果，最小权限 |
| Identity和Platform机制 | 组织、访问、系统治理及恢复 | 上下文鉴权、案件协作、审计、证据和通知 |
本轮将现有82页看作可复用能力，而非必须全部保留在一级导航的82个菜单。迁移时每个旧入口有明确新落点或经批准的退出原因；新建来源关系和样例先修复，不能只替换壳层。
新增重点是客户组合查询、受托办理、协调步骤、购买批次与资金分配、业务异常索引。它们由已定义Owner供给，不另复制业务账本。
9. 已接受方向、待决政策与交付顺序
本轮方向输入：两层Workspace；选定客户后有完整且有针对性的操作视图；后台承担小程序监控和兜底。当前风格暂定保留。
本文件设计建议：具体导航命名、8个客户分区、上下文切换规则和办理容器。可以在实际原型中调整，不把本稿当冻结像素规格。
已确定机制：付款核验且订单成立后即可提前确认，默认配送日北京时间16:00截止，未确认自动取消、已确认无需重复；未切配可申请取消/换菜，由停止与开工竞争裁决；实际重量计价。订单不跨日期/地址，独立时段拆单，旧终态不恢复。
仍待业务定案：替代授权方式、岗位可办范围及复核门槛、部分取消/费用、配送费用档位、精确计价分摊、退款方式与时点、接手时限。只引用架构DECISIONS，不把已确定原则重列为待定。具体办理按业务机制与异常处理；两层Workspace不自动扩大权限。
建议下一轮原型交付顺序：
- 两层壳与同一客户事实链：全局检索/异常入口、客户常驻、返回及切换、8个客户分区、完整合成对象关系。
- 实战办理：逐项补齐WS-01～16的成功、拒绝、未知、部分失败、权限和交接；关键写操作不能继续靠“回执齐全”下拉框证明源事实。
- 全局经营与专业工作区：客户案件与配货、资金、质量队列双向联办；按架构覆盖其余经营能力。
- 更新原有stories/flows/cases并进行同一数据集的两端结果验收，再讨论是否满足完整运营支撑。
壳层完成不等于本轮全部功能完成。每项进入下一轮设计时必须映射原审查G01～G18及J01～J36，清楚列出关闭证据，不能因菜单归入Workspace就销项。
10. 取舍与恢复
没有选择继续按领域平铺，因为跨域拼查仍由客服承担；没有选择直接嵌入小程序并代登录，因为授权身份、专业处置和审计需要独立表达。采用客户上下文下的任务工作区，代价是增加组合查询与跨域办理设计；事实仍由原Owner维护。
本轮只增加设计文档和草稿范围说明，无产品数据迁移。后续原型切换须保留旧深链接映射、客户/案件ID、历史回执及未提交草稿归属；未知旧记录隔离核验，不自动归到默认客户。回退视觉壳不回滚已发生的资金/现场事实。设计维护Owner为主会话，真实岗位与政策责任人仍待指定。
2026-09-29 两层结构实现记录
已接入当前预览
- 全局首页增加客户入口与服务协作入口；原经营模块保留。
- 客户目录支持姓名、电话尾号、业务记录编号检索；点击进入单客户工作区。
- 八个客户分区与持续身份栏；业务列表按显式
customerId归属及当前范围筛选。 - 客户服务事项支持 11 类诉求入口、目标对象选择、方案、客户答复、专业岗接手、交接待接收、跟进及归档。
- 每位客户单独保存受理草稿；办理弹窗打开时阻止路由切换；关闭未保存的受理表单需确认放弃。
- 专业记录关联需同客户且明确引用原对象；核验源结果检查状态，不能通过备注直接完成退款或履约事项。
- 全局服务队列与客户服务轨迹共享本地事项数据；保留原有本地业务记录并增补客户归属，不自动重置。
观察范围与未完成事项
通过浏览器实际打开客户目录、客户总览、受理表单、咨询事项详情和资金分区；记录桌面及移动视口截图。本轮未运行完整业务测试或正式验收。
本次是信息架构及客服协作原型重组，不表示之前18组运营缺口全部关闭。源业务仍有以下限制：
- 专业事项目前关联已有源记录；取消、换菜、新安排、分项售后尚未从服务方案自动生成完整执行链。缺少源记录时事项保持处理中。
- 代填计划目前保存为服务方案，不自动生成可购买的结构化餐次；客户答复为原型演示登记，未接入真实小程序授权。
- 岗位仍为经办/复核/只读三档演示，专业岗位身份及生产权限尚未实现。
- 旧合成数据存在关联与区域不一致。按客户及区域取交集展示；不把旧错误关系静默当成合法证据。跨域原操作的审查缺口继续保留。
- 预览数据存浏览器，不与小程序或后台服务同步；跨窗口提交核对版本，尚无服务端并发与事务保障。
恢复方式：保留 site/ 上版作品；新代码集中在 workspace-model.js、workspace-view.js、customer-ownership.json 及 app.js/样式接入。无需修改或重置小程序数据。
全局管理结构调整（2026-09-29）
预览当前以全局经营概览为首屏；11个模块概览覆盖原82功能入口；客户总览直接呈现计划、订单、确认、资金、交付和售后。全局详情可下钻客户内的同一条记录，再返回全局；两层复用原业务处理函数。
不增加个人工作台、接待或交班模块。前文“受理服务”及以案件统领全部办理的描述只保留为早期方案沿革，不能作为下一轮顶层设计依据。历史服务记录仍可查看，但不是查看、管理订单或其他业务的前置条件。
审查、实际调整、定向证据与尚未完成项见全局管理审查。