压根就不会有人去学我们的软件。

客服系统、外呼工具、聊天平台。真实的客户与庞大的用量。当年我们为这些工作感到骄傲，今天依然如此。

可是，每当这些客户想要点什么，需求总会落到我们头上。

不是落到某个设置页面，而是直接落在我们身上。我们会有一个大活人去读邮件，打开客户的账号，替他们把事办好，再回信告知。这不是产品做失败了，产品本来就是这么设计的，几乎所有企业软件也都是这么运转的。在我们做上一代产品的大部分时间里，根本没得选。

但现在有得选了。所以，在介绍 Omni Octo 能做什么之前，不妨先由我们这些亲历者来说说，上一代产品到底错在了哪里。

一

系统本来就能做，只是客户够不着。

客户开口要的，几乎从来都不是什么还没做出来的新功能。

软件通常早就具备这些能力。它们只是藏在某个没被发现的菜单里，或是一张客户不知该怎么拉的报表里，又或者是一个必须先知道名字才搜得到的设置项里。功能都在，几个月前就上线了，我们甚至还发过公告。

由于找不到，客户只能做唯一能做的事：来找我们。

解决这种需求既不需要研发，也不需要发版部署，更不需要任何人写哪怕一行代码。即便如此，它依然要经历一整套流程：发一封邮件、分派给一个人、在队列里排队，最后在周四等来一个答复。

如果真是新功能需求，那这种等待无可厚非。做新东西总是需要时间的，对我们如此，对任何人都不例外。对于这种等待，我们能接受，客户也能理解。

真正值得深究的是剩下的那 90%：软件明明做得到，缺的仅仅是知道该怎么做。

这条链路上的每个人都不是故意拖延。负责回邮件的同事业务精湛，也很在乎结果。排队更不是团队的失职。只因为在客户的问题和系统早已存在的答案之间，这是我们修出的唯一一条路。

然而，还有一笔无人计算的成本，那就是那些从未被问出口的问题。

一旦“提问”有了成本，大家就不再为小事开口了。他们宁愿让一个表现有偏差的 agent 错上几个月，也不愿意为了一点小小的改善去搭上两天时间，外加折腾一长串邮件。系统里提交上来的每一张工单我们都看得见，但那些被客户自己咽下去、觉得“不值当提”的改进需求，我们却一无所知。而那才是真正庞大的冰山底座。

二

他们的数据，锁在我们的楼里。

有位客户跑了一场几百通电话的外呼任务。结束后他们跑来告诉我们，效果很差。

我们问怎么看出来的。对方发来了十五段录音。

几百通电话，只有十五段录音。不是他们刻意挑刺，而是因为一个人花整整一下午时间，纯靠肉耳听，也就只能听完这十五通。剩下的录音都在系统里，不仅录了音，还做了转写，完完整整地存着。

他们想要的每一个答案，其实全在数据里。有多少人接了电话？多少人听到了最后？大家通常在聊到哪一步时陷入沉默？究竟是哪一个问题把所有人都问懵了？甚至，让他们火冒三丈的那个小插曲，到底只发生了六次，还是足足出现了四百次？

回答这些问题根本不需要我们开发任何新东西。需要的只是一个知道如何向数据提问的人。但尴尬的是，这个人坐在我们办公室里，不在客户那边。

结果，我们和客户的交流根本算不上数据分析，变成了双方各执一词的盲人摸象。他们手里只有那十五个反面案例，因为那是他们唯一能抓到的把柄。

我们建了一个系统，它一丝不苟地攒齐了改进自身所需的所有证据，却把它们锁死在了连数据主人都发问无门的地方。

这根本不是什么存储技术问题。它决定的是，一个客户究竟能不能在一个平凡的周二下午，靠自己查出问题的答案，还是说必须得先向别人费力解释一番，然后慢慢等。

三

配置成了一份标准答案。

一位客户带了一张表格来找我们。表里把紧急程度分了三档，每一档罗列了四五十种情况，每一行都严格规定了对应的话术。

他们拿这种东西来无可厚非。那是他们沉淀下来的行业经验。他们对自身业务的理解是我们永远赶不上的，拿出这张表，说明他们已经把最难的那部分脑力活做完了。

于是我们照单全收，把它写进了配置里。一种情况对应一种回复，严丝合缝。然而就在配置生效的那一刻，两件我们始料未及的事情发生了。

首先，这张表格成了一份标准答案。它变成了系统“应该”怎么说话的白纸黑字。这意味着，任何偏离表格的临场发挥，按定义都成了一种缺陷。“我明明写了该这么说，它为什么要那么回？”既然我们已经接纳了这份文件，客户这么质问就完全合情合理。这也意味着，除非重新商定这份表格，否则系统就再也没有改进的余地。而在现实中，根本没人会去反反复复地重谈这一百五十行规则，所以系统实际上相当于被彻底锁死了。

其次，这张表只会无限膨胀。每一个边缘场景、每一种突发状况、每一句“能不能把这个也处理一下”，都会化作表格里的新一行。而每加一行，我们就得为这个客户无休止地维护下去。这份配置变成了一纸永远不会到期、且只增不减的契约。

客户想要的从来就不是那一百五十行死规矩。他们想要的，是那些规矩试图捕捉的临场判断力。

