客服工作故事与端到端动线

日期：2026-09-29 · 状态：设计提案，尚未完整实现。使用者包括兼具客服与管理职责的工作人员；故事仅用于具体功能设计。

1. 设计依据与问题定位

依据：运营支撑审查的 J01–J36 / G01–G18、交易严谨性、逐日安排状态职责、现有工作区。当前业务架构含候选政策，不把架构提案当正式运营授权。

现有 stories.md / flows.md 是领域能力和局部操作目录：大部分终点为“记录可查”，不足以指导客服完成接待。当前 Workspace 又将这些能力按客户分组，仍要求客服自行判断、跳页、选择业务对象、手工关联执行结果。本次补充操作场景，作为具体功能修订输入；系统组织方式仍以全局经营管理为准。不能因为写完本文件，就把审查缺口记成完成。

产品目标：以全局管理能力完整支撑小程序运营，并在具体客户及业务对象上提供顺畅、受控、可恢复的操作。

客观限制：尚无真实客服访谈、班次样本、工单统计及已批准职责矩阵。以下为基于业务文档的场景推导，频率、优先级阈值及操作时长不冒充实测。设计维护由主会话负责；运营主管、资金、履约、质量和隐私责任人的实际人员待指定。

2. 固定的系统组织原则

本系统为支撑小程序运营的统一管理后台。顶层固定为完整的全局经营管理视角；下钻单个客户后，集中查看和操作该客户相关业务。权限控制可见数据、可执行动作及必要复核，同一人员可以兼具客服与管理职责。

不设计“我的工作”、接待台、接待生命周期或交班模块；不按个人一天的工作组织首页和导航。客服故事只检查具体功能能否办完、操作是否顺畅、异常是否有出口，不推导独立的客服系统或额外管理系统。

全局与客户层复用同一业务对象、办理能力、权限及回执。管理者可在全局直接处理批次、配货、商品、资金和异常，不要求所有操作先选择客户或创建服务事项。

3. 功能操作动线的检查方法

flowchart TD
 G[全局经营管理] --> B[客户 / 订单 / 配货 / 资金 / 质量等业务视图]
 B --> A[全局对象或批次直接管理]
 B --> C[按需下钻单客户及具体对象]
 C --> D[核对事实与可操作范围]
 D --> E[填写目标 / 核对影响 / 必要授权与复核]
 E --> F[执行业务动作 / 查看分项结果]
 F --> R[失败恢复 / 原请求查证 / 继续处理]
 R --> F
 F --> B
 A --> B

每项功能必须明确：入口与目标、前置事实、允许操作、具体输入、影响预览、提交与回执、拒绝/失败/未知/部分完成的处理，以及返回来源视图的路径。全局与客户层显示同一结果；返回保留筛选、业务日期和定位。

权限不足时展示可适用的审批或有权岗位处理路径；相关责任保留在原业务对象中。不为实现这些约束增加独立的接待或交班体系。查询无需创建工单，取消、退款、售后等使用其本来需要的业务申请和记录。

4. 客服故事库存

每条故事都应用第3节的身份、权限、版本和恢复规则。下表及后续展开是一个设计库存；验收状态统一为“设计待原型实现”，不代表已有能力。

CS-01 全局经营检查与异常定位

作为具有管理职责的工作人员，我需要从全局查看经营进展和未完成业务，以便发现问题并在对应对象上处理。

动线：全局概览 → 按日期/区域/状态查看订单、配送、资金及异常 → 打开具体对象或批次 → 核对来源与已有处理 → 执行获准操作 → 返回原列表核对结果。个人负责人仅是可用筛选条件，不改变全局结构。

终点：异常对应明确对象、源状态、可执行动作和处理结果。未配置时限不伪造超时；自动流程正常推进，工作人员处理例外。

CS-02 客户定位与已有处理续办

作为工作人员，我需要从全局客户或业务记录准确找到客户及已有处理，以便避免误操作和重复申请。

动线：客户/订单等全局视图 → 姓名、脱敏联系点或业务编号定位 → 区分同名客户 → 按动作要求核验身份与权限 → 下钻客户或直接打开业务对象 → 查看现有申请 → 继续办理或发起不同范围的操作。

