從來就沒有人會去學我們的軟體。

客服中心軟體、行銷活動工具、聊天平台。真實的客戶、龐大的用量，當年我們對這些心血感到自豪，至今依然如此。

然而，每當這些客戶有任何需求，事情總會落到我們頭上。

不是落到某個設定頁面，而是落在我們身上——要由我們這邊的大活人去讀信、打開帳號、替他們處理好，再回信告知。這不是產品設計失敗，產品本來就是這樣運作的，而且幾乎所有企業軟體都是如此。在我們開發上一代產品的大半歲月裡，根本沒有其他選擇。

但現在有了。因此，在介紹 Omni Octo 能做什麼之前，讓我們先以過來人的身分，談談我們以前做的產品到底哪裡出了問題。

一

系統明明做得到，他們卻找不到。

客戶開口要求的，幾乎從來不是什麼根本不存在的新功能。

通常是軟體早就能做到的事，只是藏在他們沒發現的選單裡，或者是一張他們不知從何拉起的報表，又或者是一個必須先知道確切名稱才能搜尋到的設定。功能一直都在，幾個月前就上線了，我們甚至還發過公告。

所以他們只能做唯一能做的事：來問我們。

而這個需求——不需要工程師介入、不牽涉發布或部署，更不用任何人寫半行程式碼——依然得走過一整套流程：發一封電子郵件、交給專人處理、在佇列裡慢慢排，最後在星期四等來一個答覆。

如果這真的是新功能需求，那等待是理所當然的。開發新東西需要時間，對我們如此，對任何人也都一樣。這種等待我們能接受，客戶也能理解。

真正值得深思的是剩下的那百分之九十：軟體明明已經具備這個能力，唯一缺少的只是「知道怎麼做」。

整個流程裡沒有人是故意在拖延。負責回信的同事能力很強，也很在乎結果。要排隊也不是團隊失職——只因為在客戶的疑問與系統既有答案之間，這是我們打造出的唯一途徑。

然而，沒有人算過另一筆隱形成本：那些從未被問出口的問題。

當「提問」的代價太高，人們就不會再為了小事開口。他們寧可忍受一個稍微有點偏差的 agent 幾個月，也不願為了一點微調耗上兩天時間外加一串信件往返。系統裡收到的每一張工單我們都看得見，但那些被客戶自己吞下去、覺得「不值得麻煩」的改善需求，我們卻一無所知——而那才是真正龐大的黑數。

二

他們的資料，鎖在我們的大樓裡。

有位客戶執行了一檔幾百通電話的行銷活動。事後他們跑來跟我們說，成效很糟。

我們問怎麼知道的。對方傳來了十五段錄音檔。

幾百通電話，只有十五段。不是他們刻意挑毛病，而是因為一個人花上整個下午，用肉耳聽完的極限就是十五通。剩下的錄音其實都在，不僅錄了音、轉成文字，還完完整整地存在系統裡。

他們想要的所有解答，全在那些資料裡。有多少人接起電話？多少人聽到了最後？大家通常在對話的哪個環節陷入沈默？究竟哪個問題把所有人都搞糊塗了？讓他們很不滿的那個小插曲，到底是只發生了六次，還是足足出現了四百次？

要回答這些問題，根本不需要我們開發任何新東西。只需要一個懂得如何向資料提問的人。但尷尬的是，這個人坐在我們辦公室，不在客戶那邊。

結果，我們和客戶的對話根本稱不上是分析，而是雙方拿著片面的特例各執一詞——而他們手裡只有那十五個因為表現差而被挑出來的極端案例。

我們建置了一個系統，它一絲不苟地收集了所有能用來改善系統本身的證據，卻把它們鎖死在連資料主人都無法過問的地方。

這根本不是儲存架構的問題。它決定的是，一個客戶究竟能不能在一個平凡的星期二下午，靠自己查出問題的答案，還是必須先費力向別人解釋一番，然後慢慢等。

三

設定檔變成了一份標準答案。

有位客戶帶著一份試算表來找我們。表裡把緊急程度分為三級，每一級羅列了四、五十種情境，每一列都硬性規定了對應的話術。

他們拿這種東西來完全合情合理。那是他們寫下來的專業知識——他們對自己領域的了解是我們永遠比不上的，拿出這份試算表，代表他們已經把最困難的腦力活做完了。

於是我們照單全收，將它寫進設定裡。一種情境對應一種回覆，嚴絲合縫。然而就在我們這麼做的那一刻，發生了兩件我們始料未及的事。

首先，這份試算表變成了一份標準答案。它變成了系統「應該」怎麼說話的白紙黑字。這意味著，任何偏離這份文件的對話，按照定義都成了一種瑕疵。「我明明寫了應該這樣說，它為什麼那樣回？」既然我們已經同意了這份文件，客戶這樣質問就完全合理。這也代表，除非重新協商這份文件，否則系統就無法再進步——而在實務上，根本沒有人會去反覆重談那一百五十列的規則，所以系統等同於被徹底凍結了。

其次，這份表只會無限膨脹。每一個邊緣情況、每一種新情境、每一句「能不能把這個也處理一下」，都會變成試算表裡的新的一列。每增加一列，我們就得為這個客戶無休止地維護下去。這份設定檔變成了一紙永遠不會到期、且只增不減的合約。

客戶想要的從來不是那一百五十列的死規矩。他們想要的，是那些規矩試圖捕捉的判斷力。

