JINDONG HUIZHI
今东汇智 · 案例与方法
演示答得顺，不等于客户问题接得住。看一个厂商客户故事，再把测试和转人工写成能检查的清单。
合成场景 · 非真人真事
以下开场用于说明测试盲区，不是作者或围总亲历。
你准备验收一个AI客服。
演示里，它回答得很顺。
你照着知识库提问，它能答。
你把客户的原话换上去，它开始绕。
你补了一句“不是那个设备”。
它又解释了一遍刚才的答案。
你想找人接手，却没看到入口。
此刻，问题不再是它会不会说话。
而是：它听不懂的时候，谁来收口？
01
顺畅演示之外，还有真实问法
THE GAP
做客服的人容易理解这种落差。文档写的是产品名称，客户说的却是“旁边那个盒子”；文档按完整问题分类，客户只说了半句，还夹着上一次沟通的背景。
这不是让客户学会提问就能处理的事。客服服务的是有事情要办的人，而不是来配合演示的人。
Salesforce在2026年11月6日发布的Greenlane客户故事，提供了一个可参考的做法。Greenlane建设电动重卡充电网络，司机会询问如何开始充电、账单以及站点进出等问题。
原文称，它原先使用的共享呼叫中心，要同时服务不同企业，难以保留充电业务所需的细节背景。Greenlane已有Salesforce的数据和业务流程基础，因此选择用Agentforce配置客服代理。
这里应当分清：这是Salesforce发布的厂商客户故事，不是独立评测，也不是我们对系统的实测。它的既有系统条件，也不等于每家企业都具备。
我们要借鉴的，是它怎样检查答案，而不是照搬它买了什么。
那么，团队把哪些难题放进了测试里？
02
不只测标准问题，还要测“没说清”
TEST DESIGN
原文记载，核心搭建约两个月，随后团队继续严格测试；他们创建了100多个场景，覆盖司机可能提出的高频问题。文中还明确写到：要测试改述、说话不完整、对硬件使用不同叫法等情况。
“约两个月”描述的是该案例的核心搭建阶段，不是给其他企业的交付周期承诺。场景数量也不是一条通用达标线。问题清单多长，要由你的业务范围和风险决定。
困难往往出在这里：只测知识库里的标准问法，成绩可能很好看；把客户原话全塞进去，却没有判分依据，又会变成大家凭感觉争论。
两条路都不够。
测试不是让AI把资料复述一遍，而是看客户换种说法后，事情还能不能被正确处理。
以下是今东汇智基于案例整理的方法建议，不是Greenlane原文披露的测试表。
先从经过脱敏的历史咨询里挑高频事项，再按同一意图整理不同问法。别把每一种口语表达都当成一种新业务，也别把不同业务硬塞进同一个标准答案。
一张测试卡应写清什么
客户原话：保留省略、别称和上下文缺口，但去除个人信息。
业务意图：客户究竟想知道什么，或想完成什么。
答案依据：对应哪份已批准资料、哪个版本、谁负责维护。
通过条件：应回答什么、应追问什么，以及不能擅自做什么。
接手条件：什么情况停止解释，转给哪类人员。
方法示意：今东汇智整理，非Greenlane内部测试表。
把这些写在提问之前，而不是看到答案后再修改判分口径。接下来，才有理由讨论“通过”两个字。
03
测试成绩好看，不等于可以放手
EVIDENCE
原文按答案准确度、平均处理时长、是否需要升级处理来评估场景。页面结果栏标注了106个测试场景，以及98%的AI响应能力。
这份厂商故事正文同时称，该案例早期测试阶段相对共享呼叫中心，回答速度快58%、答案准确度高15%；并称可处理至多98%的来电而无需升级处理。
这些话必须连着边界一起读：它们是厂商故事所述的早期测试结果，不是正式运营成效，更不是客户满意度或错误率。原文没有在该页面给出足够的计算细节，不能把“准确度高15%”改写为“提升15个百分点”。
本文不把这些比例当作选型结论。真正值得留下的，是它同时检查了“答得对不对”和“需不需要人接手”。
如果团队只盯着少转人工，遇到不确定的问题也硬答，表面上的自动处理比例可能好看，客户却被留在错误解释里。这是我们的风险判断，不是对Greenlane实际运行情况的指控。
该转的没有转，也应算作测试失败。
人工兜底不能只在方案里写一句，具体应该接住什么？
04
收口不是道歉，是把事情交出去
HANDOFF
Greenlane原文说，若答案不在已批准来源中，代理不应编造；边缘问题保留人工支持路径。文中还提到，测试暴露缺口后，团队会补充别称、调整检索逻辑或更新指令。
这给我们的启发是：不要把所有失败都归结为“模型不够聪明”。客户换了叫法，可能要补资料；找错了文档，可能要改检索；明明没依据还作答，可能要改停止规则。
方法建议：先定位失败类型，再修订并复测；不是厂商披露的内部流程。
以下交接清单同样是本文建议，需由企业自行确认后使用：
人工接手要能检查
触发：资料没有依据、信息相互矛盾，或客户明确要求人工。
告知：说明当前不能确认什么，不拿猜测当结论。
交接：把客户诉求、已核实信息和未解决问题交给接手人。
路由：写清负责岗位、可用渠道；无人可接时给出真实的后续入口。
复测：既测“能转过去”，也测接手人是否看得到必要上下文。
这里的高潮不是AI独自接完所有问题，而是你打开一份测试记录，能看见每个问题的判断依据、失败原因和接手位置。
一次像样的验收，要允许答案是“这里交给人”，但不能停在“请联系人工”。
今东汇智方法示意；转人工条件及渠道须按实际业务确认。
05
把上线判断，落在可追查的记录上
NEXT STEP
上线前，你可以让业务负责人和客服一起看测试记录：同一种意图换个说法是否仍能识别；缺资料时是否停止猜测；交接后是否有人知道要接着做什么。
测试没有通过，就把缺口留在记录里。修订后用原问题复测，再补充类似问法，避免只记住一道题的答案。测试所用资料版本也要保留，否则后续很难解释同一个问题为什么变了答案。
冷静一点看，受控测试并不能覆盖真实客户的所有表达。资料变化、站点状态变化、人工渠道变化，都可能让原来通过的题再次失效。本文建议上线后继续抽查，不将一轮成绩当作长期能力证明。
Greenlane的案例不是一份照抄即可生效的答案。它提醒我们：在讨论AI接了多少之前，先看没接住的事有没有去处。
本文开场为合成场景，非真人真事；案例事实据Salesforce客户故事，方法清单为今东汇智整理，未实测该系统。
你更想先测哪一类：客户换个说法，还是AI不会时转人工？欢迎在评论区说说你遇到的难题。后台回复「诊断」。
案例来源：Salesforce，2026年11月6日，Greenlane客户故事：https://www.salesforce.com/customer-stories/greenlane/
THANKS FOR READING
今东汇智