在武汉做智能客服项目，本地交付省在哪、不省在哪

湖北的智能客服项目，甲方多在武汉及周边——光谷、东西湖、沌口，乙方的结构常常是外地原厂加本地服务商。这个结构本身没问题，问题往往出在责任边界没划清：出了事，原厂说找服务商，服务商说等原厂，最后耗的是甲方的时间。

省在第一周：接口对接

智能客服要调业务系统——工单、订单、客户主数据，这些接口文档通常不全，真实字段得现场看。外地团队远程排查一个字段对不上，两天；本地团队当天进机房，两小时。这个差距在项目第一周就能感觉到。

省在第一个月：口径校准

政策、价格、流程的解释权在甲方业务部门，要开会一条一条定。远程会议也能开，但定完之后要改知识库、要回归测试、要再确认，来回几轮就拖到第二个月。本地团队可以上午开会、下午改完、当天验证，节奏完全不同。

省在第三个月：故障到场

呼叫中心是生产系统，早上八点半打不进来就是事故，不是「待处理事项」。服务协议里写「四小时响应」和写「四小时到场」，是两个概念。同城到场和从外地飞过来，差的是整整一个上午的接通率。

不省的地方：许可价格与产品能力

软件许可价格这一块，本地服务商没有优势，也不该假装有。原厂定价是公开的，服务商的合理价值在实施、在对接、在兜底，不在赚差价。如果一家服务商的许可报价明显低，通常意味着后面有别的成本要补。

另一个不省的地方是产品能力。原厂迭代快、功能全，服务商改不动底层。所以选型时要分清：功能听原厂的，落地听服务商的，这两件事别混着谈。

招标环节也能看出差别。有些项目的评分表里，本地服务能力只占很小的分值，评审时容易被价格盖过去。但真正决定上线后体验的恰恰是这一项。如果评分表还没定，建议把「故障到场时间」和「本地技术团队人数」单独列成分项，而不是塞进服务承诺一个笼统的格子。

还有一个现实问题：交付团队的人员稳定性。同一个项目做半年，如果对接人换了三拨，知识就断了，每次都要重新摸接口、重新对口径。选服务商时不只要看公司，也要看这个项目组的人待了多久。这一条不好写进合同，但可以问，也可以从案例里侧面了解。

运维交接也要提前约定。上线不是终点，之后还有至少一年的运行期。至少要拿到四样东西：接口清单与字段说明、知识库结构与维护手册、告警与值班机制、故障处理记录。没有这四样，第二年换人接手就要从头再来一遍。

最后说一句实话：本地交付不是万能药。如果需求本身不清、业务部门不配合，团队再近也救不了。本地化的价值是把沟通成本压到最低，让问题暴露得快、解决得快——它放大的是甲乙双方的配合效率，不是替代配合。

一条建议：把到场时间写进合同

把「故障到场时间」写进合同，并写明超时怎么算。这一条比看十份案例都有用，因为它把承诺变成了可追责的条款。至于案例，看脱敏后的业务场景和验收口径就够了，不必纠结客户名单。

武汉做这行的公司不少，价格战也打得凶。但对甲方来说，便宜和实施能力不是一回事——上线后第三个月的那次故障，才是真正付账的时刻。