誰も私たちのソフトウェアを学ぼうとはしませんでした。

コンタクトセンターのソフトウェア。キャンペーンツール。チャットプラットフォーム。本物の顧客、膨大な利用量。私たちは当時の仕事に誇りを持っていましたし、それは今も変わりません。

しかし、顧客が何かを求めたとき、そのリクエストは毎回私たちの元へ届きました。

設定ページにではなく、私たちの元へ。社内の人間がメールを読み、アカウントを開き、作業を行い、返信する。それは失敗ではありませんでした。製品は設計通りに動いており、そしてそれは、ほぼすべてのビジネスソフトウェアの仕組みそのものでした。私たちが開発していた時期の大半において、他に選択肢はなかったのです。

しかし、今は違います。ですから、Omni Octoで何ができるかをお話しする前に、私たちが過去にやってきたことの何が間違っていたのかをお伝えします。それを作った張本人たちの言葉で。

その一

機能はすでにありました。ただ、顧客には届かなかったのです。

顧客からのリクエストが、まだ存在しない新機能であることはほとんどありません。

大抵の場合、それはソフトウェアがすでにできることです。ただ、顧客が見つけていないメニューの奥にあったり、作成方法がわからないレポートだったり、事前に名前を知らなければ検索すらできない設定項目だったりするだけです。機能自体は存在し、何ヶ月も前にリリースされ、私たちも告知していました。

そのため、彼らは唯一できる行動を取ります。私たちに頼むのです。

開発も、リリースも、デプロイも、たった1行のコードを書く必要すらないリクエスト。それでも、メールが送られ、担当者が割り当てられ、キューに並び、木曜日になってようやく回答が届くというプロセスを経ることになります。

もしこれが本当に新機能のリクエストであれば、待たせるのも誠実な対応と言えます。新しいものを作るには時間がかかります。それは私たちでも、他の誰であっても同じです。その待ち時間に対しては、私たちも顧客も異論はありません。

深刻なのは、残りの90パーセントです。ソフトウェアにはすでにできるのに、単に「やり方を知らない」というだけで起きているケースです。

この連鎖の中で、わざと遅くしている人は誰もいません。メールに返信するスタッフは優秀で、結果に責任を持っていました。キューが溜まるのはチームの落ち度ではありません。顧客の疑問と、システム内にすでに存在する答えとを結ぶルートを、私たちがそれしか作っていなかったからです。

そして、誰も計算に入れていないコストがあります。それは、決して口に出されることのなかった質問です。

質問すること自体にコストがかかるようになると、人々は些細なことを尋ねなくなります。少し的外れなagentを何ヶ月も使い続けます。なぜなら、それを少しだけマシにするために、2日間の待ち時間と長いメールのやり取りを費やす価値はないからです。私たちは、提出されたチケットはすべて把握していました。しかし、「わざわざ頼むほどではない」と顧客が諦めた改善案を見ることはありませんでした。そして、その数の方が圧倒的に多かったのです。

その二

彼らのデータが、私たちの建物に閉じ込められる。

ある顧客が、数百件の電話をかけるキャンペーンを実施しました。終了後、彼らは結果が悪かったと報告してきました。

どうして分かったのかと尋ねると、15件の録音データが送られてきました。

数百件のうちの、たった15件。都合の良いデータを選んだわけではなく、1人の人間が午後の時間を使って手作業で聞ける限界が15件だったからです。残りのデータも存在していました。録音され、文字起こしされ、保存され、すべて揃っていました。

彼らが求めるすべての答えは、その中にありました。何人が電話に出たか。何人が最後まで聞いたか。会話のどの部分で沈黙したか。どの質問が全員を混乱させたか。彼らを怒らせたあの小さな問題は、6回起きたのか、それとも400回起きたのか。

それに答えるために、私たちが何かを開発する必要はありませんでした。データに対してどう質問すればいいかを知っている人が必要だっただけです。しかし、その知識を持った人間は顧客のオフィスではなく、私たちのオフィスにいました。

その結果、彼らとの会話は分析とは呼べないものになりました。双方が限られたエピソードを元に議論を戦わせるだけでした。彼らが持っていたのは、結果が悪かったという理由で選ばれた、わずか15件の事例だけだったのです。

