在 Turo 客服工作台的设计里,我们把车辆、预订状态、行程信息和客户对话放在一起。取还车的问题经常需要这些上下文;涉及费用、争议或异常的事项,又需要运营人员作判断。两类工作适合不同的处理方式,客服系统需要把这个区别表达出来。

标准问题,也要先核对这一次行程

“怎么取车”和“我现在到了,怎么取车”,看起来接近,回复所需的信息却可能不同。设计回复之前,需要知道用户问的是哪辆车、哪次预订,以及当前处于什么阶段。把这些资料放在对话旁边,是为了让处理者少做几次来回查找。

模板适合保存稳定的说明,例如取还车步骤和照片记录要求。实际回复仍然需要核对相关行程,不能因为问题熟悉,就直接套用一段答案。

需要承担判断时,让人工接手

费用是否合理、车况记录是否存在争议、异常情况该如何处理,这些问题涉及责任与具体事实。即使能生成一段流畅的解释,也不意味着系统具备作出决定的依据。

因此,工作台区分标准答复与人工处理事项。对于后一类,设计上的重点是保留问题与已有资料,让运营人员核实,再决定如何回应。语气自然可以改善沟通,却不能代替授权与判断。

交接本身,也是一段需要设计的流程

设计人工入口时,我们关注接手的人需要看到什么:相关行程、客户提出的问题、已经掌握的信息,以及仍需核实的部分。转交之后,如果这些资料还需要重新收集,工作就只是换了一个人重复开始。

当前展示使用模拟行程和模板回复,尚不能据此说明真实服务效率。后续接入实际业务时,值得检查的是:上下文是否齐全、人工是否容易接手,以及未经核实的事项有没有被误当成结论。

这次设计中的判断

我们希望客服系统既能处理重复工作,也能把需要判断的事情,连同必要信息交到合适的人手中。

相关项目

本文围绕已有项目的设计整理。查看 Turo 客服智能体 的案例、真实界面与说明 ↗