客户档案
事项与
关于同一件事的每一条消息、每一通电话和每一封电子邮件，如何作为一个事项归并在一起，从首次联系直到解决，以及每个事项记录了什么。
客户很少能在一条消息里把事情解决。周日在 WhatsApp 上报告漏水后，周一接着是一张照片，周二是一通电话，周四又是一封确认维修的电子邮件。Telonic 把这些都归并为一个事项：事项在客户首次就此联系时开启，在问题解决时关闭。您的团队看到的是客户需要的每一件事、它目前的进展，以及为此经历的全部过程，而不是一堆零散的消息。
什么是事项
事项是客户为之联系的一件事。它介于单次对话和客户的全部历史之间。
| 术语 | 涵盖内容 | 示例 |
|---|---|---|
| 对话 | 一通电话、一个邮件线程，或在某个渠道上一段连续的消息往来 | 周日晚间的一段 WhatsApp 往来 |
| 事项 | 客户需要的一件事，从首次联系到解决，无论经过多少次对话和多少个渠道 | “厨房水槽下方漏水，房号 C-0412” |
| 客户档案 | 该客户在每个渠道上的每一次对话和每一个事项 | Sahel Crest Properties 与一位买家讨论过的所有内容 |
由于档案按事项组织，您的团队可以回答关键的问题：这位客户还有哪些事项未结，解决一个事项经历了哪些过程，以及客户是否不得不再次联系。
消息如何归并到事项
在 WhatsApp 和短信上，一段消息往来被视为一个事项，而不是多个。客户在两天内就同一处漏水发送五条消息，档案中只有一个事项，而不是五个。
新消息到达时，AI 智能体会判断它是在延续一个未结事项，还是开启一个新事项。它依据客户所说的内容、客户提供的任何编号，以及客户档案中已有的未结事项进行判断。无法明确判断时，它会询问：“这是关于您厨房漏水的事，还是另一件新的事？”
邮件线程保持完整
一个邮件线程在每次回复中都作为同一个事项保留。客户在一周后回复一封确认邮件，延续的仍是同一个事项，因此不会有内容被重复答复，也不会在一连串转发中丢失。参见电子邮件：邮箱连接、邮件线程与附件。
一个事项跨越多个渠道
客户在一个渠道上开始、在另一个渠道上继续，仍属于同一个事项。在 WhatsApp 上发送的照片和关于同一处漏水的后续来电，都会归入该事项。接听来电的智能体已经知道漏水的情况，看过照片，也知道之前说了什么。
之所以能做到这一点，是因为每个渠道都向每位客户的同一份档案写入数据，也从中读取数据。参见客户档案：概览。
同时存在多个事项
一位客户可以同时有多个未结事项，例如一个关于交房日期的问题和一个关于物业服务费的咨询。每个事项单独跟踪，各有自己的对话、状态和处理结果。
一次对话也可能引出多个事项。当一位买家来电反映漏水，随后又询问物业服务费时，这通电话会同时关联到两个事项。智能体可能解决其中一个，把另一个转交给您的团队，档案会准确显示每个事项的情况。
事项如何关闭，以及它记录的处理结果
每个事项都会记录处理结果，让贵机构能够看到哪些问题真正得到了解决。
| 处理结果 | 含义 | 示例 |
|---|---|---|
| 已解决 | 客户的需求得到满足 | 已更改预订并发送确认 |
| 仍未结束 | 工作正在进行，或正在等待某项条件 | 车险理赔正在等待修理厂出具报告 |
| 已转交给您的团队 | 事项已转给工作人员，并附有完整的历史和摘要 | 退款请求已转给财务团队 |
处理结果会汇入控制台（您的团队使用的 Telonic 网页应用）中的各项指标，例如解决率和首次联系解决率（事项在客户无需再次联系的情况下得到解决的频率）。参见处理结果与联系原因。
客户为什么联系
每一次对话都会被标记一个联系原因，取自您与 Telonic 约定的一组类别。旅游公司可能使用“预订变更”“行李”“退款进度”和“特殊协助”。保险公司可能使用“理赔进度”“新理赔”“保障范围咨询”和“续保”。
在成千上万个事项中，联系原因揭示了是什么在推高您的对话量。如果同一栋楼的数百位买家都就物业服务费提出同样的问题，那就应该从源头解决，而不是逐一答复。
事项再次出现时
当客户就一件已经解决的事再次联系时，智能体会重新开启原来的事项，而不是新建一个。一位客人来信说上周承诺的退款还没有到账，延续的就是同一个事项，此前的每一次对话都附在其中。
这样，无论谁接手，完整的历史都集中在一处。这也意味着重复联系会被如实统计：再次出现的事项第一次并未得到解决，您的首次联系解决率数据也会反映这一点。
技术细节
| 问题 | 答案 |
|---|---|
| 新消息如何关联到未结事项？ | 依据消息内容、客户提供的任何编号，以及客户档案中的未结事项。存在歧义时，智能体会询问客户 |
| 邮件线程如何保持完整？ | 智能体将每个邮件线程作为一次对话跟踪，因此每次回复都延续同一个事项 |
| 事项有编号吗？ | 有。如果某个事项需要在您的其他系统中处理，例如在您的服务台（您的团队用来记录和跟踪请求的系统）中创建工单，该事项也会保存那个系统的编号 |
| 记录哪些处理结果？ | 每个事项都会记录已解决、仍未结束或已转交给您的团队 |
| 联系原因类别由谁设定？ | 由您的团队与 Telonic 在实施期间共同设定。之后可以更改 |
实际应用
Salma 通过酒店集团 Qamar Stays 的网站预订了四晚住宿。
- 周一，她发电子邮件说订金被扣了两次。智能体将邮件关联到她的预订，核对付款记录，确认存在重复扣款。退款需要财务团队审批，因此它把这个事项连同摘要转交给财务团队，并告诉 Salma 接下来会如何处理。
- 周二，她在 WhatsApp 上发消息，询问能否增加机场接送。智能体识别出这是一个新事项，在酒店规则范围内安排了接送，并将其作为已解决关闭。
- 周三，她回复周一的邮件线程，询问退款是否已获批准。这条回复延续了第一个事项。智能体在酒店的付款系统中查询退款情况，告诉她退款已于当天上午获批。
- 下一个周一，Salma 再次来信：退款还没有退到她的银行卡上。智能体重新开启原来的事项，并连同完整的历史再次转给财务团队。
- 她的档案显示两个事项：一个在一次对话中就得到解决；另一个经历了跨两个渠道的四次对话，并且再次出现过一次。
您的团队掌控的内容
- 联系原因类别，以及对这些类别的更改。
- 每类事项怎样才算已解决，在实施期间约定。
- 哪些事项会在您自己的系统中创建工单或任务。
相关内容
产品名称和标识均为其各自所有者的商标。提及这些名称和标识，表示 Telonic 与相应系统连接，并不意味着存在合作或背书关系。