私たちは、改善に必要な証拠を完璧に蓄積するシステムを作り上げました。しかし、その証拠をデータの持ち主がアクセスできない場所に閉じ込めてしまったのです。

これは単なるストレージの話ではありません。顧客が、ありふれた火曜日の午後に自分の疑問を自力で解決できるのか、それとも、まず誰かに状況を説明して待ち続けなければならないのか、それを分ける決定的な問題なのです。

その三

設定ファイルが「模範解答」になる。

ある顧客がスプレッドシートを持ってやって来ました。緊急度が3段階に分かれ、それぞれに40から50の状況がリストアップされ、すべての行に決められた対応が記載されていました。

これを私たちに持ち込むのは、完全に理にかなっています。それは彼らの専門知識を書き起こしたものです。現場のことは、私たちよりも彼らの方がはるかに深く理解しています。このスプレッドシートは、彼らが最も困難な思考作業を終えたという証拠でした。

だから私たちは、それをそのままシステムに組み込みました。状況、対応、状況、対応と。しかしそうした瞬間、私たちの思いもよらない2つのことが起きました。

第一に、そのスプレッドシートが「模範解答」になりました。システムがどう発言すべきかを記した公式記録となり、そこから外れた会話はすべて定義上「不具合」として扱われるようになりました。「こう言うように設定したはずなのに、なぜ違うことを言ったのか？」 私たちが合意した文書がある以上、そう問われるのは当然です。そしてこれは、文書を再交渉しない限りシステムの改善ができなくなったことを意味しました。150行ものルールを何度も再交渉する人などいないため、実質的に改善不可能になったのです。

第二に、ルールは増える一方でした。例外ケース、新しい状況、「これも対応してくれないか」という要望が出るたびに、行が追加されていきました。一行増えるごとに、たった一人の顧客のために私たちが無期限で保守すべきものが増えました。その設定ファイルは、終了日が存在せず、ただ肥大化し続けるだけの契約書と化していました。

顧客が本当に欲しかったのは、150行のルールなどではありません。その行を通じて言語化しようとしていた、「臨機応変な判断力」だったのです。

「真摯に受け止めること。適切に質問を重ねること。緊急時を見極めること。」実は、指示のすべてはこれだけであり、たった3つの文に収まります。あの巨大なスプレッドシートが存在した理由は、その3つの文をソフトウェアに直接伝えて理解させる方法がなかったからです。だからこそ、生きた判断力をあらかじめ手作業で規則に落とし込み、そこで凍結させるしかなかったのです。

その四

そもそも作るべきではなかったもの。

先ほどのようなスプレッドシートの中に、相手が「孤独を感じる」と言った場合の行がありました。決められた対応は、最近そう感じた回数や時期を思い出させ、詳しく説明させるというものでした。

データ収集のステップとして見れば、これは完全に理にかなっています。構造化されたフィールドが生成され、それをもとにレポートを作成できるからです。

しかし、見ず知らずの他人に孤独を打ち明けた数秒後に、電話口で聞かされる人間の言葉として想像してみてください。これほどグロテスクなことはありません。会話の中で間違いなく人間らしさが宿ったその一瞬を、無機質なデータベースへの書き込み処理へと変えてしまうのです。

私たちはその要求を断りました。今でも同じように断るでしょう。

対話の中には、人が向き合うことを選んだからこそ意味を持つものがあります。それを自動化しても、配慮がスケールするわけではありません。本来機能していたはずの、人のぬくもりを削ぎ落とすだけです。

スケジュール調整、リマインダー、フォローアップ、議事録、そして対話に付随する事務作業を処理するagentは、人が向き合うための時間を作り出します。それには計り知れない価値があります。しかし、対話そのものを処理しようとするagentは、全く別の、悪しき目的を持った製品です。私たちは、そのようなものを作ることに一切の興味がありません。

その五

彼らは学ぼうとはしない。ただ質問するのです。

これが、私たちが6年かけて学んだことです。私たちはこれを、間違った順序で、ゆっくりと学びました。

まず私たちが気づいたのは、顧客はインターフェースを学ぼうとしないということでした。私たちのものだけでなく、誰のものもです。