“重视客户的情绪。适时追问细节。分得清轻重缓急。”其实所有的指令都在这里了，三句话就能概括。那张巨大的表格之所以存在，仅仅是因为当时我们没有办法把这三句话直接讲给软件听并让它听懂。于是，那种活生生的判断力只好被生硬地拍扁，靠人工提前翻译成死规则，然后永远冻结在那里。

四

有些东西，我们打一开始就不该做。

在那类表格里，有这么一行：当电话那头的人透露自己感到孤独时，系统被规定要立刻追问对方，最近这种感觉出现了几次、分别是什么时候，并要求对方详细描述。

如果把它当成一个数据采集步骤，这简直顺理成章。它能稳定产出一个结构化字段，而字段是可以用来生成报表的。

可是，想象一下电话那头是一个活生生的人。就在他刚刚鼓起勇气向一个陌生人承认自己很孤独之后的几秒钟，听到这样冰冷机械的盘问，那该有多残忍。它硬生生地把整段对话里唯一闪烁着人性微光的时刻，抹杀成了一次毫无感情的数据库写入。

对于那个需求，我们拒绝了。再来一次，我们还是会拒绝。

有些对话之所以有分量，恰恰是因为有人愿意花心思去投入。把这种对话自动化并不能批量复制关怀，只会把真正抚慰人心的那部分彻底剔除。

如果一个 agent 能帮人处理排期、提醒、跟进、做笔记以及处理文书，从而为那些真正有价值的对话腾出空间，这绝对功德无量。但如果一个 agent 妄图去替代这些对话本身，那就是另一款居心不良的产品了。我们对做这种东西毫无兴趣。

五

他们不想学。他们只想问。

这是六年的血泪史教会我们的事。我们悟得很慢，甚至连顺序都弄反了。

首先我们发现，客户根本不去学软件的界面。不仅不学我们的，谁家的他们都不学。

回想一下那种感觉：有人把 Salesforce、HubSpot 或微软的某个企业软件塞到你手里，然后信誓旦旦地保证，你想要的功能全在里面。这话千真万确，但也毫无用处。软件本身并不难，只是里面的东西实在太多了。它们全都是按照开发者的脑回路排列组合的，想要吃透这套逻辑，本身就是个巨大的工程。而我们的客户每天还要忙自己的本职工作呢。

于是我们开始写文档。写了海量的文档。每个功能都配一篇 wiki，有操作指引，有超长的视频教程。我们建起了一整个知识库，并且时刻保持更新。内容精准，条理清晰，我们自己看了都觉得满意。

可客户压根不看。

客服队列里塞满了早就写过答案的问题。不是偶尔几个，而是绝大多数。这些答案要么就躺在我们写好的某一页文档里，要么就藏在点三下鼠标就能打开的菜单中。有很长一段时间，我们盲目地以为这只是文档写得不够好，于是闷头写了更多的文档。

其实这从来就不是文档的问题。它和界面难用是同一个毛病，只不过换了张皮。一篇 wiki，本质上是通往另一个人思维模型的索引。去读它，固然比死记硬背菜单要轻松些，但这依然是一项任务。最致命的是，这是一项关于我们的任务，而不是关于客户自己工作的任务。

没人有闲工夫去钻研另一家公司的产品、死记另一家公司的菜单、翻阅另一家公司的 wiki。大家都有自己的正经事要干。

所以，人们转而采取了另一种方式，也是人类最古老的一种习惯。

他们直接开口问。

问这个按钮是什么意思。问系统刚刚为什么出错。或者干脆问，能不能直接帮我把这事办了。

人与人之间一直就是这么打交道的 —— 不管对方是朋友、孩子、老师、学生，还是同事、下属、董事会成员。你听说过谁去查阅关于同事的“使用说明书”吗？你直接问，对方直接答，事情需要办就顺手办了。“问”绝不是懒人不愿读书的捷径。自打有人类以来，这就是我们彼此之间最天然的交互界面，而且好用得令人发指：它不需要任何培训，第一天就能上手；它能包容各种词不达意的描述；最重要的是，它允许你用自己习惯的词汇去表达诉求，而不是被迫咀嚼别人强加给你的术语。

那些明明能在 wiki 里找到答案却依然提了工单的客户，并不是在“误用”我们的软件。他们只是在本能地调用自己真正拥有的那个界面。

只不过，在这个界面的另一头，站着的不是一个随叫随到的系统。

他们问到的是我们公司里的一个大活人。而活人面前是有工单队列的，活人是有时区差异的，活人是要过周末的。于是需求一旦递进来，漫长的等待就开始了。这无尽的等待，正是最沉重的代价。

客户想要的是立刻解决。甚至是昨晚就该搞定。可他们实际等到的，却是下周四的回复。

他们既不想苦苦等着别人替自己搞定，也不想为了自己搞定而去啃大部头的教程。上一代产品只能提供这两个憋屈的选项。面对这两个选项，客户感到不爽，那是理所当然的。

因此，我们现在给自己定下的及格线，已经跟当年截然不同了。

一项功能，代码跑通了不算完工。加了个设置页面不算完工。补齐了一整页的说明文档更不算完工。真正的完工，是当你用自己的话把诉求说出来 —— 就像你平时跟同事交代工作那样，而不是绞尽脑汁去猜我们给功能起了什么鬼名字 —— 此时 agent 能精准听懂你的意图，告诉你它打算怎么干，然后利索地把事办妥。

差一丝一毫，本质上依然是在逼着人先去学我们的产品。