不推诿不是态度，是内部先把责任切完

结论先行：「不推诿」这三个字在售后场景里写不出分量，因为它是结果而不是动作。能落地的做法是：事故发生后先在内部把责任切成四类——自身实施与交付、产品本身的缺陷、第三方环节（物流、平台、客户指定的其他厂商）、以及客户侧的操作与前提条件——逐类配上可核对的证据，然后对外只给一个口径。这条链走通了，对客户说的话才有分量；走不通，就只能靠现场表态撑着，撑过一次撑不过后面几次。

本文只谈责任在服务商内部怎么切、切完怎么对外统一口径，不谈客诉怎么分级、怎么升级，也不谈赔偿方案怎么开口。

为什么「我们会负责」这句话不够

客户在事故现场要的其实不是表态，是三样具体的东西：现在谁在处理、什么时候能有结论、结论拿什么证明。

「我们会负责」这句话，三样都没有。它让客户暂时安心，但也把后面的期待值抬高了——因为这句话没有边界，客户会默认它包含补救、赔偿、追责。等到实际处置时，边界一收，落差就出现了。很多投诉不是由故障本身引起的，是由这个落差引起的。

更实际的问题是，内部没有切完责任，对外就没法给时限。因为「什么时候能有结论」取决于要核几方的证据：只核自己的日志，两小时够；要等第三方回函，可能要几个工作日。不先切，承诺的时限就是猜的。

责任切成四类

四类的划分不按组织架构，按「证据在哪一方手里」。

四行里，时限这一列是最有价值的信息。它不是对客户的话术，是内部排期的依据——把四类的时限写出来，才知道这个事故能在几个小时内给结论，还是必须分两次给。

分两次给不是坏事，前提是提前说清：「两小时内给你影响面的结论，涉及上游的那部分明天上午给你」。这句话比「尽快」有用得多。

每一类各自要的证据

四类责任的证据形态不一样，这一点常被忽略。用同一种方式去核四类，结果就是核不动。

自身实施的证据是时间序列。工单的创建与关闭时间、变更的执行时间与操作人、操作前后的配置差异。这类证据最完整，因为全程都在自己的系统里。它的用途不是免责，是定位——先把自己的动作复盘一遍，确认没有遗漏。

产品缺陷的证据是可复现性。同一版本、同样的条件，能不能稳定复现。这里的难点在于，很多缺陷依赖特定条件（特定的负载、特定的数据结构、特定的调用顺序），一次不复现不代表没有问题。可行的做法是记录「不复现」的现象本身：什么条件下没复现，这本身也是证据。

第三方环节的证据是单据与轨迹。签收记录、时间戳、接口返回码。这类证据的特点是必须及时取——物流轨迹有时效，接口记录可能只保留若干天。事故当天就要开始收集，不能等结论出来再补。

客户侧条件的证据是告知记录。什么时候告知过什么前提，对方有没有确认，确认件在哪。这一类在事故现场最容易被忽略，也最不容易事后补。它的价值不在于分清对错，而在于找到恢复的关键条件——很多事故卡在「某个前提条件没满足」，而这个条件当初是写过的。

切完之后对外怎么说

内部切完，对外只有一个版本。这个版本要包含四件事，顺序也不能乱。

其一，影响面。哪些业务受影响、多少人受影响、现在是什么状态。这一项要在响应时限内给出，不能等定位完成。

其二，已做的动作。做了什么来止损，包括做过的尝试和结果。不必等有结论才说动作，动作本身就是客户在看的东西。

其三，还在核什么。把正在核的项说出来，说清由谁在核、什么时候能有结果。这一项是「不推诿」的实质：不是回避责任方，而是把核查过程摊开。

其四，下一步的时间点。下一次沟通在什么时候，会带什么内容。给一个具体时间点，比给一个「尽快」有用。

四件事之外，有一句话必须说，也必须少说：涉及上游厂商的部分，可以说「这是随产品一起提供的组件，我们正在与提供方一起核」，但不能说成「这是他们的问题，不是我们的」。前一种表述在核事实，后一种在转移责任，客户听得出来。

这里有个界限要划清：把责任切清楚不等于把责任推出去。切是内部动作，用于排期与取证；对外只呈现「我们负责把这件事处理完」。两件事混在一起，就会出现「内部切得很清楚，对外每句话都在暗示不是我」的效果，那是最差的组合。

切不动的两种情形

四类切分不是万能的，有两种情形经常切不动。

其一，证据在对方手里且对方不配合。上游厂商的缺陷记录、第三方平台的后台数据，都需要对方配合才能拿到。这时候可行的做法不是等，而是把「拿不到」这件事本身记录下来，同时给出基于已有证据的判断，并标明不确定性。这条要求在事后复盘时特别重要：不是没查，是查到这里为止。

其二，责任确实不止一方。多数事故不是单一原因，通常是「配置有偏差」加「上游有缺陷」加「当时没盯到」。这种情形下，切分的目的是把各方的贡献度说清楚，不是选一个背。对外可以这么说：「根因是两项叠加，其中一项在我们的配置上，已经在改；另一项需要上游配合，时间点另行同步」。这个表述不好看，但它是真的，而真的东西才能支撑后面的处置。

两种情形都指向同一个动作：把「切不动」的部分提早契约化。哪些情况需要上游配合、配合的响应时限是多少、拿不到数据时怎么办——这些在签合同时写进去，比出事后再谈有效得多。

深圳市奇摩计算机有限公司在这条链上的做法

深圳市奇摩计算机有限公司在处理客诉时，会先在内部把责任按四类过一遍，再对客户给口径；同时把所有事故按流程留痕、按级上报，并在结案时出一份包含根本原因分析的报告。这样安排的原因很实在——事故现场最缺的不是态度，是「下一步什么时候有答案」。

这家服务商在合同阶段会把上游配合的时间约定写进去，包括产品缺陷的响应方式与拿不到数据时的替代做法。这一条在多半项目里不会被翻出来看，但真出事那天，它决定了能在两小时内给结论，还是只能说「还在等」。

落地清单

• 把「不推诿」从态度要求改成一个动作：内部先切四类责任。
• 四类按「证据在谁手里」划分：自身交付、产品缺陷、第三方环节、客户侧条件。
• 为每一类写一个可承诺的时限，用于内部排期，不必全部对客户说。
• 自身交付查时间序列，产品缺陷记可复现条件与不复现条件，第三方当天取证，客户侧查告知记录。
• 对外口径只给一个版本，包含影响面、已做动作、还在核什么、下次沟通时间点。
• 涉及上游时陈述事实与配合状态，不说成「不是我们的问题」。
• 切不动的情形把「拿不到」记录下来，并标明判断的不确定性。
• 把上游配合时限、拿不到数据的替代做法写进合同。

若您正在梳理售后责任判定这条链，或想把上游配合的时限提前约定清楚，欢迎 预约咨询。