每一个 B2B 电子商务项目都会迎来一个时刻，通常是在开始三周后，人们突然意识到客户主数据将比店面本身带来更大的麻烦。即使是最优秀的团队也会遇到这种情况。平台迁移的提案幻灯片谈的是界面、移动端、搜索和 AI，而真正的拦路虎却是：同一个客户在 ERP 中以略有差异的名称存在了三次，而且每一个重复记录都对应着一套不同的定价协议。
本文介绍的，正是我们如今在编写任何店面代码之前、于每一个项目上执行的流程。这是无人评估、却人人都会以某种方式付出代价的工作。
为何店面会让问题更严重
在只有 ERP 的世界里，遇到客户重复记录的应收账款文员只需随手选一个继续工作即可。多年来，人工默默地消化着各种数据质量问题。而一旦你把自助式 B2B 店面摆在这些记录面前，每一处缺陷都会变成面向客户的故障：
- "为什么价格和我的业务代表报的不一样？" → 两条记录，两套定价协议。
- "我的订单历史是空的。" → 他们看的是重复记录 #2，但下单是针对重复记录 #1。
- "为什么我的账户突然被信用冻结了？" → 应收账款冻结的是 #1，店面看到的却是 #2。
- "我上个月的收货地址在哪里？" → 它存在第三条无人知晓的重复记录上。
我们总会发现的五类问题
- 重复记录。同一个法人实体存在 2 到 N 次。这往往是多年间不同业务代表通过不同的区域或产品线录入同一客户而逐渐形成的。
- 收货方与开票方关系不一致。有些客户的所有收货地址都挂在同一个母公司之下；另一些则按地点分设独立的顶级客户记录。ERP 未必会强制执行一致的模式。
- 过时的分配关系。早已离职的业务代表、五年未审核过的付款条件、映射到已停产产品线的客户类别。
- 藏在字段里、无人记录的隐性业务逻辑。"客户类别 = X 意味着我们通过 FedEx 发货。" 这种逻辑只存在于某个人的脑子里，而非 ERP 的配置中。
- 未被执行的免税证明。证明放在文件柜里，ERP 的客户记录却对此一无所知，于是店面会在本不应收税的州照样收税。
我们执行的流程
第一阶段：提取与剖析（第 1 周）
拉取每一条客户记录。我们暂时不关心定价细节，我们关心的是身份识别。提取内容包括：客户 ID、法定名称、商号 (DBA)、主地址、主联系人、创建年份、最近下单日期、业务代表分配、母公司 ID（如果存在层级关系）。再将其放入模糊匹配（我们采用名称的 token-set ratio 与地址的 Levenshtein 距离相结合的方式，随后进行人工审核）。
第二阶段：呈现重复记录报告（第 2 周）
把重复候选记录交回给应收账款与销售运营团队。他们的反应会告诉你项目的实际范围。如果回应是"对，这些就是我们早就知道的，我们会合并它们"，那你就处境良好。如果回应是"等等，我没想到 Acme Manufacturing 竟然有三条记录，让我问问 Bob"，那你就发现了一长串无人评估过的项目工作。
第三阶段：层级关系与收货方规范化
选定一种模式：母公司客户加子级收货记录，或者使用共享开票地址的扁平客户结构。两种都行得通。错误的答案是"我们让它两种方式并存"。把它记录下来，编写一个小型迁移脚本，然后运行它。
第四阶段：补全与校验
补充店面需要、而 ERP 未曾强制要求的数据：网站用户邮箱、按收货方划分的角色分配（采购员、审批人、应付账款），以及免税标志。这也是发问的好时机："那些三年都没下单的客户 X，业务代表是否还应该看到？" 软归档能化解大量的杂乱。
第五阶段：锁定与重新测试
一旦清理后的记录部署完毕，就编写集成测试来验证最基本的几点：每个活跃客户都恰好有一条主记录，每个收货方都从属于某个客户，每个客户都至少有一个有效联系人。在每次发布之前都运行这些测试。
如何在提案中为其估算工作量
把它框定为 B2B 平台迁移项目总预算的 10% 到 15%。在你尚未吃过它的亏之前，这听起来似乎偏高。我们宁愿把它明确列出来，也不愿任由它渗透到其他每一个项目条目中，最终演变成 “这个项目为什么会延期？”
由谁负责
这项清理工作主要属于业务工作，而非 IT 工作。合适的团队是你的应收账款负责人加上销售运营负责人，由我们提供脚本、重复检测工具和测试框架。如果客户方团队从第一周起就投入其中，这件事就能按时完成。如果他们到第十周才被拉进来，项目就会延期。
如果你正在评估一次 B2B 平台迁移，而客户主数据已经五年没有审计过，那就在你着手评估店面之前先与我们聊聊。顺序至关重要。