「認真看待這件事。適時追問細節。分得清輕重緩急。」這其實就是全部的指令，三句話就能說完。這份龐大的試算表之所以存在，僅僅是因為當時我們沒有辦法把這三句話直接講給軟體聽並讓它聽懂——因此這種判斷力只好被生硬地拍扁，靠人工事先翻譯成死規則，然後永遠凍結在那裡。

四

有些東西我們打從一開始就不該做。

在那份試算表裡有這樣一列：當電話那頭的人透露自己覺得很孤單時，系統被規定要立刻追問對方，最近這種感覺出現了幾次、分別是什麼時候，並要求對方詳細描述。

如果把它當作一個資料蒐集步驟，這簡直理所當然。它能穩定產出一個結構化欄位，而欄位是可以拿來產生報表的。

可是，想像一下電話那頭是一個活生生的人。就在他剛剛鼓起勇氣向一個陌生人承認自己很孤單之後的幾秒鐘，聽到這樣冰冷機械的盤問，這有多麽荒謬且殘忍。它硬生生地將整段對話裡唯一閃爍著人性微光的時刻，抹殺成了一次資料庫寫入動作。

針對那個需求，我們拒絕了。再來一次，我們還是會拒絕。

有些對話之所以重要，正是因為有人願意花心思去投入。將這些對話自動化並不能量產關懷，只會把真正發揮作用的那部分給抽離掉。

如果一個 agent 能幫忙處理排程、提醒、後續跟進、做筆記以及處理相關的行政庶務，從而為這些真正有價值的對話騰出空間，這絕對功德無量。但如果一個 agent 妄想去取代這些對話本身，那就是另一款居心不良的產品了，我們對開發這種東西毫無興趣。

五

他們不想學。他們只想問。

這是六年的血淚史教會我們的事，我們領悟得很慢，而且順序還搞反了。

首先我們發現，客戶根本不會去學軟體的介面。不是不學我們的，是誰家的都不學。

回想一下那種感覺：有人把 Salesforce、HubSpot 或任何微軟的企業軟體塞給你，然後告訴你，你需要的東西都在裡面某處。這句話千真萬確，但也毫無用處。軟體本身並不難，只是裡面的東西實在太多了，而且全都是按照開發者的邏輯排列組合的。想搞懂這套邏輯，本身就是個浩大的專案。而我們的客戶早就有自己的正職工作要忙了。

於是我們開始寫文件。寫了海量的文件。每個功能都配一篇 wiki，有操作教學、長篇影片，我們建起了一整個知識庫，並且隨時保持更新。內容準確、架構清晰，我們自己對此相當滿意。

可他們根本不看。

然後客服佇列裡塞滿了早就解答過的問題。不是少數幾個，而是絕大多數。這些問題的答案，要麼就躺在我們寫好的某一頁文件裡，要麼就藏在點三下滑鼠就能打開的選單中。有很長一段時間，我們誤以為這只是文件寫得不夠好，於是悶著頭寫了更多的文件。

其實這從來就不是文件的問題。這跟介面難用是同一個毛病，只是換了個形式。一篇 wiki，本質上是通往另一個人思維模型的索引。去讀它，固然比死記選單要輕鬆一點，但這依然是一項專案，而且是一項關於我們的專案，而不是關於他們自己工作的專案。

沒人有心力去學習另一家公司的產品、另一家公司的選單，以及另一家公司的 wiki。大家都有自己的工作要做。

所以，人們改採另一種方式，這也是人類最古老的一種行為。

他們直接開口問。

問這是什麼意思。問剛剛為什麼會那樣。或者乾脆要求幫忙把事情辦好。

人與人之間一直都是這樣互動的——無論對方是朋友、孩子、老師、學生、同事、下屬，還是董事會成員。你從來沒聽說過誰去查閱同事的「使用手冊」。你直接問，對方回答，如果事情需要處理，他們就順手辦了。「發問」絕不是懶得看書的人所走的捷徑。自從有人類以來，這就是我們彼此之間最常使用的介面，而且它好用得不可思議：完全不需要培訓，第一天就能上手；它能包容模糊不清的問題；最重要的是，它讓你用自己真正擁有的詞彙來描述問題，而不是被迫使用別人挑選的專有名詞。

那些明明能在我們的 wiki 裡找到答案，卻還是開了工單的客戶，並不是「不會用」我們的軟體。他們只是在使用他們真正擁有的那個介面。

我們只是沒有站在這個介面的另一端而已。

因為他們問到的，是我們公司裡的一個人。而這個人面前有工單佇列，有時區差異，還有週末要過。於是需求一旦送出，漫長的等待就開始了——而這無盡的等待，就是最沉重的代價。

他們希望現在就解決。或者昨晚就該搞定。但他們實際得到的，卻是下週四的答覆。

他們既不想花時間苦等別人做好，也不想花時間學習怎麼自己做好。上一代產品只能提供這兩個選項，而我們的客戶對這兩者都不滿意，這是完全合理的。

因此，我們現在對自己設下的標準，已經和過去截然不同。

一項功能，程式碼能跑不代表完工。有一個設定頁面不代表完工，有一整頁的文件說明更不代表完工。真正的完工，是當你能用自己的話描述你想要什麼——就像你跟同事交代工作時用的詞彙，而不是我們剛好給這個功能取的什麼鬼名字——這時 agent 能精準聽懂你的意思，告訴你它打算怎麼做，然後乾淨俐落把事情辦妥。

差那麼一點點，本質上都還是要求別人先來學習我們的產品。