终点：客户、业务对象及操作范围一致。无匹配保留查询条件并提示补充线索；不能猜测归户。权限不足走受控处理路径；已有写入不能通过改客户标识掩盖误操作。

CS-03 解释“付了钱为什么没送”

作为客服，我需要把某一餐的付款、客户确认、商家接受和配送事实放在一起，以便给出准确解释和可行下一步。

动线：来访 → 选择日期/餐次 → 并列核对四条事实 → 区分未确认、确认结果未知、已接受但未派单、已出发 → 解释并选择后续。未确认给确认入口；已到期走CS-07；已接受未作业走CS-17；部分交付走CS-13。

终点：解释有来源；客户若只咨询可结束接待，有后续承诺则建立事项。源加载失败不解释为未付款；提醒送达不算确认。

CS-04 协助编排餐次与菜卡

作为客服，我需要替不熟悉操作的客户填写具体餐次草稿，并让客户核对内容，以便减少操作负担而不替他做购买决定。

动线：选择未购餐次/菜卡 → 填商品、规格、切法、份数、日期 → 系统核对商品有效性及估价 → 展示改前/改后 → 保存结构化草稿 → 客户核对 → 引导合法购买。计划、菜卡、已购餐次三个影响范围分别选择。

终点：客户能查看同一版本草稿并继续购买；客服看到接受/拒绝/待答复。缺货或规格失效先给替代选项；已购部分走CS-10；草稿不占用付款或授权配送。客户失联保留草稿及跟进，不生成订单。

CS-05 协助联系点、地址与偏好更正

作为客服，我需要明确客户改的是以后默认资料还是已成交的这次配送，以便不会让客户误以为明天已改成功。

动线：选择资料范围 → 核验受托依据 → 填写新值并展示差异 → 保存获准资料 → 列出受影响的在途安排 → 逐项申请CS-09或明确保持原地址。

终点：资料修改回执与在途变更结果分别可查。非服务区域拒绝配送目标并提供合法选择；隐私更正转CS-21；不可批量覆写历史成交快照。

CS-06 协助每日确认和费用解释

作为客服，我需要确认这次安排是否被权威接受，并帮助客户完成获准步骤，以便不会把选时间或已交费误报成确认成功。

动线：打开本次安排→核对付款核验、订单成立、截止快照及合法时段→核对范围、地址、期望时间→展示有效报价及免费条件→引导客户自助确认→跟踪费用目标及安排接受。付款后即可提前确认多日，已确认无需每日重复；默认配送日北京时间16:00起拒绝新确认，自动到期取消。D-06未批准不开放受托确认，员工说明不能代替授权。

终点：接受后可查对应授权版本；拒绝时解释实际原因。报价跨档/过期重新核对；收费成功但接受失败进入补偿事项；确认/到期竞争查原结果，不能手填接受时间。特殊授权方式未批准时等待政策或使用已批准渠道。

CS-07 不送后请求重新安排

作为客服，我需要为已到期但又希望配送的客户找到合法新安排，以便继续服务并保留旧决定。

动线：查旧安排终点 → 选择新日期/时段 → 核对当前供给、订单及原款可用性 → 形成新目标/必要新单 → 客户接受费用及内容 → 提交并跟踪承接。

终点：旧记录保持终态，新安排结果可查。无能力给替代时间或退出；原款退款未知先查证，不承诺只付差额；迟到旧确认不得激活配送。

CS-08 取消指定餐次或数量

作为客服，我需要只取消客户明确指定的范围，并分别核实停止与钱款处理，以便不会误停整周或过早承诺退款。

动线：选餐次/订单行/数量 → 查执行进度 → 预览取消影响 → 取得适用依据 → 提交唯一协调请求 → 跟踪停止、商业关闭、资金分配/退款 → 告知分项结果。

终点：选中范围合法处置、其他安排保留、资金去向明确。开工先发生转受控部分处置；停止未知保持跟进；客户撤回意愿时重新判断已发生事实，不能直接恢复旧终态。完整屏幕动线见第5节A。

CS-09 更改本次地址或时刻

作为客服，我需要知道在当前执行阶段还能改什么，并得到调度接收回执，以便避免口头答应后司机仍送旧地址。

