Fancy 跨平台 SaaS 支持不同平台订单关联客户吗

先回答这个问题：能，而且是按"人"来关联

经常有人在后台问我们同一句话：你们这套系统，能不能把不同平台的订单算到同一个客户头上？

能。这是 Fancy 从一开始就在做的事，不是后来补的功能。简单说，我们的做法是先把订单拆成"商品明细"，再把明细归到"客户档案"上。订单来自哪个平台只是它的一个属性，不影响它最终落在谁的名下。

下面把我们内部怎么想这件事、系统怎么实现、你们可以怎么用，一次讲清楚。

为什么要做"订单归人"，而不是"订单归平台"

大多数商家一开始是这样看数据的：淘宝一个后台，抖音一个后台，线下门店一套 POS，微信私域又一本账。每个后台都长得很合理，但拼在一起就对不上——同一个人在三个地方下过单，在三个报表里是三个陌生人。

我们做 Fancy 的时候，判断这是一个会长期存在的问题。平台的边界会变，渠道会起落，但"这个客户买过几次、花了多少、喜欢什么"这类信息，是商家真正攒得住的资产。所以系统底层是以客户为主键的，订单是挂在客户下面的记录。

不同平台的订单，具体怎么关联到同一个客户

我们用的是分层识别的办法，不依赖某一家平台是否开接口，也不强求客户在每个渠道留同样的信息。

三级都跑完之后，一个客户档案里可能同时挂着天猫订单、小程序订单、门店小票，甚至一条售后工单。系统会保留每条记录的原始来源，谁也不会被"洗掉"，但统计口径是合在一起的。

合并之后，一个客户档案里有什么

• 订单时间线：按时间顺序排好，能看到第一次在哪买、最近一次在哪买，中间隔了多久。
• 渠道占比：哪些来自线上、哪些来自门店，方便判断这个人更习惯哪种购买方式。
• 商品偏好：同一个 SKU 反复出现，或者不同渠道买的是互补品，都能看出来。
• 服务记录：退换、咨询、投诉，统一挂在客户名下，客服不用再翻几个后台找上下文。

这些字段本身不复杂，价值在于它们是同一个人的完整记录，而不是拼图的一角。

这套关联在真实业务里解决什么

我们说一个具体的场景。一家做家居用品的品牌，线上有天猫店，线下有十来家门店。有位客户先在门店买了一套餐桌椅，三个月后在天猫补了两把单椅，再过半年多了个售后——椅脚有点磨损。

如果订单按平台分开存，客服看到售后单时只知道"这是天猫的两把单椅"，不知道这位客户在门店买过整套，更不知道他是老客户。关联之后，接单的人一眼就能看清楚来龙去脉，处理方式自然不一样。

同类的事情每天都在发生：会员权益跨渠道能不能用、导购的业绩怎么算、复购提醒该发给谁、老客户回门店有没有人认得出来。这些问题在数据没打通之前，只能靠人记住；打通之后，交给系统。

我们做这件事时的几条底线

数据以商家自己的账号为主体。订单和客户资料存在商家自己的空间里，平台授权只是读取通道，不会替你产生第二份数据。

宁可不合并，也不乱合并。识别置信度不够的时候，系统会停下来问人，而不是自作主张。客户档案一旦合并错了，后续补救的成本高于当初多确认一步。

平台再变，结构不变。今天接的平台，明天可能规则调整，但客户档案的字段和时间线是稳定的。换渠道不意味着重建一次数据。

判断一套系统是否真的做到关联，看这五点

1. 看主键是谁。客户档案能不能独立存在，还是必须依附某张订单？
2. 看合并规则能不能查。系统告诉你"这两个是同一人"，你能不能看到它凭什么这么判断？
3. 看能不能拆。合并错了能否撤销，原始记录是否完整保留？
4. 看线下有没有份。只接电商后台的系统，线下客户永远是黑盒。
5. 看客服能不能直接用。关联的结果如果只躺在报表里，一线人员用不上，等于没做。

如果你正在被这个问题困住

你可以先做一件很轻的事：挑十个在多个渠道下过单的老客户，手动对一遍他们的消费记录。如果这件事花掉你半天，那多半说明你的数据还是按平台存的。

Fancy 做的事情说穿了很朴素——让每个走进来的人，不管你从哪个门进来，我们都能认出你，也记得你上次买了什么。这是我们做这套跨平台 SaaS 的原因，也是我们一直在维护的东西。