回一句“处理 #2”,事情就办了。

业务摘要是一份简短的循环简报,分三部分——哪些需要你、发生了什么、机会在哪儿——由你的对话、营销活动和工作流汇总而成。它就是一封普通邮件,所以回一条指令给它,就是你处理它的方式。

这份摘要用的是你套餐里已含的额度,内容也是从你本来就有的工作里汇总出来的。没有额外的报表付费模块。

你的这一周 —— 有 4 件事需要你 发给 you@harbourdental.com · 周一 07:00 · 已避开你的免打扰时段

需要你处理

  1. 1Northvale 已经问了三次三月对账单,还没有人回复。
  2. 2“周六营业时间”这个问题出现了 9 次。知识库里没有任何内容涵盖它。
  3. 3你的提醒营销活动有 31 通无人接听,正等你决定要不要重拨。

发生了什么

184 条对话,其中 147 条没用你出手就处理掉了。六通下班后的来电,全都留了转写记录。网站聊天挂件带来两位新联系人。

机会

有 22 位三月预约过的人再没回来。这是你这一季度还没联系过的最大一群人。

你的回复 处理第 2 项 —— 把周六营业时间加上去,另外给第 3 项的那 22 位发短信,说一下春季优惠。
它就是一封普通邮件,而这正是整个设计的核心。回一句指令就是你采取行动的方式 —— 而发短信那一半仍然会停下来要一组确认码。

或者,直接开口问

这份摘要本身就是操作界面。

三个部分,回复它就是你采取行动的方式。

from:octo 摘要
Octo周一简报:3 件需要你 — 外加已经发生的事,和一个机会上午 7:00
Octo回复:周一简报——已完成 — 你回复里的两件事都办好了上午 7:22
Octo上周一的简报 — 2 件需要你,都已了结周一

Inbox周一简报:3 件需要你

OOcto上午 7:00

需要你:1. Kepler 的退款决定 · 2. bookings@ 的授权快到期 · 3. 一位来电者点名找你。已发生:214 条会话,3 个营销活动,1 次工作流失败。机会:有九个人问到周六。

D上午 7:19

把第 2 件修好。Kepler 那笔就退。另外把周六营业时间加到问候语里。

Octo在线
工作流失败是怎么回事?上午 8:02 ✓✓
是非工作时间自动回复那个——第 4 步从你的 CRM 收到 503。有九条记录没落进去。上午 8:02
周六这事是真需求还是噪音?上午 8:04 ✓✓
七天里在电话和 WhatsApp 上有九个不同的人问到。这是从会话里数出来的,不是凭感觉总结的。上午 8:04
周三也发一份上午 8:06 ✓✓
周一和周三上午 7 点发。不管哪天,它都遵守你的免打扰时段。上午 8:06
消息
#omniocto4 位成员
MRMarcus上午 7:40

@Octo 简报除了发邮件,也发到这里

OOctoAPP上午 7:40

处理中 🔧(正在执行get_analytics…)

每天上午 7 点会发到这儿,还是那三个部分。处理方式也一样——直接回复就行。 (edited)

🎉 3

2 条回复 · 最后回复于 5 分钟前

DWDana上午 7:55

花费超过 80% 也提醒我们一下

消息 #omniocto

邮件 octo@agent.omniocto.com · WhatsApp 1-MAN-ASK-OCTO · Slack #omniocto

三个部分

不是仪表盘。是一份简报。

报表都是扫两眼就关掉。这一份是写来在手机上两分钟读完、并且顺手就处理掉的。

需要你处理

那些不会自己了结的事——一位还在等的客户、一条停掉的自动化流程、一个只有你能拍板的决定。

发生了什么

用一段话讲完这一周。多少通对话、都是关于什么的、有哪些没经过你就处理掉了。

机会

那个值得动手的规律——五位客户都问过的同一个问题、一群值得回访的人、一件你老是要手动回答的事。

它就是一封普通邮件,这就是整个设计。回复它,就是你处理它的方式。

实际用起来是怎样的

它送到、你回复、它调整。

1

它送到

频率跟着你这一周的节奏走。

一份三段式的简报,在你醒着的时间到,而你不用去搭一张报表。

2

回复它

“处理 #2”就是一条完整的指令。

像回同事一样回这封邮件。那一条就变成 Octo 去执行的任务,而凡是要花钱的,都会先停下来等一个确认码。

“处理 #2——另外给 #3 里的那三个人发短信,说说周六的时段。”
3

它会调整

清闲的一周,邮件就短一些。

频率跟着实际发生的事情走,所以它不会变成那封你不看就归档掉的每日邮件。

✓ #2 已处理 · 3 条短信排队等你确认

底下实际发生的事

为什么这一封不会被你过滤掉。

回复就是操作界面

这份摘要是一条真实邮件线程上的真实邮件,所以回复里的一条指令是会被执行的。没有另一个应用要打开——而这正是大多数内部报表没人看的原因。

回复即执行 · 确认机制照旧生效

事实是查出来的,不是总结出来的

汇总步骤直接读你的数据,而不是去读通话记录;一旦这一点变了,测试就会让构建失败。你拿到的是一份建立在计数和状态之上的简报,只经过一次写作加工——而不是一层层摘要之后越走越偏的东西。

直接汇总数据 · 由测试强制保证

频率会自适应

它跟着实际发生了多少事走,而不是不管怎样每天早上都发一份一模一样的简报。要避开的失败方式,就是那种人人自动归档的报表。

自适应频率

免打扰时段是被遵守的

摘要和提醒都会在你醒着的时候到。凌晨三点被通知,应该是你自己选的,而不是因为越过了某个阈值就发生的事。

免打扰时段 · 你的时区

紧急的事不会等它

故障提醒和预算提醒会在发生的当下触发,分别在预算的 50%、80% 和 100% 时。摘要是总结;提醒才是打断。

故障提醒 · 50/80/100% 预算提醒

常见问题

大家真正会问的问题。

里面到底有什么?
三个部分。哪些需要你——那些不会自己了结的事。发生了什么——用一段话而不是一张图表讲完这一周。还有一个机会,也就是你的对话里显出来的、值得去做点什么的规律。
“回复处理 #2”是什么意思?
这份摘要是一封真实的邮件,所以回复就是你处理它的方式。回一条指令,指明是哪一条,它就变成 Octo 去执行的一件任务——不用开后台,不用建工单。凡是要花钱的,仍然会先停下来请你确认。
它是在读我所有的客户通话记录吗?
不是。事实是通过直接查询数据得到的,而且有一个测试:一旦汇总步骤开始去读通话记录,构建就会失败。它被刻意做成不是“摘要的摘要”。
是每周还是每天?
发送频率会随着实际发生了多少事而调整,而不是每天早上给你一份几乎空白、内容雷同的简报。清闲的一周不会产生和忙碌的一周一样多的邮件。
它会在凌晨三点发过来吗?
不会。免打扰时段是被遵守的,所以摘要和提醒都会在你醒着的时候到。
如果在下一份之前出了问题呢?
那是提醒该管的事,它们是分开的:故障提醒和预算提醒会在当下就触发,分别在预算的 50%、80% 和 100% 时,而不是等到下一份摘要。

开始

这周就收到第一份。

这份摘要用的是你套餐里已含的额度,内容也是从你本来就有的工作里汇总出来的。没有额外的报表付费模块。