Omni-channel Contact & Case Management
オムニチャネルは、チャネル数の問題へと単純化されがちです。ウェブチャットを追加し、メッセージング用の番号とソーシャルの受信箱を接続すれば、これで全体像は完成したと宣言する、という具合です。しかし顧客が経験するものは、企業に到達できる経路の数からではなく、どの入口をくぐったとしても、その顧客が誰であり、何を尋ね、何を約束されたのかを組織が覚えているかどうかから生まれます。以下では、チャネルを付随的なものとして扱い、意味を持つ単位としてケースを据えます。チャネルは安価であり、コンテキストは高価だからです。
現状と、なぜ今それが重要なのか
今日ほとんどの組織が運用しているシステム環境は、チャネルごとに組み上げられてきました。それぞれが独自の予算、ベンダー、チーム、報告系統を持っています。電話プラットフォームが最初に到来し、文化を形づくりました。メールサポートはその横に後付けされ、たいていは別のチケッティングツールを伴っていました。ウェブチャットはさらに後になって、しばしば第三の供給業者から導入され、マーケティングの誰かがひっそりとソーシャルアカウントを取得しました。メッセージングの試験運用が片隅で走り、結局きちんと終わることはありませんでした。それぞれの追加はそれ自身の論理で正当化され、より重大なことに、それ自身の論理で計測されました。だからこそ、典型的なコンタクトセンターは、呼損率を小数点第二位まで報告できる一方で、単一の顧客が先週、運用するすべてのチャネルを通じて何回別々に到達してきたのかは答えられないのです。
この歴史は、技術的である以前に組織的であることに注目してください。チャネルが増殖したのは、組織図が増殖したからです。音声運用チーム、別個のデジタルチーム、マーケティング内部に置かれたソーシャル機能、それぞれに、自らの領域と賞与が自らの担当面に結びついたマネージャーがいました。技術は、すでに存在していた構造を記録したにすぎません。これが重要なのは、変化への抵抗がどこから来るかを予測させるからです。ケースを中心に統合することは、プラットフォームを脅かすというよりも、一連の報告系統を脅かします。そして、この問題を純粋に技術的なものとして扱うプログラムは、名指しを避けた政治の上で座礁するでしょう。システム環境とは、誰が何を所有していたかについての過去の意思決定を写した地図であり、それらの意思決定の多くは今なお現役です。
いま二つの圧力が、この配置を維持不能にしています。第一は行動上のものです。顧客は生活の他の場面で非同期かつメッセージング優先の習慣へと移行しており、その期待を持ち込んできます。すなわち、あるチャネルで問い合わせを始め、数時間後あるいは数日後に別のチャネルで、経緯全体を語り直すことなく続けたいのです。第二は経済的なものです。同期的な音声は組織が購入する最も高価な一分であり、より安価なチャネルが存在するというだけでその需要が減ることはありません。安価なチャネルが実際に問題を解決したときにのみ、需要は減ります。同時に、言語モデルはセルフサービス層が現実的に挑めることを変え、それによりディフレクションを誤る機会とリスクの双方を高めています。
したがって進行中の転換は、チャネルを減らすことから増やすことへの転換ではありません。組織原理としてのチャネルから、組織原理としてのケースへの転換です。チャネルは、顧客が利便性のために選び、組織がコストのために選ぶ伝送層となる一方で、ケース、すなわち解決されつつある事柄は、それらすべてを貫いて持続します。メッセージングの問いをメッセージング製品の購入で答え、ソーシャルの問いをソーシャル製品の購入で答える組織は、逃れようとしているサイロを、一件の取得ごとに作り直しているのです。うまくやる組織は、新しいチャネルのそれぞれを、すでに共有している中核への別の入口として扱っています。
中核となる枠組み、すなわち第一原理
ほとんどのオペレーティングモデルが曖昧にしている区別から始めましょう。コンタクトとは単一のやり取りです。一本の通話、一通のメッセージ、一件のフォーム送信です。ケースとは、顧客が接触してきた実際の理由であり、多くのチャネルにまたがる多数のやり取りと数日間に及ぶことがあります。管理する価値のある単位はケースです。コンタクトが単位であるとき、これはコールセンターの系譜の大半がそうですが、チャネルの切り替えごとに新しいレコードが始まり、顧客は同じことを繰り返し、組織は、解決された需要のいずれにも結びつけられない活動を数えます。ケースが単位であるとき、コンタクトはイベントとしてケースに付随し、それぞれが到着したチャネルは構造ではなくメタデータになります。
関連する区別を率直に述べておく価値があります。というのも、多くの計測の枠組みが誤るのはまさにここだからです。コンタクトを閉じることは、ケースを解決することと同じではありません。エージェントは通話を終え、チケットを完了と記し、あらゆる運用目標を満たすことができますが、その一方で顧客が電話をかけた理由は満たされないままであり、だからこそ翌日また電話をかけ、それは新規コンタクトとして集計に入るのです。解決とは顧客が付与する属性であって、運用者が宣言する属性ではありません。ケースを単位として構築することは、これを表面化させます。なぜなら、再開されるケースは、都合のよい新しい番号ではなく、目に見えて同じケースであり、繰り返しのコンタクトは、そもそも謳っていたものを計測していなかった初回解決の統計の内側に、もはや隠れられなくなるからです。
そこから、コンテキストの単一ビューという考えが導かれます。ケース、その履歴、顧客の身元と権利、過去のコンタクト、未決の約束、関連するレコードを集約し、どのチャネルであれ、現在のやり取りを扱ういずれのエージェントやシステムからも利用できるようにするのです。コンテキストは、エージェントが切り替えて見る画面ではありません。やり取りが走る基盤そのものです。それが音声プラットフォームの内部にしか存在しないなら、チャットのエージェントは盲目であり、顧客はその盲目の代価を繰り返しによって支払います。
さらに三つの原理が枠組みを完成させます。第一に、ジャーニーはルーティングされるのではなくオーケストレーションされます。問いは、単にコンタクトがどのキューに入るかではなく、ケースがどの状態にあり、次に何が起こるべきか、それはチャネルをまたぐかもしれず、生身のエージェントを一切伴わないかもしれない、というものです。第二に、ナレッジは共有資産です。同じ答えが、セルフサービス層、有人サービスのエージェント、AI層に等しく供されなければなりません。というのも、三つに分かれた真実の写しこそ、組織が自己矛盾を来す仕組みだからです。第三に、計測はケースに従います。解決と労力はケースの属性であって、いずれか一つのチャネルの属性ではなく、チャネル単位の活動に報いるオペレーティングモデルは、意図がどれほど善良であろうと、誤ったものを最適化してしまいます。
現在の動向とパターン
既定の構えとしての非同期メッセージング。 最近の最も重要な変化は、新しいチャネルではなく、時間に対する新しい期待です。メッセージングの会話は、応対の時間枠の中で開いて閉じることはありません。持続し、静かになり、再開します。エージェントが一定数のライブチャットを同時に保持する同期的な同時処理を軸に組まれたシステム環境は、これにうまく適応できません。機能するパターンは、あらゆる会話をケースに付随する持続的なスレッドとして扱い、顧客が戻ってきたときに手の空いている誰かが引き継ぎ、履歴は完全なまま保たれ、同じ人物が応答するという期待は伴いません。
壁としてのAIではなく、AIが支援するコンタクト。 言語モデルの信頼に足る展開は、二つの場所にあります。支援層では、返信の下書きを作り、長い履歴を要約し、関連するナレッジ記事を、送信内容に責任を持ち続ける人間の前に提示します。セルフサービス層では、狭く明確に境界づけられた意図を端から端まで解決し、そして決定的に、限界に達したときには完全なコンテキストとともに引き継ぎます。失敗するパターンは、顧客が人に到達するのを防ぐことを目的とした門としてモデルを展開することです。顧客はこれを打ち破ることを学び、そこで報告されるディフレクションは架空のものです。
解決として捉え直されたディフレクション。 成熟した運用者は、セルフサービスが吸収したコンタクトを数えるのをやめ、セルフサービスが実際に満たした需要を数え始めました。チャットボットを見限ってコンタクトセンターに電話をかける顧客は、ディフレクションされたのではありません。コストは単に移動し、増大しただけです。この捉え直しは、何が構築されるかを変えます。ナレッジと自動化は、人間なしで真に解決する意図に狙いを定め、そうでない意図は、防御するのではなく速やかに人へとルーティングされます。
ケースに織り込まれたプロアクティブなコンタクト。 より目立たない転換は、純粋なインバウンドの応対から、組織が起点となるコンタクトへの移行です。配送の例外、サービスの停止、判断を要する更新などです。一斉配信として扱われると、これらの通知は、どのチャネルも予期していない混乱したインバウンドの返信の波を生みます。適切に扱えば、アウトバウンドのメッセージは、ケース上の単なる別のイベントであり、コンテキストとともに送られ、顧客が好むどのチャネルでも返信を受け取る準備が整っています。こうして、プロアクティブなメッセージへの答えは、冷たい問い合わせを始めるのではなく、同じスレッドに戻ってきます。インバウンドのケースモデルをまず固めた組織は、アウトバウンドがほとんど無償で手に入ることに気づきます。アウトバウンドを別途後付けする組織は、七つ目のサイロを作り、それをエンゲージメントと呼ぶのです。
共有インフラとしてのナレッジ。 勢いを増しているパターンは、公開ヘルプセンター、エージェント内のパネル、AI層を一つの源から供給する単一のナレッジベースであり、その執筆、レビュー、廃止は他の本番資産と同様に統制されます。ナレッジがイントラネットのページ、保存された返信、個人の記憶にばらばらに残っているところでは、どれほどチャネルに投資しても一貫性は生まれません。答えそのものが食い違っているからです。
それを機能させるアーキテクチャと設計原理
共有されたケースの中核と、周縁のチャネル。 荷重を支える決定は、ケース、コンテキスト、ナレッジをチャネル非依存の中核に保持し、音声、メール、チャット、ウェブ、ソーシャル、メッセージングを、その中核へのアダプターとして扱うことです。各アダプターの仕事は、認証し、コンタクトを捕捉し、正しいケースに付随させ、それを扱う者にコンテキストを描き返すことです。中核が真に共有されているとき、チャネルの追加は新しいオペレーティングモデルではなく統合の作業になります。そうでないとき、あらゆるチャネルはそれ自身の小さなコンタクトセンターになります。
一級の関心事としての本人特定。 発信者、メール送信者、メッセージ送信者が同一人物であると組織が判別できなければ、ケースはチャネルをまたいで持続できません。本人特定、すなわちコンタクトを既知の顧客と、そして許容できる確信度で既存の未決ケースと突き合わせることは、他のすべてが乗る静かな土台です。ここへの投資を怠れば、設計上は健全であっても、共有された中核は実運用で断片化します。コンタクトが孤児として着地するからです。
チャネルロジックから分離されたオーケストレーション。 次に何が起こるか(エスカレーション、ルーティング、確認、自動化、待機)についての決定は、チャットツールや電話のメニューの内部ではなく、ケースの状態を推論するオーケストレーション層に属します。そのロジックを各チャネルに埋め込むことは、乖離を保証します。同じケースが、顧客がたまたまどこにいるかによって異なる扱いを受け、六つの場所で変更しなければ誰もポリシーを変えられなくなるのです。
応対の地点で組み立てられるコンテキスト。 顧客データをあらゆるチャネルツールに複製するのではなく、やり取りの瞬間に、各部分を所有するシステムからコンテキストのビューを組み立て、人間と機械に等しく一貫して提示します。これにより所有関係が明確に保たれ、陳腐化した写しが避けられ、コンテキストビューの改善がツールごとに再実装されるのではなく一度にすべてのチャネルへ届くことを意味します。
一部が故障したときの穏やかな劣化。 共有された中核は価値を集中させ、それは同時にリスクも集中させることを意味します。本人特定やコンテキストサービスが利用できないとき、あらゆるチャネルが一斉にそれを感じます。健全な設計は、それを起こらないものと仮定するのではなく、これに備えます。中核に到達できないアダプターは、それでもコンタクトを捕捉し、暫定的な身元に対して待ち行列に入れ、後で照合するべきです。そうすれば、下流のサービスが遅いという理由で顧客が門前払いされることは決してありません。代替、すなわち部分的な停止がひそかにコンタクトを取りこぼしたり、ケースを見られないチャネルに置き去りにしたりする状態は、それが置き換えた断片化した環境よりも悪質です。目に見えず、しかも大規模に失敗するからです。悪い日のために設計することは悲観論ではありません。集中化の代価です。
よくある失敗の様態
チャネル数の演出。 顧客がいまや六通りの方法で到達できるようになったからといってオムニチャネルを達成したと宣言する一方で、そのどの方法も新しいレコードを開き、顧客は切り替えのたびに同じことを繰り返す、という状態です。同じ迷宮への入口が増えることは、訪問者を覚えている一つの建物と同じではありません。
ディフレクションの会計。 セルフサービスに対して、解決した需要ではなく吸収したコンタクトに報いることです。高い封じ込め率を報告しながら、ひそかに怒った発信者を製造するチャットボットは、自らを美しく見せる唯一の数字を最適化し、重要な数字はどれも最適化していません。そして真のコストは、一つ下流のチャネルで表面化します。
AIの門。 その真の機能が、顧客と人との間に立ちはだかることであるモデルを展開することです。顧客はこれを素早く見抜き、突破するための言い回しを学び、労力を取り除くどころか付け加えられて、すでに苛立った状態で有人層に到達します。技術に問題はありません。その配置の背後にある意図こそが過ちです。
ナレッジの乖離。 ヘルプセンター、エージェント、自動化それぞれに別々の答えを維持することです。それらは必然的に食い違っていき、その結果、組織は同じ質問に対して、顧客がどの面に触れたかによって三つの異なる回答を返します。源そのものが食い違っているとき、一貫性は研修の問題ではありません。
サイロを再生産する再プラットフォーム化。 名目上はすべてのチャネルを網羅する単一のスイートを購入し、その後、各チャネルをその中で、独自のキュー、独自のナレッジ、独自の報告を持つ別々のワークスペースとして構成することです。こうしてサイロは、一つのベンダーのロゴの下で、移行を無傷で生き延びます。共有された中核とは、アーキテクチャとオペレーティングモデルへの約束であって、調達の出来事ではありません。スイートはそれを可能にしますが、それを実現させるためには何もしません。ライセンスを成果と取り違える組織は、多額を費やして出発点そのものに到達し、いまや長期の契約に縛られています。
チャネルごとに孤立した計測。 チャネル単位で応対時間、放棄率、件数を報告する一方で、ケース全体としての解決率や労力を誰も担わない、という状態です。チャネル単位で計測されるものはチャネル単位で最適化され、たいていは、指標には見えない場所へと境界を越えて難しさを移すことによってそうなります。このように計測されたオペレーティングモデルは、自分が顧客を失望させていることを検知することすらできず、各部分が忙しそうに見えることだけを検知します。
私たちの働き方
私たちはチャネルではなくケースから始めます。いかなるプラットフォームを論じる前に、顧客が接触してくる実際の理由、それらの理由が今日どのように解決されるのか、そして現在の環境がどこで繰り返し、引き継ぎ、コンテキストの脱落を強いているのかを地図に描きます。これにより、どのコンタクト種別が人間なしで真に解決するのか、どれが速やかに人間を必要とするのか、そしてどれが、コストを別の場所で製造している自動化によって防御されているのか、という率直な描像が得られます。チャネルの願望リストではなく、その地図が優先順位を定めます。
そこから、まず共有された中核を、次にチャネルを設計します。本人がどう特定されるか、ケースがやり取りをまたいでどう持続するか、コンテキストが応対の地点でどう組み立てられるか、ナレッジがどう一つの資産として執筆され統制されるかを確立します。その中核が定義されて初めて、各チャネルをそこへのアダプターとして扱います。この順序が重要です。だからこそ、後から加わるチャネルは新しいオペレーティングモデルではなく統合となり、ポリシーの変更は六つではなく一つの場所に着地するのです。私たちはAI層について慎重であり、狭い意図を明快に解決するか、責任を負う人間を支援する場所にそれを据え、障壁として用いることを拒みます。
私たちは、すべてが整うまで何も届けない複数年のプログラムではなく、実際のコンタクト種別を端から端まで解決する漸進的な単位で作業します。各単位は当初から解決と顧客の労力に対して計測されるので、改善は重要な数字において目に見え、後退は早期に捉えられます。私たちはベンダーに対して実利的であり続けます。価値の多くは本人特定、オーケストレーション、コンテキストの組み立て、ナレッジの統制にあり、これらは製品の選択であると同時に設計とオペレーティングモデルの作業でもあるのです。既存のプラットフォームが共有された中核に資するところではそれを残し、サイロを塗り固めるところでは率直にそう申し上げます。
コンタクト種別が共有された中核を通って動き始めたら、私たちはその周りに、古いチャネル報告では支えられなかった計測とレビューのリズムを据えます。解決率と顧客の労力は、意図別に、ケースの水準で読み取られます。そうすれば、ある理由での繰り返しコンタクトの増加は、安定して見えるチャネル平均に吸収されるのではなく、シグナルとして目に見えるようになります。私たちはナレッジベースを、名前のついた所有者、レビュー期日、もはや真実でないものを廃止する経路とともに、生きた資産として統制します。というのも、自動化層は、それが依拠する答えの良さを決して超えられないからです。そして私たちは、技術とともにオペレーティングモデルを見直し続けます。ケースを中心とした環境は、処理量ではなく解決に報いる役割と誘因を要求し、それらは自ずと変わることはないからです。
Nashuaが違いを生む場所
コンタクトとケースの管理において私たちが特にもたらすものは、あらゆる商業的圧力が、もう一つチャネルを買ってそれを進歩と呼ぶ方向へ押しやるときに、ケースを中心に据え続ける規律です。私たちはプラットフォームを統合するのと同じくらい、オペレーティングモデルと計測の枠組みを描き直すことにも通じており、本人特定、オーケストレーション、ナレッジの統制を、付随的な配管ではなく本質的な作業として扱います。チャネルの活動ではなく解決と労力から論じられたその組み合わせこそが、受信箱の寄せ集めを、顧客を覚えている組織へと変えるものです。
これが何を要し、何を要さないかについて正直であるに値します。それが有能な電話プラットフォームや好評のチケッティングツールを引き抜くことを要することはめったにありません。それが要するのは、それらを中心から周縁へと格下げすることであり、これはより難しい変化です。ソフトウェアではなく権限に関わるからです。元を取る作業は、地味な中間部です。信頼されるに足る確信度でチャネルをまたいで本人を特定すること、あらゆるチャネルが読めるどこかにケースの状態を保持すること、そして顧客がどこで見つけても答えが同じであるように単一のナレッジ体系を統制することです。そのいずれもデモンストレーションで見栄えよく映ることはなく、そしてそのすべてが、顧客を覚えているシステム環境を、顧客を忘れる方法を実に数多く持っているだけの環境から分かつものなのです。
さらに、作業が何を前提として許されるかを変える実務上の帰結があります。あるエンゲージメントが、まだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほぼあらゆる機能を速やかに受け入れられるように構築されています。必要なものを平易な言葉で記述すれば素早く生成されますが、それは常に確固たるアーキテクチャ原理の内側で、厳格な品質保証の下で行われるので、速さが一貫性、セキュリティ、統制を犠牲にすることは決してありません。その効果は、単に便利であるというより戦略的です。それは内製か購入かの線を動かし、選択肢の余地を安価に保ち、戦略がたまたま棚にあったものに屈するのではなく、アーキテクチャが戦略に従うことを可能にします。
その結果は、チャネルが真に付随的なシステム環境です。顧客は自分に合った方法であなたに到達し、ケースは顧客に付いて回り、そして組織はついに、顧客が求めてきた事柄が実際に解決されたかどうかを見て、改善できるようになります。それが、私たち自身に課す成果であり、それによって計られたいと願う成果です。
