コンタクトセンターの自動化は、積み上げれば積み上げるほど成果が出ると思われています。FAQを整え、チャットボットを置き、IVRで振り分け、CCaaSで電話を束ね、QAツールで応対を評価する。ひとつ入れるごとに「1件あたり◯分削減」という報告が上がり、稟議はどれも通ります。
しかし実際には、多くのセンターで成果はある地点から頭打ちになります。個々の報告はすべて正しいのに、センター全体のコストは思ったほど下がらない。現場の肌感も、報告の数字ほどには楽になっていない。私たちはこの状態を、点の自動化の積み上げと呼んでいます。
本稿では、なぜ点を増やすほどROIが薄まるのかを、「効果は足し算、コストは掛け算」という非対称から整理します。そのうえで、エンタープライズとスタートアップ、実験の予算と本番運用の予算という4つの視点を足し、点ではなく「つながる」設計の条件を考えます。
「点の自動化」は、最初だけ効く
よくある構成を図にすると、こうなります。FAQ、チャットボット、IVR、CCaaS、QAツールが横に並び、それぞれの下に、それぞれのデータがぶら下がっている。ツールごとに管理画面があり、ツールごとにナレッジの置き場があり、ツールごとにレポートの形式が違う。
私たちは、こうした自動化を「点」と呼んでいます。単体で完結し、単体でROIを測り、単体のデータを持つ自動化です。点そのものが悪いわけではありません。最初の1つ、2つは、確かに大きな効果を出します。FAQを整えれば問い合わせは減り、ボットを置けば一次対応は軽くなる。
問題は、その先です。点を足すほど、1つあたりの効果は伸び悩みます。導入するツールの数を横軸に、効果を縦軸に取ると、曲線は最初に急に立ち上がり、やがて横ばいに近づいていく。3つ目、4つ目のツールは、1つ目ほどの効果を返しません。
なぜ伸びが鈍るのか。現場で起きていることは、おおむね4つに整理できます。
データがつながらないため、同じナレッジを複数の場所で更新し、重複投資が増える
ボットで顧客が話した内容が有人に届かず、体験が分断されて顧客満足が伸びない
有人応対で得た学びが次のボットやFAQに反映されず、運用が育たない
ツールを足すほど、運用と接続のコストが雪だるま式に増える
料金改定がひとつ入れば、FAQにも、ボットにも、オペレーター用のスクリプトにも手を入れる。どこかひとつが古いまま残り、回答がぶれる。ボットで途中まで話した顧客が有人につながった瞬間、「最初からお伺いします」と言われる。有人が見つけた新しい問い合わせのパターンは、SVの頭の中には残るが、ボットには戻らない。全体最適にはならず、部分最適の寄せ集めになる。これが、点の自動化が頭打ちになる正体です。
効果は足し算、コストは掛け算
ここが、この記事の中心です。
ツールAが電話で削った時間と、ツールBがチャットで削った時間。これは足し算です。AとBを一緒に入れたからといって、効果が掛け算で増えることはありません。効果は、どれだけうまくいっても足し算でしか増えない。
一方、コストの一部は、ツールとツールの「間」で発生します。画面の切り替えは、AとBの間で起きる。ナレッジの二重更新は、置き場の組ごとに発生する。障害が起きたときにどのツールの問題かを切り分ける時間も、ベンダー同士の調整も、「AとBの間で何が起きるか」という形で膨らみます。
組み合わせの数は、ツールの数より速く増えます。2つなら1組。3つなら3組。4つなら6組。5つなら10組。点を5つ並べたセンターは、10組の「間」を毎日運用していることになります。
見えないコストは、稟議書ではなく席に載っている
そして、この「間」のコストは、稟議書には載りません。稟議書に載るのは、ライセンス費用と導入費用です。オペレーターが1件の対応で切り替える画面の数、SVが毎朝見る管理画面の数、同じ情報を更新する場所の数、ツールごとの研修、ベンダーごとの調整窓口。どれも項目として立てにくいため、稟議には現れない。しかし、席、つまり同時に応対できる座席に座っている人が、毎日払っています。見えないコストは、稟議書ではなく席に載っているのです。
構造を見るために、仮の数字を置いてみます。実際の値ではなく、形を見るための数字です。
あるツールを入れて、効果が100、システム費用が50、席に載る見えないコストが30だったとします。手元に残る価値は20です。ここで、もっと効果を出そうとツールをひとつ足します。効果は1.5倍の150に増えた。システム費用は75。ところが、組み合わせが増えた分、見えないコストは倍の60になる。手元に残る価値は15。効果は増えているのに、残る額は減っています。
ベンダーのROIと、企業のROIは別物
もうひとつ、会話の構造にも罠があります。個々のツールを売る側から見れば、自分のツールのROIが成立していればよい。「応対時間を◯分削減できます。費用はこれだけです」という計算は、閉じていて正しい。
だから提案の場では「効果が出るなら、ツールが分かれていてもよいのではないか」という話になります。ところが企業の側からROIを見ると、ツールが増えるほど分母が膨らんでいる。個々の提案書には現れない組み合わせのコストが、センター全体では確実に発生している。ベンダーのROIと企業のROIは、別物なのです。
全員が正しくて、全体が間違っている。
これは、数え方の単位がずれているときに起きることです。ツールの単位で数えれば正しく、センターの単位で数えると合わない。ここまでが、点の自動化に共通する構造です。ここからは、この構造が組織の形や予算の形によってどう姿を変えるかを見ていきます。
エンタープライズでは、組織の数だけ点が増える
エンタープライズでは、点の積み上げは誰かの判断ミスではなく、組織構造の結果として起きます。
電話はコンタクトセンター、チャットはデジタル推進部門、FAQはWeb担当、応対品質は品質管理部門。予算が部門別に分かれていれば、稟議も部門別に上がり、契約するベンダーも部門別になる。
システムの構造は組織の構造を写す、という古い経験則は、コンタクトセンターの自動化にもそのまま当てはまります。点の数は、ツールを選んだ人の数ではなく、予算を持っている組織の数で決まる。
エンタープライズには、掛け算を加速させる要因もあります。
セキュリティ審査とベンダー管理は、ツールごとに発生する。複数年契約の満了時期はツールごとにずれていて、入れ替えのタイミングが揃わない。
データをつなぐ作業は「統合プロジェクト」として別の予算、別の稟議になり、しかもその稟議は「削減」ではなく「投資」に見えるため、単体ツールの稟議より通りにくい。すでに入れたツールを束ね直す提案は、過去の投資の否定に見えてしまうこともある。
ただし、エンタープライズには逆の面もあります。席が多いということです。席に載る見えないコストは席の数に比例するので、つないだときの回収も席の数に比例して大きくなる。
数百席のセンターで、1席あたり1日10分の画面切り替えと二重確認が消えたとすれば、それは席数と営業日数を掛けた分だけ効いてくる。点を足す稟議が個別に通りやすい組織ほど、つなぐ設計の回収余地は大きいのです。
エンタープライズで問うべきなのは、「このツールは効果が出るか」ではありません。「この点を足す稟議は、誰の予算で通り、誰の席に載るのか」です。予算を出す部門と、見えないコストを払う席が別の組織にあるとき、掛け算は誰にも見えないまま進みます。
スタートアップでは、点が1人の上に積まれる
スタートアップでも構造は同じです。違うのは、そのコストを誰が払うかです。
席が少なく、兼務が多い。カスタマーサポートの責任者が1人で問い合わせ対応、FAQの更新、ボットの運用、ツールの選定を兼ねていることは珍しくありません。SaaSは月数万円から始められるため、「安いから足す」という判断が起きやすい。ライセンス費用だけを見れば、たしかに安い。
しかし、組み合わせのコストは安くなりません。エンタープライズでは10組の「間」が数百席に分散して載りますが、スタートアップでは1人の上に全部載ります。5つのツールを1人が運用しているなら、10組の切り替えと、5か所の更新と、5社との調整を、その1人が毎日担っている。ライセンス費用が月数万円でも、その人の時間は月数万円では済みません。
スタートアップには、エンタープライズにない強みもあります。既存の資産も、複数年契約も、部門の壁も少ない。最初から「つながった設計」を選ぶ自由がある。
ところが実際には、「まずFAQだけ」「まずボットだけ」と点から始めることが多く、事業の成長とともに点が増え、気づいたときにはエンタープライズと同じ構造が小さな規模で再現されています。しかも成長期は問い合わせが増える局面なので、掛け算は最も痛いタイミングで顕在化します。
スタートアップで問うべきなのは、「このツールは安いか」ではありません。「席が10になり、100になったとき、この構成のまま回るか」です。判定の基準はライセンス費用ではなく、1人の上に載っているものの個数になります。
実験の予算は点で成立し、本番運用の予算が線を払う
もう2つの視点は、予算の性質そのものにあります。
実験、つまりPoCの予算は、期間を限り、範囲を限り、単体で評価するよう設計されています。「このボットで自己解決率が何ポイント上がるか」。実験は点で切るのが正しい。範囲を切らなければ、実験になりません。
問題は、点で切った実験の成功が、点の積み上げを正当化してしまうことです。
実験で測っているのは分子、つまり効果だけです。接続、二重更新、研修、ベンダー調整という分母は、実験の期間中は評価の対象外か、実験チームが手で吸収しています。実験の予算の中では、掛け算は起きない。だから実験は成功し、稟議が通り、点が増える。
本番に移ると、その分母は運用の予算に移ります。
ところが本番運用の予算には、「接続」「二重更新」「研修」「調整」という行がありません。あるのは人件費とライセンス費です。見えないコストは人件費の中に溶け、誰の目にも「ツールを足したから増えた」とは見えなくなる。
さらに、予算の主体が変わります。
実験の予算を持つのはDX推進部門やイノベーション部門、本番運用の予算を持つのはセンター長やSVです。導入の意思決定の場に、運用の予算を払う人がいないことは珍しくありません。予算の主体が実験から本番に移る瞬間に、コストが見えなくなる。点の自動化が正当化され続けるのは、この受け渡しの構造があるからです。
打ち手は2つあります。ひとつは、実験の設計に「つながるか」を含めることです。精度や削減時間だけでなく、ボットで得た文脈が有人に渡るか、有人の学びがボットやFAQに戻る導線があるか、本番で1席に載るものが何個増えるか。この3つを、実験の評価項目に入れる。もうひとつは、本番運用の予算をツール別ではなく、センター全体の「運用システム」として1本で持つことです。予算が1本になれば、組み合わせのコストははじめて1か所に現れます。
「つながる」には3つの条件がある
ここまで「つながる」という言葉を使ってきました。その中身を定義します。
つながるとは、ツール同士をAPIで接続することではありません。接続を増やすことは、組み合わせを増やすことでもあります。私たちが「つながる」と呼ぶのは、次の3つが揃った状態です。
データがつながる。
すべてのチャネルが、同じ正(マスターナレッジ)を参照している。正とは、回答の根拠となる唯一の原本のことです。料金改定は1か所を直せば、FAQにもボットにも有人のスクリプトにも同時に反映される文脈がつながる。
ボットで顧客が話した内容、途中まで進んだ判断が、有人にそのまま渡る。顧客は同じことを二度言わない学びがつながる。
有人応対で見つかった新しいパターンや修正が、次のボット、FAQ、スクリプトに戻る。運用が、使うほど育つループになる

