接手被换掉的DMC客户，前90天别急着证明你更强

一、一个真实到有点扎心的接盘现场

去年下半年，我认识的一家华东地接社接了个"天上掉下来"的客户：一家欧洲Tour Operator刚跟合作三年的中国DMC闹掰，把未来八条Series Departure一股脑扔了过来。合同签得飞快，客户的态度也很直白——赶紧把团接住，别出事。

结果新团队上班第一天就傻了眼。六个已售团期，20封往来邮件，行程文件前后七个版本，四张报价表，还有一批"旧DMC说确认过"但合同主体完全对不上的酒店。客户自己也说不清哪些信息还能用、哪些要重新核，因为这些规则都散落在上一家的销售邮箱、OP的微信和几年前的WhatsApp记录里。

我们做旅游这行的都懂，换地接这件事，最凶险的从来不是"找不到新供应商"，而是合同一换、联系人一换，所有人都默认事情结束了。实际上，真正的考试才刚开始。

二、前90天为什么最危险：新旧事实同时在场

供应商切换最容易被低估的地方，就是大家以为交接是一瞬间的事。合同换了、联系人换了、新团队开始跑团了，任务就完成了。可一个跑了几年的复杂Account，影子比想象中长得多：部分酒店是旧合同确认的，新合同没法自动继承；有的客人交了Rooming，有的没交；某个团期前后改了三次行程；Advisor长期要求白标出团，可这条规矩只写在原销售的私人邮箱里；团里还有特殊饮食、行动需求的客人，Brief散落在聊天记录里。

这种局面的危险，不是哪一项信息缺失，而是信息看起来特别全，团队于是默认它已经被验证过。新旧两套事实叠在一起，最怕的就是所有人以为自己在执行同一个版本，实际各拿各的。

三、十个最容易出事的环节

接手一个Replacement Account，出问题几乎都出在同一批地方。下面这十个环节，每一行都是真金白银换来的教训：

这些环节的共同点是什么？它们不是靠"效率"解决的，是靠"让每项事实重新获得状态"解决的。

四、过渡计划不是交接表，是四个问题

一个能用的过渡计划，至少要把四件事回答清楚。

Scope——到底迁移什么。不是所有旧资料都值得搬，真正要重建的是：当前有效产品、未来已售团期、关键客户规则、必要客人需求、已确认和待确认的资源、商务状态、风险事项。

Ownership——迁完之后谁负责。Account Owner、销售、产品、OP、财务、Emergency角色得分清。最怕两种情况：所有事都找同一个人，或者谁都说不清最终谁负责。

Status——每项现在是什么状态。Confirmed、Pending、Needs Revalidation、Client Decision Required、Not Applicable、Closed，比在表格里堆备注好管得多。

Cutover——旧责任哪一天真正切成新责任。跑到一半的预订由谁完成？未来团期从哪天起算新DMC的？款付给了旧供应商、服务还没执行怎么办？这些没法套模板，得按合同、付款和双方正式文件一条条捋。

一张能用的过渡表，至少要有这些字段：Account/Project、团期、当前行程版本、商务状态、供应商确认状态、客户规则、客人需求、Pending Item、Owner、截止时间、状态依据、最后更新时间、风险等级、下一步动作。目的只有一个——让销售、产品、OP不再靠"我记得上次好像是这样"干活。

过渡真正完成的标准，不是新DMC收到文件，而是每一项关键事实都重新拥有了Owner、Status和Current Version。

五、首团不是履约，是压力测试

Replacement客户的首个团，最容易犯的错是倾巢而出：为了证明自己比上一家强，把团队里所有老手都押上去，问题全人工兜住。首团顺顺利利，第二团回到正常配置，问题立刻冒出来。因为你验证的是一次特殊照顾，不是一套可复制的新合作机制。

首团真正要验证六件事：全员拿的是不是同一版行程；白标、客户保护这些Account规则有没有下沉到一线；特殊需求有没有从Brief传到履约；酒店或导游临时换人时，是不是按已确认的产品标准处理；临时变化时谁是Owner、谁通知Advisor；首团暴露的问题有没有在第二团前完成分类和更新。

对Series团尤其如此。首团冒出的小问题，如果属于整个系列的结构性问题，必须在第二团前写进Master Product、Guide Brief、Account Rule和OP的SOP里。首团不是过渡的终点，是第一个真实数据点。成熟的做法是：首团→复盘→更新→第二团→再验证→稳定，而不是"首团成功，宣布迁移完成"。

六、知识迁移最容易被"文件很多"骗了

旧DMC合作多年，留下的Proposal、报价、Rooming、邮件、Guide Notes、客人偏好、合同、供应商文件堆成山。新团队一看："信息很完整嘛。"实际上文件越多越要筛——里面混着过期规则、错误版本、只适用于某个客户的特殊安排、原供应商的内部商业信息、已经失效的联系人，甚至不该长期保存的客人敏感资料。

知识迁移不是搬文件，是把"仍然有效、确实有权用、未来还要执行"的知识重新确认一遍。可以按四类分开管：Account知识（白标、客户保护、商务习惯）、产品知识（系列标准、酒店偏好、导游要求）、当团数据（日期、人数、Rooming、航班）、敏感数据（护照、健康资料、私人联系方式）。四类东西混在一个"客户资料包"里，迟早出事。

七、风险清单要落到人头上

过渡期的风险，最好显性管理：列一张Risk Register，每条风险有Owner、有下一步动作、有截止时间。酒店没重新确认，是典型的过渡风险；旧报价还在流通，是商务风险；白标没下沉，是渠道风险；Emergency联系人没更新，是现场风险；Pending Item没人负责，是最高危的迁移问题。

过渡期的问题还要跟日常运营问题分开记——首团出了状况，先判断是不是供应商切换本身造成的，别一股脑算在新团队头上，也别一股脑不当回事。

八、收束：先答对那七个问题

一个客户今晚把未来三个月六个已售团期交过来，20封邮件、7个版本行程、4张报价表、一批未确认酒店。明天早上你团队能不能先回答：哪份是当前版本？哪些资源重新确认了？哪些只是旧资料？哪些风险没解决？每项谁负责？首团要验证什么机制？

如果不能，最该做的不是发Proposal，而是先把过渡控制建起来。

换了地接的采购者，最不缺的就是"我们很专业"的漂亮话。它刚从上一段合作里吃了亏，需要的是有人告诉它：哪些确定、哪些不确定、谁负责把不确定变成确定。供应商切换真正专业的第一句话，不是"我们能接"，而是"我们先把现在的真实状态确认清楚"。

换供应商这个本来高风险的窗口，能不能变成一段长期B2B合作的入口，就看新DMC有没有把"接盘"当成一项项目管理来干。