交付后客户说不能用，先分清三件事

2026-08-12 售后处理,需求确认,交付验收,客户沟通

2026 年 8 月我交付烧烤店那单，收入 ¥3000，其中手写代码不到 20 行。交付第二天客户发消息说「打不开」。交付后客户说不能用，十次里有八次不是代码的问题。 关键是在打开编辑器之前，先分清三件事。

第一件事：是真坏了，还是预期不对

这两件事的处理方式完全相反。

真坏了——功能本身有 bug，页面报错，数据不对。这种你改。

预期不对——客户想要的是 A，你交付的是 B，但需求文档里写的是 B。这种不能靠改代码解决，得回到当初确认过的内容上。

分辨方法很简单：让他描述「你期望发生什么，实际发生了什么」。 只要他不说这两句，你就不要动手。

第二件事：是谁的环境，谁的账号

我遇到那次「打不开」，最后查出来是客户用的浏览器版本太旧。

交付后的问题，第一反应应该是问三件事：什么设备、什么网络、什么账号。 这三样里任意一样和你测试时不同，问题就未必在你的代码里。

我当时的处理是先让客户换个浏览器试，五分钟解决。如果上来的第一反应是「我看看代码」，可能就要花一晚上。

第三件事：是本次范围，还是新需求

这是最容易吃亏的一条。

「不能用」这三个字很有弹性。 它可能指你交付的功能有问题，也可能指客户发现少了某个他从没提过的功能。

判断标准：翻回需求确认记录。 需求里有的，是你的责任；需求里没有的，是新需求，走变更流程，具体见客户中途加需求怎么加钱，别只加活儿。

这一步不做，你会免费干很多活。

我那次的处理过程

客户说打不开，我的实际动作是按顺序走的：

1. 先问三件事——设备、网络、账号，一次问完

2. 要截图或录屏——不是不信任，是文字描述误差太大

3. 自己复现——用客户说的一样条件跑一次

4. 给出结论和下一步——是环境问题就告诉他怎么换，是 bug 就说修复时间

整个过程我没打开过一次代码编辑器。 因为问题在第一步就定位了。

我踩过的坑。

早期我犯过一个错：客户说不能用，我第一反应是道歉，然后说「我马上看看」。

道歉太快会直接坐实责任。 后来改成先确认事实，再决定要不要道歉。这不是推卸，是不在事实不清的时候下结论。

第二个错是在群里公开讨论技术细节。客户群里还有他的同事和老板，技术讨论放进去会显得问题很大。改成私聊沟通，群里只发结论。

一套可以直接抄的回复模板

收到「不能用」的消息时，先回这一段：

「收到。为了快速定位，麻烦你提供三点：一是你用的设备和浏览器，二是打开的具体页面或操作步骤，三是你期望看到的结果和实际看到的结果。有截图或录屏更好。我这边同步复现，稍后给你结论。」

这段话的作用是把讨论从「你的东西坏了」拉回到「我们一起定位问题」。

分完三件事之后怎么走

真 bug：给修复时间，说明原因，改完再交付一次
环境问题：给操作指引，必要时远程看一下
预期偏差：翻需求记录，把确认过的内容截图发过去
新需求：走变更流程，报价后再动手

只有第一种和第四种需要写代码，但第四种要另外收钱。

至于责任划分、退款争议这些事，以合同约定和当地法律法规为准，我不给判断。

常见问题

Q：交付后客户说不能用怎么办？

A：先分清三件事——是真 bug 还是预期偏差、是不是客户环境问题、属于本次范围还是新需求。分类之前不要动手改代码。

Q：客户说不能用又不肯给截图，怎么办？

A：说明你需要这些信息才能定位，并把需要的内容列成清单发过去。对方不配合时，先把问题记录在案，约定一个回复期限。

Q：查出来是客户自己的环境问题，还要改吗？

A：不需要改代码，但可以给一份操作指引，或者远程协助一次。这部分是否算售后，按合同约定和当地法律法规口径处理。