この3つが揃うと、ツールを足しても組み合わせは増えません。増えるのは入り口、つまりチャネルの数だけで、中心は1つのままです。効果は足し算のまま増え、コストは掛け算から足し算に戻る。ROIの曲線は、横ばいにならずに伸び続けます。
ここで、ひとつ注意が必要です。AIエージェントを入れれば自動的につながる、という話ではありません。チャネルを横断して一次対応を担うAIエージェントは、「電話用のAI」「チャット用のAI」という分け方を無意味にし、「チャネルごとに1ツール」という前提を崩し始めています。
しかしAIエージェントもまた、既存のツールの上に「もうひとつ足す」形で入れば、分母を膨らませる側になります。前提が崩れるのは、設計を変えたときだけです。
私たちは、AI導入を「点」ではなく「運用システム」として設計すべきだと考える
私たちは、AI導入のROIは、ツールの数ではなく、つながりで決まると考えています。
変わるべきなのは、問いの立て方です。「このチャネルに、どのツールを入れるか」ではなく、「センター全体を、ひとつの運用システムとしてどう設計するか」。KARAKURIが顧客対応AIエージェントのGeN、オペレーター支援のKARAKURI assist、ナレッジ基盤のKARAKURI CXMを、別々の点ではなく、同じ正と同じ文脈を共有する一つの運用システムとして設計しているのは、この考えからです。
「一元管理」の価値は、これまで主にライセンス費用の削減として語られてきました。私たちは、この論点はROIの文脈で語られるべきだと考えています。つなぐことの価値は、費用をまとめて安くすることではなく、分母の掛け算を止めることにあるからです。効果を足し算で積み上げても、分母が掛け算で増えていては、手元に残る額は増えません。
エンタープライズであれば、予算を出す組織と席を持つ組織のずれを見る。スタートアップであれば、1人の上に載っている個数を見る。実験の予算では、精度だけでなくつながるかを測る。本番運用の予算では、ツール別ではなく運用システムとして1本で持つ。立場は違っても、見るべきものは同じです。
見えないコストを、正確な数字にする必要はありません。数えにくいから稟議書に載らないのであって、それ自体は仕方のないことです。ただ、ツールを足せば確実に増え、しかも足し算ではなく掛け算で増える。この一点だけは、意思決定の場に置いておいてほしいと考えています。
あなたのセンターで、1席に載っているものはいま何個あるでしょうか。そして次のツールを足したとき、それは何個になるでしょうか。
議論のたたき台として、つながる設計の実際に関心のある方はお気軽にお問い合わせください。
このブログを書いた人
change_historyKARAKURI Marketing team