动线：选一次安排 → 录新目标 → 核对覆盖范围/能力/费用及当前执行 → 展示差异 → 取得新授权 → 提交变更 → 核对旧执行停止/新承接 → 向客户交代。

终点：当前有效安排和旧记录明确。已出发、范围不支持、费用变化或版本冲突需重新给方案；地址簿修改不代替本次变更，调度未接收不显示已改妥。

CS-10 已购换菜、改量与缺货替代

作为客服，我需要提出客户能接受且只执行一次的替代方案，以便处理临时变化而不造成双做、双收或错误补差。

动线：原餐次 → 选替代商品规格数量 → 核对供给及报价 → 展示原款可用部分/差价/费用 → 客户接受 → 请求旧执行永久停止 → 原单关闭及合法后继 → 补款/分配核验 → 新内容授权 → 跟踪新承接。

终点：新旧谱系和钱款逐项明确；“替换完成”与“新餐已送”分开。拒绝替代不强行换货，进入取消或其他选择；旧单已关闭而补款/新单失败保留停止，转补偿；便宜差额按批准政策结算，不变成通用钱包。

CS-11 查询扣款、退款未知或失败

作为客服，我需要沿原资金目标查到可信结果，并在未知时保留责任，以便客户不会因再次催问而被重复收退。

动线：从客户事项选原款/退款 → 展示金额、目标、尝试及最新来源 → 发起查询 → 按成功、确定失败、仍未知、相反证据分别处理 → 专业核验/受控重试或升级 → 告知当前结论与下次跟进。

终点：成功有同目标可信回执；未知仍有责任和下次动作。失败不由客服直接改成功；确定失败后的释放或重试由资金权限决定；人员变化后仍沿原目标续查。完整屏幕动线见第5节B。

CS-12 解释资金、称重差额与剩余安排退出

作为客服，我需要把客户一次购买的钱逐项解释，并发起合法范围退出，以便能回答“还剩多少、为何没退、接下来怎么办”。

动线：购买批次 → 原款分配与餐次消费明细 → 核对称重/优惠/配送费依据 → 选择退出范围 → 逐项停止与结算评估 → 跟踪结算/退款 → 汇总说明。

终点：实收、占用、消费、待结算和退款有来源，不把余额全部叫可退。政策齐备的正常结算由系统推进，异常由有权岗位接手。实际重量计价已定；D-04的超重、舍入、优惠/费用分摊及应收确认时点未定，缺规则保持待核算。D-05未决，不默认暂留、余额、即时退或整批结束退，不承诺金额/到账日。结清后晚到事实进入独立调整。

CS-13 延误、失联、拒收、错送与部分交付

作为客服，我需要按包裹和实际数量判断发生了什么，以便制定不会重复配送的补救方案。

动线：异常或来访 → 选择此次交付及包裹 → 核对轨迹/交接/签收与客户描述 → 请求现场查证 → 分离已交与未交范围 → 提议继续送达、重新安排或售后 → 客户接受必要变化 → 分项执行。

终点：各范围真实结果及剩余责任可查；部分送达不能整单补送。失联保留合法联系尝试及调度处置；错送涉及其他客户信息时最小披露；现场不明先查证，不凭司机备注强制全部送达。

CS-14 少件、品质、重量或切法售后

作为客服，我需要一次受理就能推进退款、补送和必要回收，以便不用叫客户分别向多个岗位重复说明。

动线：选择受影响商品行/数量/包裹 → 收集问题与证据 → 核对已有售后和可处理范围 → 方案及必要裁决 → 客户接受适用方案 → 自动派生退款/补送新目标/回收任务 → 跟踪分项 → 告知。

终点：批准方案不等于执行完成；所有必要义务各自有结果。缺证可补充；重复申请续办；退款完成但补送未完成仍跟进；通知失败不重复退款。完整屏幕动线见第5节C。

CS-15 批次质量事件及跨客户影响

作为负责事件跟进的客服，我需要从统一事件领取受影响客户，并逐客记录联系和处置，以便召回不会漏人也不会重复办理。

动线：质量岗确定事件范围 → 全局影响名单 → 去重认领 → 下钻客户及对应包裹 → 告知风险与已批准方案 → CS-14 → 回到事件查看未联系/等待/部分完成。

