处理「我的订单在哪」咨询：核实、解释与分流
这项任务从顾客询问订单位置开始。完成标准是：客服确认自己在向有权查询的人解释正确订单，能说明已知状态与证据，给出可用的自助入口或下一步；存在异常时，有负责人接手，而不是继续套用正常运输模板。
交付物是一份案例响应记录和分流清单。确认会或已经逾期后，转入处理一笔延迟订单落实主动告知与补救；本文不重复取消和退款操作。
1. 先核实查询资格，再查具体包裹
通过私密渠道取得定位订单所需的最少信息，并按店铺既定流程核实身份。优先使用已登录的订单入口或原订单通知渠道；订单号本身不是充分的身份凭据。信息不匹配时转人工验证，不透露“确有这笔订单”、地址或追踪信息。完整方法见客服渠道与服务水平。
确认顾客问的是整单还是某件商品：一单多个包裹时，把商品和数量对应到包裹。顾客称少收到一件，可能是尚未送达的另一包，也可能是真正缺件；在核对前不直接要求退货或判定丢失。
2. 并排核对付款、履约和追踪
Shopify 的订单状态说明分别维护付款与履约等状态，已付款不能证明发货，授权也不等于已收款。后台标记与支付、仓库、承运商证据不一致时，保留差异再调查，不用另一条状态掩盖。
| 检查对象 | 记录内容 | 不能直接推出的结论 |
|---|---|---|
| 付款 | 当前状态、对应交易与时间 | Paid 就已交给承运商 |
| 履约 | 哪些行、多少数量已处理，实际交接凭证 | Fulfilled 就全部送达 |
| 追踪 | 每个包裹的承运商、最新事件、事件时间与查询时间 | 有运单号就已揽收；Delivered 就无争议 |
| 原承诺 | 发货截止、送达范围、时区和日历 | 今天的新预计日期可以替换原陈述 |
UPS 的追踪说明区分 Label Created 与取得包裹后在网络中运输；长距离运输期间也可能直到目的地枢纽才再次扫描。因此“追踪没更新”本身既不能证明丢失，也不能证明一切正常，应对照交接、路线、原承诺和所用服务的规则。
3. 按证据分流，给出明确回复
下表是编辑整理的处理矩阵。升级时点应来自原承诺、实际异常与店铺已批准的检查规则，不使用一个适用于所有承运商的固定等待天数。
| 已核实的情形 | 回复必须说明 | 下一步与升级条件 |
|---|---|---|
| 未发货，仍在原处理窗口内 | 当前在处理、最晚发货点、届时去哪里查 | 约定复查点；确认无法按期时转主动延误处理 |
| 已建面单，尚无交接确认 | 面单已生成，但尚不能确认承运商取得实物 | 仓库核实交接；不能回复“包裹已经在路上” |
| 已交接，承运商显示运输中 | 最新事件及其时间、原送达范围、可用查询入口 | 超过承诺或出现异常事件时由物流负责人接手 |
| 派送中 | 当前是派送阶段，并非已经签收 | 按承运商信息说明收件安排，不保证未确认的具体时刻 |
| 投递未成功或地址异常 | 事件原文、需要核实的必要信息 | 私密核对后确认重投、自取或改址的实际可用性 |
| 显示送达，顾客称未收到 | 系统有交付记录，但顾客报告未收到 | 核对包裹与交付证据，交物流负责人调查，不能直接结案 |
| 不含追踪的服务 | 服务能力、已有交接证据及原预计范围 | 保留人工跟进；没有运单不能编造物流节点 |
| 分批发货 | 每包包含什么、各自进度，尚缺哪些商品 | 逐包处理，首包送达不等于整单完成 |
“已送达未收到”可在合适情况下请顾客核对其指定代收安排，同时由商家查交付记录；不公开签收照片或完整地址，不要求顾客自行追查陌生人的订单。是否丢件、谁能索赔和具体期限须按承运服务确认，不能由客服模板推定。
4. 用四项内容组织回复
每次回复至少包含：已核实状态、证据时点、顾客下一步，以及商家下一次更新的时间。缺少新信息时也说明还在核查什么，不把调查更新时间说成送达承诺。
下面是虚构的分包回复片段，只适用于身份已核实的私密对话；不是自动群发模板：
您订单中的手账本已显示送达；内页是另一包裹，目前只有面单记录，尚未确认交给承运商。该包裹原定最晚明天 17:00 发货。我们已请仓库核对，并会在明天 12:00 前按 UTC+8 时间更新结果。您可以从原订单通知进入状态页，分别查看两个包裹。
这段回复没有把第二包说成已发货，也没有承诺“明天收到”。如果仓库随后确认无法按原期发出，就转入延误任务，而不是等到回复中的更新时间才开始处理。
5. 检查自助入口是否真的可用
Shopify 的订单状态页支持多次履约，包括不同承运商，并为其分别显示区块；受支持与不受支持承运商的显示能力不同，不能保证所有服务都有实时地图。
在获准的测试环境，用测试订单验证下列情形；通知只发给测试收件人，不操作真实顾客订单。页面结构见订单追踪页面配方，邮件实现见通知与邮件。
| 用例 | 验证结果应回答的问题 |
|---|---|
| 从订单通知进入 | 链接是否指向正确订单，顾客能否找到进度 |
| 需要重新验证身份 | 是否有可用的验证或人工求助路径，没有泄露其他顾客资料 |
| 一个订单两个包裹 | 商品、数量、承运商与进度是否正确对应 |
| 无追踪或不支持实时更新 | 是否如实解释能力，仍有联系入口 |
| 自定义过通知模板 | 实际邮件中是否仍有有效入口，不能只看模板预览 |
不要为了补一个链接就直接恢复默认模板，覆盖其他已确认的内容。若测试需要改配置，先保存原版本，按平台实现核对影响，再运行相关用例。没有完成这些测试时，记录未测项，不以官方支持某功能代替本店已经可用的证据。
一份可复核的响应记录
以下案例均为虚构，只演练分流，不代表真实发送或运输结果。每条还应在内部记录身份核验方式、证据引用与实际回复时间，公开样例只保留脱敏编号。
| 案例 | 核实结果 | 响应与去向 | 本次完成边界 |
|---|---|---|---|
| Q101 | 已付款、尚未发货；原处理窗口未结束 | 解释处理进度，给出原发货点与自助入口 | 查询得到解释；到期前若出现风险继续跟进 |
| Q102 | A 包有送达记录，B 包只有面单；B 尚未超过原发货点 | 逐包解释，请仓库核实，约定下一次更新 | 等仓库回复，不能标记问题已解决 |
| Q103 | 已交接，但预计无法按原送达范围交付 | 说明变化并交延误负责人制定补救 | 查询已分流，延误案例继续开放 |
| Q104 | 承运商记录送达，顾客否认收到 | 记录争议，核对交付证据并升级物流调查 | 未判定丢件，未擅自退款或结案 |
完整记录应能回答：顾客问了什么，客服依据什么回答，哪些仍未知，谁接手以及何时再回复。转交后由接收人确认，不把“已转相关部门”当成责任已经交接。
按问题归因，反馈给真正的负责人
把找不到入口、未发货询问、分包误解、运输异常、送达争议分别统计。一个顾客就同一订单的同一问题发了三封邮件，应保留三次接触记录，但在“独立问题数”中按既定口径去重；不能用消息条数代表受影响订单数。
入口问题交内容与页面负责人，原承诺表达不清交运营，实际延误交履约，反复的交付争议交物流负责人。改动后复查相同口径的案例与证据，不把客服回复变快直接解释为配送变快。