H7.07.3refund progress tracking设计研究
进度需可追踪
别名: 退款进度 · 售后状态 · refund status
概念解释
申请交出去之后，人要能打开同一条售后，看见它现在卡在哪一步、这一步从何时开始、下一步是谁的动作。可追踪是状态机对外可见，不是再发一张「我们已收到」的永久票。时限告诉人最晚何时；进度告诉人此刻在哪。没有进度，时限只是墙上的日期。
机制
退款跨商家、仓、财务、渠道，人在外面只能看见沉默。沉默会被编码成「没在处理」或「钱丢了」，催单和拒付随之而来。把内部工单状态映射成少量外部阶段（待审核、待寄回、已收货、已出账、渠道处理中、已到账），人才能决定要不要行动——寄回要自己动，渠道处理中则不能催商家。阶段名必须和真事件绑定：财务没出账就不能写「已退款」。历史节点留下时间戳，人才能判断有没有停滞，而不是每次打开都只看到「处理中」。
怎么研究
做一条会在中途停留的退款（待寄回、待质检），比较无状态、只有「处理中」、分阶段带时间戳。看催单发生在哪些阶段。
自变量：阶段数量、是否显示责任方、停滞是否单独标记。 因变量：期内催单、错误催的对象（催商家而实际在银行）、能否指出当前步骤。
实验室压缩成几分钟，看不到隔日停滞。要用日记或隔日回访。不要把通知条数当进度——推送很多但状态不变，是噪音。
边界
渠道不回传入账事件时，最后一阶段只能停在「已发起退款」，并指引人去银行 App 核对，不要假装「已到账」。多件部分退货要逐件状态，整单一个条会撒谎。取消申请后进度应闭合为「已取消」，而不是消失导致人以为还在退。内部审核意见对用户不可见时，对外仍要有「需补充材料」这种可行动状态。
怎么落地
- 售后详情用阶段列表，当前步高亮，每步有开始时间；停滞超过自身时限则标记逾期。
- 需要用户动作的步骤（寄回、补照片）给出动作入口；不需要的步骤写清「无需操作」。
- 到账以渠道回传或人确认入账为准，未回传不标完成。
- 验证：走一笔待寄回的退货，隔日问「现在轮到谁、你要不要寄」。答不出责任方，或商家未出账却显示已退款，进度失败。