SalesforceやHubSpot、あるいはMicrosoftのエンタープライズ製品を渡され、「必要なものはすべてこの中のどこかにある」と言われたときの気持ちを想像してみてください。その言葉は完全に真実ですが、まったく役に立ちません。ソフトウェア自体が難しいわけではありません。ただ、開発者の論理に基づいて配置された機能が膨大に存在するだけであり、その構造を学ぶこと自体がひとつの巨大なプロジェクトになってしまうのです。私たちの顧客には、すでに自分たちの本来の仕事がありました。

だから私たちはドキュメントを書きました。大量のドキュメントを。すべての機能に対するwikiページ、チュートリアル、長編の解説ビデオ。ライブラリ全体を構築し、常に最新の状態に保ちました。内容は正確で、見事に整理されており、私たち自身も満足のいく出来でした。

顧客はそれを読みませんでした。

そして、サポートのキューはすでに回答済みの質問で溢れかえりました。一部ではなく、大部分がそうでした。私たちが書いたページに答えがあるものや、3回クリックすれば届くメニューに関する質問ばかりでした。長い間、私たちはこれをドキュメントの問題だと捉え、さらに多くのドキュメントを書くことで対処しようとしていました。

しかし、それは決してドキュメントの問題などではありませんでした。インターフェースの問題が、もう一つ上の層に移動しただけだったのです。wikiとは、他人の思考モデルを読み解くための索引です。それを読むことは、メニューの構造を学ぶよりは小さなプロジェクトかもしれませんが、それでもプロジェクトであることに変わりはありません。そしてそれは、顧客自身の仕事ではなく、私たちに関するプロジェクトだったのです。

他社の製品、他社のメニュー、他社のwikiを学ぶ余裕など、誰にもありません。彼らには彼ら自身のやるべき仕事があるのです。

では、人々は代わりにどうするのか。それは、人類が最も昔からやってきた行動です。

彼らは、質問します。

これがどういう意味かを聞く。なぜこんな動きをしたのかを聞く。そして、代わりにやってくれと頼む。

これは、人が他人と接するときのあらゆる場面で見られる姿です。友人、子供、教師、生徒、同僚、部下、役員、誰に対しても同じです。同僚の「取扱説明書」を読む人はいません。尋ねて、答えてもらい、必要ならやってもらう。質問することは、読むのを面倒がる人々の手抜きではありません。それは人類が存在する限り、私たちが互いに対して使い続けてきたインターフェースであり、驚くほど優れています。事前のトレーニングは不要で、初日から機能し、曖昧な質問も許容してくれます。誰かが選んだ用語ではなく、あなたが実際に持っている言葉で問題を説明できるのです。

wikiを見ればわかるような内容でチケットを切った顧客は、決して私たちのソフトウェアを正しく使えていなかったわけではありません。彼らは単に、自分たちが実際に持っているインターフェースを使っていただけなのです。

ただ、そのインターフェースの反対側に私たちが存在していなかっただけでした。

なぜなら、彼らが質問した相手は私たちの会社の人間であり、その人間には対応待ちのキューがあり、時差があり、週末の休みがあったからです。リクエストが入り、そこから待ち時間が始まります。そして、この待ち時間こそが、最大のコストだったのです。

彼らは今すぐ解決したかった。あるいは昨晩のうちに。しかし彼らが手にしたのは、来週の木曜日の回答でした。

誰かにやってもらうために待ちたくはない。自分でやるために学びたくもない。前世代の製品が提供できたのは、この2つの選択肢だけでした。そして顧客は、そのどちらにも不満を抱くのが当然だったのです。

だからこそ、私たちが今自分たちに課している基準は、かつてのものとは異なります。

機能は、コードが動いたからといって完成ではありません。設定ページができたからでもなく、説明用のドキュメントが用意できたからでも絶対にありません。本当の完成とは、あなたが自分の言葉で――私たちが勝手に名付けた機能名ではなく、同僚に話しかけるときの言葉で――してほしいことを伝えられ、agentがその意図を理解し、これから何をするかあなたに告げ、そして実際にそれをやり遂げたときなのです。

それに少しでも満たないものは、結局のところ、まず私たちの製品を学ぶよう顧客に強いているのと同じです。