业务问题
这个客户的客服团队规模不大，但咨询量集中在少数几类问题上：产品规格、库存与门店信息、退换货流程、售后标准。这几类问题的共同点是答案固定、口径必须统一，但每天要被重复回答很多遍。
真正的痛点不在“回答得慢”，而在三个地方：
- 新人上手慢。 遇到不熟的问题要翻资料、问同事，客户在原地等。
- 口径不统一。 不同的人回答同一个问题，措辞和承诺范围不一样，容易产生纠纷。
- 时间覆盖不全。 非工作时间和咨询高峰期，响应速度明显下降。
我们做了什么
第一步不是写代码，而是把资料整理干净。客户的产品资料、常见问题、历史服务记录分散在几个地方，版本也不统一。我们先和业务负责人一起确认了“以哪一份为准”，再把这些内容整理成结构化的知识条目。
第二步是设计应答边界。这里的原则很明确：智能体只处理它能确定的问题，判断不了的一律转人工。 涉及价格承诺、特殊退换、投诉升级这几类情况，全部走人工通道。
第三步才是接入。智能体承担首轮应答，回答时引用企业自己的资料，重要表述按企业标准输出。沟通结束后自动生成服务小结与分类标签，方便后续复盘。
落地时一起确认的边界
- 场景边界： 哪些问题交给系统、哪些必须转人工，逐条写清楚，作为验收依据。
- 知识来源： 产品资料与历史记录由谁整理、多久更新一次，明确到人。
- 责任分工： 谁负责验收、谁负责日常反馈与内容更新。
结果与后续
上线后，简单、重复的问题由系统承接，人力集中到复杂问题上。新人借助助手更快形成服务能力，服务也不再被工作时间限制。
需要说明的是：我们没有给出“效率提升百分之多少”这类数字。 一方面不同企业的口径难以对齐，另一方面这类数字如果没有双方共同认可的统计方式支撑，对决策没有实际帮助。真实的判断依据是：客服团队愿不愿意继续用它。
项目进入陪跑期后，主要工作是看真实对话里“没答好”的问题，反过来补充知识条目、调整边界规则。