第 11 课 车企 VoC：先管预期，再把业务口径磨清楚

一个车企客户之声项目的完整流程

一家车企希望把分散在客服、销售与售后渠道的反馈整理成可用信息。项目团队从需求沟通开始，逐步确认业务定义，完成模型开发、私有化部署与报告交付。先看清整条流程，再确定每个环节由谁负责。

VoC 是 Voice of Customer，客户之声：把客服电话、线索跟进、社区帖子、售后工单和经授权获得的公开讨论整理成可用信息。质量部门关注故障，市场部门关注口碑，产品部门关注配置与体验。同一个“做 VoC”的需求，可能对应三种不同决策。

六段工作，各有交付物

这六段工作可以由多人分工完成，每个环节都要有明确的负责人和交付物。

会上能判断，承诺要有条件

既懂技术又懂业务的人，可以更快指出哪些可尝试、哪些需人工兜底、哪些缺数据。这里要区分初步判断与交付承诺：没有代表性样本和测试，不能当场保证准确率。

练习时，可以这样回答：“历史工单的观点整理可以先试；涉及安全故障的判断先由质量人员复核。请提供一批经授权的脱敏样本，我们再确定覆盖范围、评价口径与本期目标。”会后把本期范围、排除项、样本来源、人工职责、验收方法和变更处理写下来，由双方确认。

标签定义是业务协作，不只是模型调优

同样是服务态度不佳，购车阶段可能归销售，保养阶段可能归售后。标签需要明确含义、适用场景、包含与排除例句、相邻标签边界和确认负责人。遇到同一表达被人工标成不同类别，先复查口径，再判断是否需要改模型。

今天先做一步

用虚构车主反馈“买车时讲得很清楚，第一次保养却没人解释费用”，写一张需求确认单和两条标签定义。分别列出销售、售后想看什么；写明哪些字段缺失时先待复核。

本章产物与验收

• 一页需求确认单：范围、排除项、样本、指标、负责人、确认日期齐全。
• 两条标签定义：都有正例、反例与边界说明。
• 由另一位读者按定义分类；如有歧义，记录分歧并修订，不能把分歧直接记作模型错误。