H7.12.2unified multi-channel order history设计研究
多渠道下单的凭证需要归集到统一的订单历史中
别名: 多渠道订单 · 订单归集 · omnichannel order history
概念解释
同一账号可能在 App、网页、小程序、门店 POS、电话下单。归集指这些单进同一个「我的订单」，用同一套状态与售后入口，而不是各渠道一份互不认识的列表。它不是发票和购物小票的区别，也不是某一张确认能不能改字——是人到哪里去找「我买过的」。
机制
人的记忆按「我买过」编索引，不按客户端编。拆开的历史迫使他们回忆当时用的是哪一端，回忆失败就去客服报一个可能属于别的渠道的号。门店小票若只存在于纸上，线上售后无法认领。技术上各渠道常是不同订单库，归集要有账号级的主键和冲突策略（同一支付意图不要显示成两单）。未登录门店单事后绑到账号，是归集的补救，不是默认。
怎么研究
让人在两个渠道各下一单，再只给一个客户端去找两单、申请其中一单售后。比较完全隔离的列表与账号级合并列表。
自变量：是否合并、门店单能否事后绑定、重复同步是否产生双记录。 因变量：找到目标单的时间、找错渠道、因找不到而进线。
实验室只用一个客户端，归集问题不会出现。至少要两个表面。不要把「订单总数对」当成功——可能对了总数但点开是重复行。
边界
不同法人主体的店铺（平台上的两家店）不应合成一个商家订单袋，但平台账号仍应有跨店的消费者历史。游客在门店付款、从未留手机，无法归集，只能凭小票号查询。合作渠道（外卖平台代下）若法律上是另一商户，归集要标明来源，不能假装是本店 POS。
怎么落地
- 登录用户的订单列表按账号合并所有自有渠道，每行标明来源（App / 门店 / 网页）。
- 提供小票号或支付号绑定到账号的入口；绑定后售后走同一套。
- 同步去重：同一支付意图只保留一条。
- 验证：网页下一单、App 下一单、用门店测试单绑定，在任一端的「我的订单」里三行都在且能进入售后。缺行或双行，归集失败。