複数のチャットツールが混在する組織で、情報を横断的に扱う

チャットツールが1つに統一されている組織は、実は少数だと思います。
社内では1つのツールを使っていても、顧客とは相手が指定する別のツールでやり取りするしかなく、ここは相手の都合なので統一のしようがありません。
厄介なのは、顧客とのやり取りのほうに価値の高い情報が含まれている点です。

今回は、複数のチャットツールが混在する環境で情報を横断的に扱う方法について書いていきます。
会議と議事録の全体像は会議と議事録のAI化。準備から共有・タスク化までの設計にまとめてあります。

社内は1つでも、顧客とのやり取りはツールが割れます

混在の形は、大きく3つに分かれるでしょうか？
社内は1つで顧客ごとに別、部門ごとに違う、社内でも新旧が混在している、という3パターンです。

顧客ごとに別のツールを使うケースは、「このツールでやり取りしましょう」と相手に指定されるたびに、対応するツールが増えていきます。
部門ごとに違うケースは、各部門が個別に導入した経緯によるものです。
社内で新旧が混在するケースは、移行の途中で両方が使われている状態です。

なかでも対処が必要なのは、顧客ごとに別のツールを使うケースです。
部門ごとと新旧混在は社内の議論で統一できますが、顧客ごとのケースは相手の都合なので、どれだけ議論しても統一できません。
なかでもこの顧客とのやり取りの情報が、最も価値が高いという事情もあります。

顧客が語った要望、条件が変わった経緯、その場で決まった内容がこうして担当者の端末にしかない状態は、業務のリスクそのものです。

横断できないと、担当が休んだ瞬間に業務が止まります

損失を具体的に並べておきます。
担当が休むと状況が分からない、引き継ぎで失われる、顧客ごとの状況を横断して見られない、決まったことの記録が残らない、顧客の声が集まらない、という5つです。

担当が休むと状況が分からないのは、顧客とのやり取りが担当者のツールの中にしかなく、代わりの人は「その件は把握していません」と答えるしかないからです。
引き継ぎで失われるのは、異動や退職の際に経緯そのものが渡せなくなるからです。
顧客ごとの状況を横断して見られないと、「この件で問い合わせが来ているのは全顧客のうち何社か」を知りたくても、ツールがばらばらだと数えられません。

決まったことの記録が残らないと、チャットで合意した内容が正式な記録になっておらず、後から「そんな話はしていない」という認識のずれが起きます。
顧客の声が集まらないのは、要望や不満が営業や開発に届かないまま流れていくからです。
なかでも実務のリスクとして大きいのは、担当が休むと状況が分からない点と、決まったことの記録が残らない点の2つです。
担当が動けなくなった瞬間に止まる業務と、相手との認識がずれたまま進む案件は、どちらも後から取り返すのが難しくなります。

集約は4方式あり、まず運用で解決できる部分から試します

方式は4つあり、判断の基準とセットで整理しておきます。
全ツールのログを1箇所に集める方式、重要な内容だけを手動で転記する方式、決まったことをメールで確認する運用にする方式、集約しない方式です。

全ツールのログを集める方式は、定期的に取得して共通の表に蓄積する形で、横断して集計する必要がある場合に選びますが実装が要ります。
重要な内容だけを手動で転記する方式は、決まったことや顧客の要望を案件の記録に書き写す形で、件数が少ない場合には成立しますが忙しい日に抜けます。
決まったことをメールで確認する運用にする方式は、チャットで話した内容をメールで送って記録に残す形で、認識のずれを防ぐことが目的なら、これで足ります。
集約しない方式は、ツールごとに残ったままにする形で、件数が少なく担当が固定されている場合の選択です。

なかでも見落とされやすいのが、メールで確認する運用です。
技術的な集約に取りかかる前に運用の工夫で解決する部分が残っていて、「決まったことはメールで確認する」という運用は記録が残らない問題と認識がずれる問題を同時に解決しますし、メールのほうは既に集約されている組織が多いのも実情です。

先に試すべき理由は3つあり、実装のコストが不要な点、相手にとっても良い点、記録として整っている点です。
メールで送る運用は今日から始められ、決まったことがメールで残ると相手も後から確認できるので「言った・言わない」が両側で解決し、チャットのログは断片的でも確認のメールは整理された形で後から読めます。

この運用には、AIも使えます。
チャットのやり取りをそのまま渡して、確認のメールの下書きを作らせるという使い方です。
ただ、そのときは社外向けの変換の指定を必ず入れます。
変換のルールそのものは社内情報を外に漏らさない変換。社外向け文面の自動生成ルールにまとめてあります。

だから順序としては、メールで確認する運用を試してから、全ツールのログを集める方式を検討します。
横断的な集計が必要になった時点で、初めて実装を考えれば足ります。

ログを集める設計は、相手先の表記をそろえる作業が肝になります

