# 两层 Workspace：全局经营与单客户服务

日期：2026-09-29。状态：prototype-implemented（两层结构与服务事项）；完整业务闭环仍为设计中。

方向依据：用户明确提出两层工作区——顶层管理全部用户、配货和后台经营；下钻到具体用户后，集中呈现能帮助该用户办理的全部工作。当前视觉暂定沿用；本文件定义信息架构与办理方式；两层工作区已接入当前预览，具体实现边界见文末。不是REQ锁定或权限政策批准。

上游：[运营支撑审查](../../../reports/review/ADMIN-2026-09-29-miniapp-operational-support.md)、[交易严谨性](../../../architecture/08-domain-model/TRANSACTION-INTEGRITY.md)、[一周无忧](../../../architecture/05-domain/WEEKLY-CARE-PLAN.md)。全局管理覆盖十个业务上下文及系统公共能力，单客户视图按归属聚合相同事实与操作。

> 2026-09-29 方向澄清：固定采用全局经营管理＋单客户下钻结构，为小程序运营提供完整管理能力。客服故事仅用于改进具体功能的操作与异常处理；不新增“我的工作”、接待或交班体系，不按个人工作过程组织后台。全局和客户视图复用同一业务能力，以权限控制数据范围和动作。

## 1. 定位：客服能在一个上下文里办完一件事

全局工作区回答：今天整个经营盘面怎样，哪些用户或履约批次需要处理，资源怎样安排。

客户工作区回答：这位客户遇到了什么，我有权帮他做什么，办理到哪一步，下一步归谁，客户看到什么。

“全部工作”包括受理、代填、取得授权、执行合法业务动作、提交审批、跨岗协作、异常恢复与结果解释。客服没有资金或质量权限时，可以在同一案件中提交复核、看到接手与进展；不会因为本人无权执行就失去服务闭环，也不能因此取得无限权限。

顾客不便操作的功能，需要受托协助；不允许顾客直接操作但存在合法经营需要的功能，需要有权工作人员处理；任何人都不能做的事，例如伪造到账、复活已取消订单，仍不开放。

## 2. 两层信息架构

