1. 文档目的

本文用于说明 Audlis 从下单到支付、从履约到物流、从异常到售后的完整业务流程。

这份文档的目标是：

• 让研发明确系统事实源和状态流转
• 让运营理解后台每个动作在流程中的位置
• 为后续售后、退货、评价、生命周期营销打基础
• 为写书提供可直接复用的业务链路材料

---

2. 流程总览

Audlis 当前采用的订单链路是：

1. 用户浏览商品并加入购物车
2. 用户进入结账并提交订单信息
3. 系统创建订单并进入支付流程
4. Stripe 支付成功后通过 webhook 确认交易
5. 系统触发供应商履约
6. 后续同步 tracking 信息
7. 记录 tracking events 与 shipping exceptions
8. 用户与后台都可以查看订单和物流状态
9. 如出现问题，再进入客服 / 售后 / 隐私 / 人工处理流程

---

3. 参与角色

3.1 用户

负责：

• 浏览商品
• 加入购物车
• 提交订单
• 支付
• 查询订单
• 查看物流
• 发起咨询或售后

3.2 管理员 / 运营

负责：

• 维护商品与价格
• 查看订单
• 查看履约与物流
• 处理异常
• 处理客户问题

3.3 支付服务（Stripe）

负责：

• 接收付款
• 支付状态确认
• 通过 webhook 提供权威支付结果

3.4 供应商 / 履约方（CJ Dropshipping）

负责：

• 接收履约请求
• 发货
• 返回物流信息

3.5 系统自身

负责：

• 持久化订单事实
• 串联支付与履约
• 对外提供订单与物流查询
• 标记异常并支持人工处理

---

4. 下单与支付流程

4.1 购物车阶段

用户在商品详情页或商品列表中把商品加入购物车。

当前购物车特点：

• 由前端状态管理
• 在浏览器中持久化
• 进入结账前不生成正式订单

这意味着购物车是“意向数据”，不是订单事实。

4.2 结账阶段

用户进入结账页后，填写：

• 联系信息
• 地址信息
• 配送相关信息

系统在服务端做以下事情：

• 校验商品和价格
• 计算订单基础数据
• 创建订单记录
• 进入 Stripe 支付流程

4.3 支付确认阶段

支付完成后，不能只依赖前端跳转结果。

真正的支付确认流程是：

1. Stripe 处理支付
2. Stripe 调用系统 webhook
3. 系统校验 webhook 签名
4. 系统更新订单支付状态

因此：

• 成功页只是用户体验上的“返回页”
• webhook 才是支付事实源

这是整个订单系统最关键的设计点之一。

---

5. 订单状态逻辑

当前订单至少包含两个层面的状态：

5.1 支付状态

例如：

• pending
• paid
• failed
• refunded

5.2 履约 / 物流相关状态

例如：

• 未创建 tracking
• 已创建 tracking
• in transit
• delivered
• exception

在系统设计上，支付状态和物流状态不能混成一个字段，否则后续运营和客服会非常混乱。

---

6. 履约流程

6.1 支付完成后触发履约

当 Stripe webhook 确认支付成功后，系统开始尝试进入供应商履约流程。

当前主要供应商是：

• CJ Dropshipping

这一步通常包括：

• 生成供应商订单
• 记录供应商订单 ID
• 后续准备 tracking 同步

6.2 供应商源信息的重要性

之所以系统保留 source_data，是因为：

• 商品可能经过本地二次编辑
• 但履约、源图、供应商属性仍需要回看原始数据

这在 dropshipping 系统里非常关键。

---

7. 物流同步流程

7.1 为什么不能只存 tracking number

如果只保存：

• tracking number
• carrier

那用户和后台看到的只是一个“物流编号”，并不能支撑客服和异常处理。

所以系统进一步引入了：

• order_tracking_events
• shipping_exceptions

7.2 tracking events

tracking events 用于保存物流时间线事实，例如：

• shipped
• arrived at facility
• customs processing
• out for delivery
• delivered

用户订单查询页和后台订单详情都可以消费这部分数据。

7.3 shipping exceptions

shipping exceptions 用于标记需要运营关注的异常，例如：

• 长时间未出 tracking
• 长时间无新物流节点
• 投递失败
• 运输异常

这使系统从“能显示物流”升级为“能运营物流问题”。

---

8. 用户查询流程

用户查询订单有两条路径：

8.1 账户内查询

已登录用户可在账户中心查看：

• 订单列表
• 订单详情
• 当前物流状态

8.2 独立订单查询

未登录或访客用户可通过订单页查询：

• 订单状态
• tracking 信息
• tracking timeline

这对跨境电商很重要，因为很多用户不会长期保留账户登录状态。

---

9. 后台处理流程

后台订单管理主要面向运营和客服，当前支持：

• 查看订单
• 查看支付状态
• 查看物流时间线
• 查看 shipping exception
• 在物流异常页集中处理问题

后台需要的不是“跟用户看到一样的页面”，而是“能帮助运营排查问题的事实面板”。

---

10. 客服与物流的关系

在实际业务里，订单、物流、客服不是三个独立系统，而是同一条服务链。

典型问题包括：

• 什么时候发货
• 为什么 tracking 没更新
• 预计多久送达
• 丢件怎么办
• 退货怎么处理

因此系统已经把以下能力串起来：

• 订单
• 物流事件
• 物流异常
• AI 客服
• Support Tickets

这条链越清晰，客服成本越低。

---

11. 异常处理与售后衔接

当前系统已经有以下异常与售后基础能力：

• shipping exceptions
• support tickets
• AI 客服转人工
• privacy requests
• returns / RMA 文档与数据层准备

这意味着订单系统已经不是“支付完成即结束”，而是具备向完整售后系统演进的基础。

后续最合理的扩展包括：

• 正式 returns / RMA 工作流
• replacement / refund 分支
• review request 触发
• delivered 后自动营销触发

---

12. 生命周期营销与订单链路的关系

订单不是运营终点，而是营销起点。

基于订单状态，可以触发：

• 弃购提醒
• 发货提醒
• 妥投提醒
• 评价邀请
• 复购推荐

因此订单、物流和营销系统必须共用同一套事实层，而不是各自维护一套“猜测状态”。

---

13. 当前流程中的关键设计原则

13.1 webhook 是支付事实源

不要信任成功页。

13.2 tracking events 是物流事实源

不要只信一个 tracking number。

13.3 供应商源数据要长期保留

不要把导入前的原始数据丢掉。

13.4 客服、物流、售后要用同一事实层

不要让每个模块自己维护一套状态口径。

13.5 前台与后台消费的是同一订单实体

只是视角不同，不应分裂成两套系统。

---

14. 当前流程仍待补强的部分

虽然主链路已经成型，但还有几块需要继续完善：

• 退货 / RMA 正式工作流
• 自动化通知更完整的覆盖
• 物流异常规则进一步细化
• 更清晰的退款与争议流程
• 更细的订单 / 履约 / 售后状态枚举管理

这些不影响现有系统成立，但会影响它从“可运营”升级到“成熟运营”。

---

15. 一句话总结

Audlis 当前的订单与履约系统，已经完成了从“下单收钱”到“支付确认、供应商履约、物流事实、异常处理、客服衔接”的关键跃迁。

这使它具备了成为完整跨境电商运营系统的基础，而不只是一个支付成功后就结束的网站。