直接进入 CRM 的呼叫记录可以解决非常具体的问题。
通话结束，但客户记录仍为空白。
有人记得反对意见。有人记得承诺的后续行动。有人记得客户提到过最后期限、预算问题或支持风险。
然后下一个通话开始。
后来，CRM票据就变成了重建工作。
这就是通话后管理从一项小任务变成对每一次客户对话的安静负担的地方。
何时应致电更新帐户
将通话输出转化为 CRM 就绪笔记
Superscribe Phone 可帮助通话成为经过审核的摘要、决策、任务、后续行动和帐户上下文，而不是稍后需要清理的另一份记录。
简短版本
CRM 不应该依赖于记忆。
与客户通话后，有用的部分应该落在它们影响的帐户、交易、票证或项目附近。
这通常意味着：
- 简短的通话摘要
- 涉及的帐户或联系人
- 发生了什么变化
- 决策
- 反对或风险
- 承诺的后续行动
- 任务所有者
- 日期和截止日期
- 账单或范围背景
- 下一个接触点
目标不是存储更多单词。
目标是让帐户中的下一个人知道发生了什么。
为什么 CRM 注释会被跳过
大多数团队不会跳过 CRM 注释，因为他们讨厌流程。
他们会跳过它们，因为调用创建工作的速度比团队记录下来的速度快。
一位代理机构负责人完成了客户通话并立即进入生产签到阶段。一名顾问挂断电话并加入销售电话。支持主管接听了一个紧急客户电话，然后又接听了另一个。 CRM 更新应该在通话后进行，但“通话后”已经消失了。
这就是为什么 CRM 笔记不是文字记录.
文字记录保留了谈话内容。 CRM 注释会更改帐户记录。
如果文字记录位于一个工具中，而 CRM 位于其他地方，团队仍然需要手动完成最后一英里。
CRM 笔记就是交接
一份好的 CRM 笔记不是日记。
这是一个交接。
它应该告诉下一个人：
- 为什么会发生这个电话
- 客户想要什么
- 自上次接触点以来发生了什么变化
- 承诺了什么
- 是什么仍然阻碍了进展
- 谁负责下一步
- 下一步何时发生
这与将文字记录粘贴到注释字段中不同。
文字记录可能包含答案。 CRM 注释应该会显示出来。
例如，这个注释很弱：
谈论了入职和后续步骤。
这条注释很有用：
客户希望将入职分为两个阶段，因为运营团队在 7 月 8 日之前都很忙。在周二之前发送较短的推出计划。风险：如果设置需要多个内部所有者，他们可能会暂停。
第二个注释给出了背景、时机、风险和下一步行动。
这就是 CRM 可以实现的输出。
“直接进入 CRM”意味着什么
“直接进入 CRM”并不意味着将每个单词都转储到记录中。
这应该意味着呼叫输出在到达 CRM 之前就已针对 CRM 进行了调整。
HubSpot 将呼叫、笔记、会议、任务、电子邮件和其他活动类型视为记录活动，这很有用，因为这些交互属于关系历史记录附近（HubSpot 知识库）。 Salesforce 还将记录的呼叫视为活动记录，为团队提供了在呼叫后记录客户对话的位置（Salesforce 帮助).
困难的部分不是证明 CRM 可以存储呼叫活动。
困难的部分是在上下文仍然新鲜的情况下将正确的呼叫活动放入正确的记录中。
这意味着在任何人单击“保存”之前，通话记录应回答四个问题。
这属于哪条记录？
该注释应与正确的客户、公司、机会、票据、事项或项目相关联。
如果该便条落在一般成绩单收件箱中，则很容易忘记。如果它出现在帐户记录中，它就成为关系的一部分。
发生了什么变化？
许多电话并不重要，因为它们已经发生了。
它们很重要，因为有些事情发生了变化。
客户认可的范围。买家提出了定价问题。候选人更改了可用性。客户找到了解决方法。利益相关者推迟了最后期限。
无需阅读完整的调用，该更改就应该可见。
需要采取什么行动？
CRM 说明应将事实与后续行动分开。
如果有人承诺发送定价、预订演示、写票证、更新提案或确认日期，则该操作属于注释中的操作。
更好的是，它应该准备好成为一项任务。
团队稍后应该知道什么？
有些细节不是任务，但它们仍然很重要。
预算压力。提及竞争对手。情感上的反对。一种支撑模式。客户用来描述问题的短语。
当凭记忆写笔记时，这些细节很容易丢失。
为什么转录优先工作流程会产生 CRM 债务
转录优先的工作流程感觉很完整，因为它们创建了一个大工件。
但一个大的文物可能会隐藏工作。
如果团队必须打开记录，搜索有用的部分，决定帐户记录中的内容，重写它，创建任务，然后保存所有内容，那么管理负担只会转移。
债务稍后显示为：
- 模糊的账户历史记录
- 陈旧的机会
- 从未发生过的后续行动
- 依赖于内存的切换
- 支持没有呼叫上下文的工单
- 项目记录中缺少客户承诺
- 下班后几天写的帐单
这就是为什么一个 商务通话记录应用程序 应该根据它创建的输出来判断，而不仅仅是它记录的音频。
调用注释应该接近它所影响的工作。
实用的 CRM 通话记录格式
如果您的团队仍在手动编写笔记，请使用足够短的格式，以便在每次通话后完成。
试试这个：
上下文
为什么会发生通话？
例子：
每周为网站迁移进行客户交付检查。
改变
现在有什么不同？
例子：
客户批准了发布日期，但希望在最终内容通过之前完成分析质量检查。
决定
决定了什么？
例子：
发布日期仍为 6 月 28 日。报告仪表板进入第二阶段。
跟进
需要采取什么行动？
例子：
在周一之前发送修订后的启动清单。将分析 QA 分配给 Mira。在下一个提案中确认仪表板范围。
风险
什么会破坏计划？
例子：
法律审查可能会延迟主页副本的批准。
下一个接触点
下一次对话应该在什么时候进行？
例子：
在周三的电话会议上审查启动清单。
这足以让其他人了解该帐户，而无需重播通话。
Superscribe 的定位
Superscribe 是为对话和后续工作之间的间隙而设计的。
对于经常使用电话的团队来说，有用的工作流程是：
- 捕捉通话。
- 将其转化为结构化输出。
- 查看结果。
- 将有用的部分移至 CRM、任务、跟进、票证或帐单中。
这也是同样的原因 电话记录和会议记录 不应被视为相同的工作流程。
会议记录通常支持对齐。
电话记录常常会产生运营工作。
如果电话更改了帐户，CRM 应该在当天处理详细信息之前反映出来。
测试
下一次客户致电后，打开 CRM 记录并询问一个问题。
明天其他人可以在不问我发生了什么事的情况下领取这个帐户吗？
如果答案是否定的，则说明尚未完成。
解决办法不是更多的转录。
从调用到帐户上下文的路由更好。
直接进入 CRM 的通话记录并不是为了保持完美的记录。它们是为了在通话结束后保持关系可用。