终点：全局事件与逐客事项双向可追踪。客户不接受或失联保留义务；名单更新有增量任务；客服不解除质量隔离，不向一位客户展示其他人的资料。事件关闭由质量/责任岗位判断，不由“已群发”决定。

CS-16 到货、缺货、备货变化和鲜讯更正

作为客服，我需要知道经营变化影响哪些已承诺安排及已告知内容，以便主动解释而非照旧承诺。

动线：运营发布有依据的到货/供给异常 → 系统给受影响餐次及通知内容 → 认领客户 → 区分只是草稿、已购未确认、已接受 → 对应告知、替代或改期 → 跟进结果回流。

终点：每位受影响客户有处置状态；鲜讯更正与告知记录可查。客服只提交经营纠错，不自行发布到货事实或修改库存。日末余料问题交供给岗位；已购客户不能因“按需备货”文案被自动取消。

CS-17 自动流程漏办与现场事实不明

作为值班客服，我需要发现已接受却未作业、到期未处理或现场回执丢失的事项，并让有权岗位恢复，以便客户不必自己监控系统。

动线：业务异常队列 → 查看源时点、自动尝试、影响与现负责人 → 去重认领 → 发起限定范围查证/恢复 → 专业岗接受 → 核对业务结果 → 必要时告知客户。

终点：原目标恢复或合法处置有回执；技术任务成功不能代替业务完成。正常未到期的待确认不报警；重复补扫不产生重复任务；现场已切但缺回执先隔离查物，不再切一份。客服不能手选“门禁齐全”。

CS-18 提醒、联系偏好与告知失败

作为客服，我需要尊重客户联系意愿，并区分通知失败和业务失败，以便跟进有效又不过度打扰。

动线：待联系事项 → 查用途授权及可用渠道 → 打开与当前对象绑定的内容 → 发送或登记获准联系 → 查看送达/失败 → 失败选择允许的替代渠道或待跟进。

终点：实际告知结果记录；送达不等于客户接受方案。退订按用途生效；旧链接打开当前有效版本或解释失效；仅通知失败不重新执行业务。客户完全无法联系时主管处置未尽义务，不自动视为同意。

CS-19 多次催问、并行处理与方案反悔

作为客服，我需要接续别人正在办理的同一诉求，并知道客户改变意见时哪些操作已不可撤回，以便避免重复操作和相互覆盖。

动线：来访定位 → 显示现有事项与经办状态 → 追加接待 → 读取当前版本 → 修改未提交草稿或提交新变化请求 → 再核对影响及授权。

终点：多个接待共享原业务目标；并行提交返回现有结果或冲突并定位变化字段。已执行部分不可因客户反悔删除；撤回仅结束未执行请求，退款/停止在途保持责任。

CS-20 未完成业务的持续处理与结果核验

作为工作人员，我需要在全局和客户视图看到同一业务的未完成步骤，以便任何获准人员都能依据现有记录继续处理。

动线：全局异常/业务列表或客户业务分区 → 打开原申请 → 查看已执行、未执行和未知步骤 → 按权限继续、提交必要复核或查证原请求 → 核验各项业务结果。

终点：源结果决定是否完成；部分成功继续保留未尽义务。人员变化不删除记录或重复创建业务目标；没有可执行权限时保留明确的专业处理出口。该故事不新增交班流程或个人工作台。

CS-21 隐私、账号受限与资料纠错

作为客服，我需要在保护客户资料的同时继续处理已有退款和交付义务，以便账号限制不会变成拒绝服务的理由。

动线：身份及用途核验 → 区分更正、用途限制、注销或疑似重复账号 → 检查在途义务 → 转交有权资料岗位 → 最小范围继续服务 → 向客户说明已生效与待处理部分。

终点：限制与义务同时可查。客服不自行合并身份/转移原款；证据冲突保持待查；无法核验身份允许通用咨询并给合法恢复路径。留存期限及替代核验政策未定，不擅自删除证据。

CS-22 权益、积分、推荐与活动疑问

作为客服，我需要分清客户实际获得的权益与原型展示内容，以便能解释资格、使用或退回，并把政策不明问题交给运营裁决。

动线：选择权益/活动及关联购买 → 核对适用规则版本和取得/使用记录 → 解释或申请有权纠正 → 运营裁决 → 核对资金/权益结果 → 告知。