```mermaid
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. 页面结构与上下文

```text
← 返回客户队列     客户：林女士 · 尾号0182 · 城南     查找 / 切换客户
服务上下文：本次来电咨询 · 案件 CASE-… · 经办 小陈 · 身份核验状态
─────────────────────────────────────────────────────────
左侧：本客户导航       中间：当前任务与事实       按需侧栏：正在办理
服务总览              今天 / 明天的餐次         换菜申请
餐桌与计划            原计划、购买、配送        当前步骤与等待方
购买与订单            当前未完成事项           客户授权 / 影响核对
配送安排              精确对象与源时点         执行 / 复核 / 回执
资金与结算
售后与补救
资料与偏好
服务记录
```

- 客户身份常驻：显示脱敏姓名、稳定标识、区域及必要区分信息，同名客户不能仅凭姓名选择。涉及出货/资金的确认面再次显示客户与具体目标。
- 在客户工作区内切换页签，客户、案件、已选目标保持；所有列表默认且强制属于该客户及员工有效范围。
- 案件不是强制每次只读浏览都新建：纯查询保持用途访问记录；需要代办、承诺跟进或跨岗协作时，建立/关联服务案件。
- 办理面可用侧栏，复杂替换/结算用主内容区；保持相同客户和案件标识。页面容器不是业务状态机。
- 从全局异常进入某客户后，自动定位原异常；返回保留全局筛选、分页/滚动和日期。不会返回空白首页。
- 切换客户时，有未提交内容则明确“保存草稿 / 放弃 / 留在当前客户”；草稿属于原客户，不带入新客户。已提交未知请求继续挂在原案件。
- 对象路由使用显式类型及ID，例如 `/customers/{customerId}/service/{caseId}`；链接对象必须再次校验归属和范围，不依赖姓名匹配、前端筛选或拆字符串猜对象类型。
- 同时打开多位客户时，各页签有独立上下文；旧标签页提交仍核验客户、对象、授权和版本。不能用一个全局可变`currentCustomer`决定写入目标。
- 来源暂不可用时只标缺失分区及时间，不把客户所有信息清空，也不把没查到的款项写成未付款。

## 4. 客服办理能力分级

|类别|例子|办理方式|用户参与及约束|
|---|---|---|---|
|读取与解释|查进度、解释收费、查原款/包裹|按岗位/用途读取；缺源保留待核验|不要求为普通查询反复授权；遵循已有隐私边界|
|代填草稿|安排餐次、代选商品、填写新地址/变更目标|保存独立草稿和来源，发给客户核对|草稿不付款、不确认、不触发切配|
|受托申请|用户已明确要求改时、取消、换菜；符合政策的替代授权|记录身份核验与具体授权，预览影响，再调用受控命令|内容、范围、费用、时效明确；电话等替代授权方式待业务决定|
|工作人员专属办理|核实现场、接受观察、受权售后裁决、处理账单差异|对应岗位权限和必要复核，保留依据；执行回到事实Owner|不是每次都让客户确认内部技术步骤；改变其承诺/费用仍需适用授权|
|跨岗协作|资金复核、质量放行、配送重新调度|客服从案件提交，专业岗接手，结果自动回到原案件|不能让客服手抄结果或替专业岗点成功；接收前责任不消失|
|禁止绕过|修改订单终态、直接标到账/退款成功、忽略质量门禁|不给通用状态编辑器；明确拒绝及合法替代路线|管理员同样受限；若应继续服务，创建合法新目标而非复活旧单|

用户无法操作时，后台应能受理并推进到可合法完成的位置。如果剩下的唯一条件是政策未允许的授权方式，界面必须显示等待原因、责任人及替代方案；不能仅有“无权限”且无服务出口，也不能擅自把问题改成已完成。

## 5. 一件事的办理容器

服务案件负责客户沟通和协作索引；变更、退款、补送、质量等仍由原业务对象拥有各自生命周期。不能把所有业务合成一个万能Case状态。

每个正在办理的事项至少呈现：

1. **诉求与范围**：客户要什么，涉及哪天/餐次/订单行/数量；如何进入案件，是否重复诉求。
2. **当前事实**：计划/资金/授权/执行分别是什么，来源与时点，已经发生的物理事实。
3. **可以怎么办**：可行方案、不可行原因、受影响金额/时间/其他安排；可选择的替代路线。
4. **所需授权/复核**：客户已同意什么，哪步仍待客户或专业岗，不把已有授权无限扩大。
5. **分项进度**：每个步骤的目标、负责人、状态、等待年龄、下一步；未知可查询原请求。
6. **办理结果**：成功、明确拒绝、部分完成或继续等待；钱和货分别交代，客户能读懂的说明。
7. **客户回看**：小程序对应餐次/订单/售后显示同一结果；通知失败只影响告知，不重做业务。

“沟通已结束”可以是一个交流记录的结果，但原退款未完成时服务总览仍展示待办和责任。专业岗位接手不等于客服可以把客户诉求丢到另一个模块。

## 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](../../../architecture/DECISIONS.md)，不把已确定原则重列为待定。具体办理按[业务机制与异常处理](BUSINESS-SUPPORT.md)；两层Workspace不自动扩大权限。

建议下一轮原型交付顺序：

1. 两层壳与同一客户事实链：全局检索/异常入口、客户常驻、返回及切换、8个客户分区、完整合成对象关系。
2. 实战办理：逐项补齐WS-01～16的成功、拒绝、未知、部分失败、权限和交接；关键写操作不能继续靠“回执齐全”下拉框证明源事实。
3. 全局经营与专业工作区：客户案件与配货、资金、质量队列双向联办；按架构覆盖其余经营能力。
4. 更新原有stories/flows/cases并进行同一数据集的两端结果验收，再讨论是否满足完整运营支撑。

壳层完成不等于本轮全部功能完成。每项进入下一轮设计时必须映射原审查G01～G18及J01～J36，清楚列出关闭证据，不能因菜单归入Workspace就销项。

## 10. 取舍与恢复

没有选择继续按领域平铺，因为跨域拼查仍由客服承担；没有选择直接嵌入小程序并代登录，因为授权身份、专业处置和审计需要独立表达。采用客户上下文下的任务工作区，代价是增加组合查询与跨域办理设计；事实仍由原Owner维护。

本轮只增加设计文档和草稿范围说明，无产品数据迁移。后续原型切换须保留旧深链接映射、客户/案件ID、历史回执及未提交草稿归属；未知旧记录隔离核验，不自动归到默认客户。回退视觉壳不回滚已发生的资金/现场事实。设计维护Owner为主会话，真实岗位与政策责任人仍待指定。


## 2026-09-29 两层结构实现记录

### 已接入当前预览

- 全局首页增加客户入口与服务协作入口；原经营模块保留。
- 客户目录支持姓名、电话尾号、业务记录编号检索；点击进入单客户工作区。
- 八个客户分区与持续身份栏；业务列表按显式 `customerId` 归属及当前范围筛选。
- 客户服务事项支持 11 类诉求入口、目标对象选择、方案、客户答复、专业岗接手、交接待接收、跟进及归档。
- 每位客户单独保存受理草稿；办理弹窗打开时阻止路由切换；关闭未保存的受理表单需确认放弃。
- 专业记录关联需同客户且明确引用原对象；核验源结果检查状态，不能通过备注直接完成退款或履约事项。
- 全局服务队列与客户服务轨迹共享本地事项数据；保留原有本地业务记录并增补客户归属，不自动重置。

### 观察范围与未完成事项

通过浏览器实际打开客户目录、客户总览、受理表单、咨询事项详情和资金分区；记录桌面及移动视口截图。本轮未运行完整业务测试或正式验收。

本次是信息架构及客服协作原型重组，不表示之前18组运营缺口全部关闭。源业务仍有以下限制：

1. 专业事项目前关联已有源记录；取消、换菜、新安排、分项售后尚未从服务方案自动生成完整执行链。缺少源记录时事项保持处理中。
2. 代填计划目前保存为服务方案，不自动生成可购买的结构化餐次；客户答复为原型演示登记，未接入真实小程序授权。
3. 岗位仍为经办/复核/只读三档演示，专业岗位身份及生产权限尚未实现。
4. 旧合成数据存在关联与区域不一致。按客户及区域取交集展示；不把旧错误关系静默当成合法证据。跨域原操作的审查缺口继续保留。
5. 预览数据存浏览器，不与小程序或后台服务同步；跨窗口提交核对版本，尚无服务端并发与事务保障。

恢复方式：保留 `site/` 上版作品；新代码集中在 `workspace-model.js`、`workspace-view.js`、`customer-ownership.json` 及 `app.js`/样式接入。无需修改或重置小程序数据。


## 全局管理结构调整（2026-09-29）

预览当前以全局经营概览为首屏；11个模块概览覆盖原82功能入口；客户总览直接呈现计划、订单、确认、资金、交付和售后。全局详情可下钻客户内的同一条记录，再返回全局；两层复用原业务处理函数。

不增加个人工作台、接待或交班模块。前文“受理服务”及以案件统领全部办理的描述只保留为早期方案沿革，不能作为下一轮顶层设计依据。历史服务记录仍可查看，但不是查看、管理订单或其他业务的前置条件。

审查、实际调整、定向证据与尚未完成项见[全局管理审查](../../../reports/review/ADMIN-2026-09-29-global-management.md)。