横断的な集計が必要になった場合の設計も書いておきます。
そろえる項目は6つで、日時、ツール、相手先、やり取りの相手、本文、元のやり取りへのリンクです。
なかでも「相手先」をそろえるのが、最も難しい作業になります。
表示名が「A社」「A社様」「エーシャ」のようにツールごとに割れているだけで、対応表を作って会社名に変換する工程が別に必要になります。

集める範囲も決めておきます。
全部のやり取りを集めると量が多すぎるので、顧客との連絡用のチャンネルと案件ごとのチャンネルに絞り、個人間のやり取りは対象外にします。
各ツールのAPIを使う場合は認証情報の管理が必要で、期限があるものは更新の仕組みか期限が近づいたときの通知を入れておきます。

ただ、相手先の同意は先に確認します。
顧客とのやり取りを社内に蓄積するのが、契約や秘密保持の範囲に抵触しないかを確かめます。
ここは技術より先に片づける工程で、飛ばせません。

線引きとしては、集約するのが顧客との連絡用のやり取りと案件に関わるやり取りで、集約しないのが個人間のやり取り、雑談、相手が集約を望まない場合です。
契約で制限があったり相手の方針で難しかったりする場合は、メールで確認する運用で対処します。
判断の目安は「担当が休んだときに必要か」で、参照されない情報を集めても管理の負荷だけが増えます。

チャットログの蓄積そのものはチャットに流れた知見を消さない。ログを組織のナレッジに変える、顧客対応の記録の受け皿は顧客とのやり取りを記録に残す。属人化を防ぐ情報の受け皿で扱っています。

集約は続けるコストが要り、止まった兆しに気づける設計にします

集約の仕組みは作ったら終わりではなく、続けるためのコストも見積もっておきます。
継続してかかるのは、認証情報の更新、ツールの仕様変更への対応、相手先の表記の対応表の更新、容量の管理です。

なかでもツールの数だけコストが増えるという性質があり、顧客ごとにツールが違う場合は対応するツールが増えるほど保守が重くなっていきます。
だから対象のツールを絞ります。
顧客数の多いツール、あるいは重要な顧客が使っているツールに限定し、全部に対応しようとすると保守が破綻します。

「対応していないツールはメールで確認する運用でカバーする」と決めておくと、運用が続くかどうかが決まります。
保守や手段の選び方はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

実務上の注意点として、定期的に走る取得の処理は止まっても気づけるでしょうか？
認証の期限切れ、ツール側の仕様変更、通信の問題があり、気づくのは必要になったときで、「あの期間のやり取りがない」と半年後に気づきます。
対処は2つで、実行の記録を残す、週に1回は最新の記録の日付を確認する、という形にします。
記録が途切れていれば止まっていると分かり、確認は自動で通知を出す形にしておきます。

あわせて止まっているときの代替も決めておきます。
手動でエクスポートする手順を残しておき、完全に自動化に依存しない設計にします。

会議ツールが混在する場合の集約は複数ツールに散った会議記録をまとめる。ツール混在環境の設計にまとめてあります。

つまずきやすいのは、技術的な集約から検討する、全部のツールに対応しようとする、相手先の表記をそろえない、顧客とのやり取りの蓄積について契約の範囲を確認しない、実行の記録を残さない、参照されない情報まで集めるの6つです。
どれもメールで確認する運用を先に試し、対象のツールを絞り、対応表を作り、先に契約を確認し、実行の記録を残し、「担当が休んだときに必要か」で判断すれば防げます。

ツールの混在を前提にした記録の集め方は、私たちが提供しているAI伴走支援でも、止まったときの手順まで含めて、AIワークフローの実装として現場の担当者と一緒に組み立てています。

チャットツールの混在は統一せず、決まったことを記録に残します

チャットツールの混在は、顧客が指定するツールに合わせるという構造から起きるので、社内の議論では統一できません。
顧客とのやり取りのほうに、価値の高い情報が含まれています。

横断できないと、担当が休むと状況が分からない、引き継ぎで失われる、顧客ごとの状況を横断して見られない、決まったことの記録が残らない、顧客の声が集まらない、という問題が起きます。
なかでも大きいのは、担当が休むと状況が分からない点と、決まったことの記録が残らない点です。
方式は4つで、全ログを集める、重要な内容を手動で転記する、決まったことをメールで確認する運用にする、集約しない、という並びです。

まず、メールで確認する運用を検討します。
実装が不要で、相手にとっても良く、記録として整っているからです。
チャットのやり取りから確認メールの下書きを作れますが、そのときは社外向けの変換の指定を入れます。

横断的な集計が必要になってから、全ログを集める方式を検討します。
そろえる項目は6つで、「相手先」の表記をそろえるのが最も難しく、対応表が要ります。
顧客とのやり取りの蓄積は、契約の範囲を先に確認します。

対象のツールは絞ります。
全部に対応すると保守が破綻するので、対応していないツールはメールで確認する運用でカバーします。

まずは顧客とのやり取りについて、決まったことをメールで確認する運用を1件、試しに回してみます。