一家批发集团把某区域客户从甲公司调整为乙公司供货。客户最关心的是明天能不能照常在手机商城找到常买商品、按约定价格下单、收到货；财务最关心的是上月甲公司形成的欠款和本月乙公司的新订单不能混在一起。若运营只复制客户资料、通知“以后找乙公司”，客户可能在旧入口继续下单，也可能把欠甲公司的钱付给乙公司。若财务为了让报表好看，把旧余额直接写进乙公司的客户账户，销售、合同、发票和收款主体就会脱节。集团内两家公司可以共享管理视角，但对客户的每笔交易必须清楚写明是谁销售、谁发货、谁收款、谁负责退货。
这不是把客户从一个名单移到另一个名单的后台操作，而是一次有截止时点的经营交接。较稳妥的做法是把迁移对象、未完订单、往来余额和首笔新单分别列清：甲公司负责关好旧业务，乙公司验证新业务，客户只需理解一个明确的切换规则。本文以同一集团内两家实际经营企业为例，说明业务和系统如何配合；具体债权转让、合同变更和税务处理应由企业对应负责人及专业人员确认，不能由系统配置代替。
先盘原企业未完业务，决定哪些不能跟客户资料一起搬
迁移前从甲公司的客户、订单、出库、退货、收款和发票记录建立一张交接底账。把待审核、待出库、部分送达、客户已签收但尚未对账的订单分开；同一客户的应收欠款、预存款、待核销收款、未处理退货和售后赔付也分开。清单至少写原始单号、业务日期、金额或数量、当前状态、甲公司责任人、客户联系人以及预计完成时间。集团汇总报表可以显示两家公司合计的经营状况，但不能用汇总数掩盖哪家企业对哪笔交易负责。
例如客户有三笔交易：甲公司上月已送货尚欠两万元；本周一的订单只送了部分商品；本周五计划由乙公司接新的采购。第一笔仍按甲公司原合同催收与核销，第二笔先决定由甲公司补送还是双方经确认后取消余量重下，第三笔才由乙公司开新单。不能把第一笔欠款当作乙公司的客户授信，也不能为了“切得干净”在乙公司复制第二笔原订单，然后让甲公司的未发余量长期悬空。迁移清单由销售、仓配、客服和财务共同签收，老板或经营负责人对例外处理给最终决定。
图1：以切换日为界区分甲公司的存量责任与乙公司的新增业务；跨越切换日的部分履约订单须逐单决定处理方式。
确定迁移范围和生效日期，把边界告知客户
迁移可以先从一个区域或一类客户做，不必一夜之间切换全集团。列出客户编号、经营门店、可售品类、服务区域、负责业务员和原供货公司；逐户决定是整户切换、仅某品类改由乙公司供货，还是暂缓切换。客户如果同一门店同时向甲、乙采购，系统里需要区分商品或订货入口、报价和订单归属，不能只用“这位客户已经迁移”一句话覆盖所有业务。生效时点最好与客户常用下单、配送及对账周期相配合，避免在订单审核或送货途中临时倒改主体。
对外通知不应只有一句“以后由乙公司服务”。客户需要看见乙公司的名称、合同或交易条款变化、收款账户、开票信息、售后电话、配送承诺与新入口开始使用时间。客户最容易误解的是历史欠款：通知中要写明“切换日前甲公司的订单与未结款继续按甲公司原记录处理；切换后乙公司新单按乙公司的规则处理”，并给两边对账联系人。客户确认记录应与具体生效日期绑定。若旧合同要求双方同意变更，不应凭群消息替代必要的书面手续。
切换日并不是账龄清零日，也不应将旧公司库存、客户预付款或发票义务自动转为乙公司。确实需要跨主体承接的事项，应先取得对应合同、财务和税务处理依据，再按企业批准的方案形成调整凭证。在未完成这些步骤前，系统可以提供集团管理看板和客户服务协同，但不得假设两家公司的债权债务天然可以互相抵消。
图2：客户联系方式与新货盘可以按授权承接，合同、旧单和资金余额需分别核定主体；图中“待确认”不能视为已迁移。
承接必要客户资料，同时重建新企业的交易规则
乙公司需要的不是甲公司的整份数据库，而是开展新交易所必需且获得授权的客户资料：门店名称、联系人与收货地址、经营区域、适用品类以及服务人员。复制或重建后，逐户核对客户是否能看见正确的商品、价格、起订量、配送日期和支付方式。原公司的特殊折扣、历史信用额、对账习惯可能只对甲公司有效；即使乙公司愿意沿用，也要经乙公司经营和财务确认新规则、有效期与审批人。尤其不能把甲公司尚未收回的两万元欠款简单复制成乙公司的应收，或把旧授信余额当成乙公司已批准的信用额度。
权限也应跟着责任变化。销售在甲公司可以处理旧售后，不等于其在乙公司自动拥有客户改价、授信、退款权限；原业务员离岗或区域调整后，需指定新负责人，并保留旧单必要的查询或交接渠道。客户重复建档时，门店名称相近可能造成错绑，应该使用业务约定的唯一识别信息和人工核对，不能只按手机号自动合并。数据交接表要记录来源、用途、接收人、核对时间及差异，便于之后追溯客户说“我原来看到的价格不是这个”时，区分旧承诺、新规则还是录入错误。
在商猫云链系统落地时，可分别检查客户资料、客户可见商品和价格、订单归属、权限与资金记录等模块的实际配置。集团如有多主体视图，首先验证它的报表范围和订单穿透路径，而不是把“后台可同时看两家公司”误解为“业务和资金可以随意转”。若当前实例不支持某项跨主体自动迁移，就用受控交接清单和新企业建档完成，不宣称有未经验证的一键能力。
用客户手机端做首单验证，不能只看后台建档成功
试点客户要亲自从乙公司实际提供的手机商城入口走一遍：进入后确认企业名称，搜索一件常购商品，看规格、价格、可配送地址、起订量与优惠是否正确；提交测试订单后，由乙公司业务员在管理端核对订单所属公司、客户和金额，再由仓配确认备货与送达承诺，财务核对收款方式和开票资料。手机端是客户真实下单场景，后台能看到客户不代表客户已能顺利交易。若要展示系统操作截图，应使用能真实反映这个步骤的手机商城页面；没有对应真实页面时，业务流程图比拿无关的PC订单确认页充数更清楚。
首单最好选金额和数量可控的正常商品，同时安排一个故意触发规则差异的异常案例，例如甲公司原有折扣在乙公司尚未生效，或乙公司不配送该门店。正常案例要走到客户确认订单与履约结果；异常案例必须能明确告知客户原因，由业务员修正乙公司的配置或提出人工处理方案，而不是让客户回到微信报单后就宣称迁移成功。当天回访客户时，问其能否分清新旧收款对象、旧单售后找谁、下一次从哪里下单，这比“培训已完成”的签到更能揭示问题。
图3：手机端可见规则、乙公司接单履约和财务资金核对必须连成一笔真实可追踪的订单，异常要返回配置环节。
原企业旧账单独收尾，避免新收款误冲旧债
在切换后的两个对账周期内，甲乙两家公司各持自己的订单和往来明细，同时做一张只用于协同的集团交接视图。甲公司的应收按原客户、原单号和原合同追踪，收到客户付款时先确认汇入账户和付款用途，再在甲公司的相应往来中核销。乙公司的新订单、新收款和新退款则沿乙公司原单处理。若客户把甲公司欠款误付到乙公司账户，财务不能直接点乙公司的“收款完成”把问题掩盖；应联系客户及两家公司财务，按真实资金流和必要手续处理，并留更正链路。
旧预付款和退货更容易被忽略。甲公司曾收预款但未交货，不能只给乙公司客户账户加一个相同余额；要先确认预款对应的交易、退款或合法承接方案。甲公司原单退货可能发生在迁移之后，退货、退款和发票处理仍需回到甲公司的原始交易及实际责任，乙公司的仓库即使代收退货，也需要清楚标记代收物品与责任公司。每周复核未关闭的旧单、欠款、预存和售后，设责任人及最迟处理日；旧账没有清完不妨碍乙公司开展新业务，但不得把未清问题从管理视线中删掉。
图4：集团可并列查看甲乙业务；收款、核销、退货与开票仍沿真实交易主体和原始单据处理。
迁移是否成功，要同时验客户连续订货和主体账款清楚
验收不要只数“迁了多少户”。先在迁移清单抽取有旧欠款、有未完订单、无旧余额三类客户，检查其新入口可用性、乙公司首单成功率、报价差异、配送完成时间和客户对收款主体的理解。再从甲公司的旧单反查交接记录，核对旧应收金额、到账、退货退款和发票状态；从乙公司的新单反查合同或交易规则、实发数量、收款与售后。两条链路要能各自闭合，集团汇总视图只用来发现漏项，不能替代原主体的明细账。
出现争议时按来源处理：客户说“我在旧入口又下了单”，先核下单时间和旧入口停用或提示状态，已生成的有效旧单由甲公司按约履行或与客户协商处置；客户说“新价格比旧价格高”，查旧约定是否适用于乙公司，再决定是否经批准调整；客户付错账户，财务核实际入账与原债权，形成跨主体纠错记录。所有处理保留原单、沟通确认、审批与最终凭证，不能只改一个状态。试点观察一至两个实际对账周期，若新单可顺利履约且旧账持续可追、差异有人负责，才扩大到下一区域。若订单归属反复不明、客户频繁错付或旧账无人认领，就暂停新增迁移范围，修复边界和告知方式再继续。
这类调整的经营价值是让集团在优化区域供给时，客户不因组织变化被迫重新学习整套交易方式，经营者又不会以“服务连续”为由模糊财务责任。商猫云链系统可承接客户入口、商品价格、订单履约和资金记录的协同；真正决定迁移何时生效、旧义务由谁承担、是否需要合同与财务处理的，仍是企业的经营和专业岗位。把客户体验与责任分界同时做实，扩张才不会靠临时解释和手工冲账维持。