营销活动之后会发生什么

一份汇总每通电话发现了什么的结果摘要、一次导出，以及含义截然不同的两组结果——它们说的都是你名单的事。

通话是成本。结果才是你买到的东西，而它们分两层到达：每通电话身上发生了什么，以及每通电话发现了什么。

下面的一切都在 /campaigns/… 的活动页面上。

结果摘要

值得第一个打开的部分。结果摘要把你的对话洞察字段在整个运行范围内汇总—— 每个值带着计数和百分比，于是你读的是这场活动，而不是一通通电话。

它自己会给你两条提示：“仅显示最常见的取值。“，以及在还太早时的*“来自此营销活动的会话尚未经过分析。”* 如果它一直是空的，原因几乎总是没有关联任何洞察—— 见下文。

每条记录都以一个处理结果收尾，列表可以按全部处理结果和全部状态 筛选。把九个值当成三组来读，会容易得多：

组别	结果	它告诉你什么
接到了人	answered_human	你真实的接通率
什么都没接到	no_answer, busy, voicemail	值得重试
接到了错误的东西	disconnected, wrong_person, ivr_system	名单里的数据问题

人们最容易把第三组误读成绩效不佳。一场接通率很低、disconnected 堆成山的活动并没有失败——它告诉你名单过期了，再打一遍也修不好。

点开一条记录可以看通话详情：转录文本、通话录音（配播放录音和 下载录音），以及从那通电话里抽取的字段。

结构化的字段——是答案，不是转录。这就是能拿去行动的结果和需要有人去读的结果之间的差别。按一个字段给一百通电话排序只要一秒；听完一百通电话要一天，而且没有人会听第二遍。

导出 CSV 会把全部内容给你。每个对话洞察字段的字段键都会*“用作 CSV 列标题”*，所以按你希望导出读起来的样子命名字段——在运行之前，不是之后。

值得知道，因为它能解释一个空的摘要。活动要么有自己的洞察，要么继承智能体的：

“继承自智能体。此营销活动没有自己的覆盖设置。” ——常见、而且通常正确的情况。
“覆盖智能体的默认设置（……）” ——这场活动要问的是不同的问题。
“此营销活动有自己的提取字段。它们仍会运行，但其他营销活动或智能体无法使用。” ——自定义（不可复用）状态。按一下保存为可复用的对话洞察 即可解决。
“此对话洞察已不存在” ——一份悬空的关联，什么都不会被抽取。

如果摘要是空的而电话都接通了，就到这份清单里找。

重试策略可以限定到具体的结果，也应该这样设。给无人接听的人回拨是正常操作。给当面挂你电话的人回拨不是，给打不通的号码再拨一次是把钱花在同一个失败上。

把结果明确设置好——「全部重试」的默认值，就是把一场活动变成一场投诉的东西。

我们推荐的模式，也是我们自己运行的模式：定义一个字段，把需要人工跟进的通话标记出来，然后让团队去消化这份名单。

它比实时转接好，理由和来电那篇一样——转接需要有人在那一瞬间有空，而没人空着的时候，对方只是被转给了一台响铃的电话。一通被标记的电话，意味着一次完整的对话，外加一条已经按优先级排好的回拨队列。

自动诊断会同时对队列做优先级排序，而设了会成为标签的字段，会把你自己定义的值变成收件箱可以筛选的东西。

一通结束的电话是一个可以启动工作流的事件，所以后续动作不是一份固定的功能清单。更新联系人。把结果发给该负责的人。把有兴趣的人加进列表，其余的加进抑制名单。安排跟进。写进你自己的系统。

同一个事件也覆盖聊天对话的关闭，所以为电话写的工作流，通常不用改就能用在你的其他渠道上。

营销活动的结果也会连同其他一切一起落到 /conversations——转录、录音、字段、优先级。营销活动不是一个需要专门去找的报表，这一点很重要，因为需要专门去找的报表，就是没人会读第二遍的报表。