终点：有明确规则才执行调整；没有规则则登记范围与政策责任，禁止客服自行加积分、发补偿券或把演示推荐当经营承诺。

5. 三条屏幕级完整动线

以下示例是设计样本，不复用旧原型中存在错链的金额。凡列“系统生成”，都是下一版应实现的行为，当前通用表单不能算满足。

A. 取消明晚的一餐，尚未开工

B. 退款仍未知，从全局资金管理查证并持续处理

C. 一件少送，客户接受补送；另一件质量问题需退款及回收

6. 故事如何改善现有管理功能

6.1 全局管理结构

顶层覆盖经营概览、客户、交易与订单、需求与配货、履约配送、商品与内容、供给与质量、资金与财务、分析和系统治理。具体分组与架构模块对应，同一套导航体系按权限呈现可访问能力。全局概览显示授权范围内的整体经营，不默认只显示本人负责的数据。

6.2 客户下钻结构

单客户工作区保留计划、订单、配送、资金、售后、资料和记录等管理分区。从哪个全局对象进入，就定位到对应客户及业务；操作面携带客户和精确对象，返回原视图保留条件。跨域查看期间保存当前操作的合法草稿和来源，不强制以服务案件作为所有操作的容器。

6.3 专属业务操作

取消选择餐次、商品行及数量；改址填写目标地址并展示影响；换菜选择商品规格及报价；售后按行制定退款、补送和回收方案。各动作直接复用所属业务能力，自动携带来源关系。全局和客户视图调用同一操作，不各写一套流程。

6.4 异常与权限

来源缺失、资金未知、部分执行、权限不足和版本冲突必须在对应业务操作中给出原因与下一步。需要专业审批时关联原业务申请；全局管理可查询其进度。业务完成依据源结果，不能通过通用状态选择器或备注宣告完成。

7. 覆盖、反例与完成标准

7.1 既有36项审查的客服落点

CS故事覆盖客服对这些结果的服务责任；不据此宣布仓配、财务、商品等岗位自己的完整用户故事已经完成。

7.2 每条故事必查的反例

• 正常成功；客户拒绝/无回复；政策不允许；缺证/来源不可用。
• 经办无权、跨范围、提交前撤权；复核身份不能用切换下拉框冒充真实独立人员。
• 重复来访/点击、多人并发、旧版本草稿、跨客户/跨页签误操作。
• 部分执行、请求已发出但响应丢失、明确失败、仍未知、迟到或相反证据。
• 专业处理受阻、人员变化、责任缺失；通知失败和业务失败分开。
• 旧数据无客户归属/错误关联应隔离核对；升级保留原事项和原请求，回退不回滚资金/实物事实。

完成反证：如果客服还要手抄ID、自己拼四个模块才能知道下一步、把另一条已完成记录关联为本次证明、未完成业务只能“关单”或“无限等待”，该动线仍不完整。

7.3 原型交付的判定方式

对CS-01–22逐条记录：设计屏幕、正常路径、拒绝路径、未知/部分路径、权限/并发路径、持续处理及客户结果、实现文件与证据、未决政策。没有证据记未实现/未验证，不用目录数量作替代。

每条动线须从全局业务视图、客户业务分区或具体异常开始，由操作产生真实关联对象，禁止只浏览预制完成样例。观测目标为：可定位、可决策、可推进、可恢复、可持续处理、可解释和有据办结；时长及点击次数先记录后优化，不捏造KPI。

8. 实施依据与范围修正

系统信息架构以 WORKSPACES.md 的全局管理与客户下钻为准。本文件只为具体功能提供操作场景，不以故事顺序排列导航，不据此新增个人工作台、接待或交班模块。

1. 按架构模块建立全局功能、客户下钻功能、权限和共享业务能力的对应关系。
2. 用本文件的操作故事逐项检查字段、关联、正常路径、拒绝及恢复出口。
3. 补齐取消、变更、资金、售后等跨域业务动作；从真实新申请产生关联目标，避免手抄编号。
4. 全局与客户视图核对同一结果；保留原有查询条件、历史记录和原请求，异常数据显式待核实。

本轮修正设计文档，未修改产品代码，不声明已有原型满足全部业务闭环。