顧客とのやり取りを記録に残す。属人化を防ぐ情報の受け皿

「担当者が休んでいるので、明日以降の対応になります」。

顧客にこう言わざるを得ない場面は、どの組織にもあると思います。
原因は人員の不足ではなく、やり取りの記録が担当者の手元にしかないことです。
記録さえ残っていれば、代わりの人でも対応できます。

今回は、顧客とのやり取りを記録に残す受け皿の作り方を書いていきます。
会議と議事録の全体像は会議と議事録のAI化。準備から共有・タスク化までの設計にまとめてあります。

担当者が休むと止まるのはなぜか

担当者が休むと、代わりの人には何が分からなくなるのでしょうか？
分からないのは、これまで何を話して何が決まっているかという「経緯」、いつまでに何を出すことになっているかという「約束」、相手の窓口が誰で社内でどういう状況にあるかという「相手の状況」の3つです。
「この案件、いまどうなっていますか」と聞かれても、代わりの人は答えられません。
この3つが分からないと、そもそも対応に入れませんし、約束の期限を過ぎていることにも気づけません。

代わりの人が対応すると、顧客に同じ説明をもう一度させることになります。
ここがいちばん信頼を損なう部分だと思います。

では、なぜその記録が残らないのでしょうか？
理由も3つあります。
やり取りのあとに記録を書く作業が別に発生するので、書いているあいだにもう次の対応が始まっています。

「顧客対応メモ」のような自由記述の欄だと、書く内容が人によってばらばらになります。
自分が書いた記録を誰も読んでいないと分かった時点で、書く動機は消えてしまいます。
この3つのうち「書く手間がある」がいちばん大きく、仕組みで解決できます。
「場所と項目が決まっていない」は設計で、「書いても使われない」は運用の設計で解決できるので、順番に見ていきます。

自動転記で「書く手間」を消す

「書く手間がある」への対処は単純で、顧客とのやり取りが行われる場所、つまりチャットのチャンネルやメールから自動で記録の表へ転記します。
要点は「全部を転記する」ことで、ここで選別はしません。
もちろん、選別してから記録したほうが整理された形に見えます。

ただ、選別には判断が必要になるので、判断が必要な作業はどうしても後回しになります。
あとから何が必要になるかも、そのときには分かりません。
だから転記した時点では選ばず、全部を記録しておいて、あとから要約や抽出をかけます。
つまり、先に全部を集めてあとから絞る発想のほうが、実務ではきちんと回ります。

また、「元のやり取りへのリンク」も必ず残しておきます。
文脈を確認したいときに、元の会話へ戻れるからです。
メールから項目を抜き出す話はメールに埋もれた情報を構造化する。欲しい項目を自動で抜き出すにまとめてあります。

記録する項目は6つで、スレッドはまとめて要約する

「場所と項目が決まっていない」への対処として、転記する項目を6つ決めておきます。
日時、相手先、やり取りの相手、本文、元のやり取りへのリンク、担当者です。

転記した項目とは別に、「要約の列」も作っておきます。
転記した本文から抽出するのは、相手が求めていること、こちらが約束したこと（期限つき）、「未対応の事項」の3つです。
このなかで「未対応の事項」がいちばん価値のある列になります。

「まだ返していない」ことが一覧の形になれば、取りこぼしそのものが防げるからです。
記録は相手先と案件でまとめられる形にしておくと、案件ごとの経緯もあとから追えます。

実務でもう1つ論点になるのが、チャットのスレッドをどう扱うかです。
スレッドは1つの話題のまとまりなので、まとめて記録したほうが文脈が保たれます。
ところが技術的には、スレッドの中の発言が別々に届くので、1発言ずつ転記すると文脈が分かれてしまいます。
対処は、スレッドのIDを記録して同じスレッドの発言をまとめて見られるようにする方法と、スレッドが終わった時点でまとめて要約する方法の2つです。

ただ、後者のほうが、あとから使いやすいと思います。
個別の発言をいくら並べても読み返されませんが、まとまった要約なら読めるからです。

「終わったか」の判定は、時間で機械的に決めてしまいます。
24時間発言がなければ終わったものとして扱う程度で構いません。
厳密でなくて大丈夫です。

ツールが複数に分かれている場合の扱いは複数のチャットツールが混在する組織で、情報を横断的に扱うにまとめてあります。

記録は書いた人に返ってくるから、引き継ぎでいちばん効く

「書いても使われない」への対処は、記録が使われる状態を作ることで、やることは4つあります。
未対応の一覧を毎朝配信し、各担当には自分の未対応の事項だけを送ります。
記録が書いた本人に返ってくるので、これがいちばん直接的な価値になります。

また、担当が不在のときに参照できる経路も作ります。
「この顧客の直近のやり取り」を、誰でも引ける状態にしておきます。
上司が状況を把握できる形にもしますが、個別のやり取りを監視する形にはしません。
未対応の件数と、期限を超えたものだけを見る形にします。

引き継ぎのときにも使えるのは、案件単位で経緯をまとめて渡せるようになるからです。
このなかで、書いた人にとっての価値になるのは未対応の一覧です。

自分の未対応が一覧になれば、記録する意味がそのまま分かります。
引き継ぎの価値は、この施策でいちばん大きいと思います。
異動や退職のときに渡せるのは、相手先ごとの経緯、決まっている条件、過去の要望と対応、「注意すべき点」（過去にトラブルがあった、特定の担当者との関係）の4つです。

このなかでいちばん渡せていない情報が「注意すべき点」です。
「この顧客はこの点に厳しい」という知見は記録に残らず、担当者の頭の中にしかありません。
だから「注意すべき点」の列を作っておき、担当者が気づいたことを1行書く欄にして、自由記述で構わない形にします。

異動が決まった時点で、担当者にこの欄を埋めてもらいます。
担当している相手先の分でも30分あれば書けますし、引き継ぎ資料をゼロから作るよりずっと速く済みます。

引き継ぎの設計そのものは担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計、商談の記録は商談内容を全社の資産にする。文字起こし→要約→記録の自動化で扱っています。

プライバシーの確認は4項目、監視にはしない

この領域は、どこまで確認しておけばいいのでしょうか？
要る項目は4つです。
顧客とのやり取りを社内に蓄積することが契約の範囲内かどうかを、秘密保持契約の内容から先に確認します。
記録を閲覧できる範囲も、営業部門と関係部門に限定して全社には公開しない形で決めます。

相手の担当者名を記録するかどうかも判断し、役職と部門の記録で用が足りる場合は個人名を入れません。
保存期間は、契約期間に一定の期間を足した長さで決めておきます。

社内の担当者の側の整理も要り、自分のやり取りが記録されることは先に周知しておきます。
黙ったまま記録を集めると、それだけで信頼を失うからです。
また、個別のやり取りの内容を上司が読む形にはせず未対応の件数と期限だけを見る形にして、「監視ではない」ことも明示します。

チャットログを組織のナレッジに変える話はチャットに流れた知見を消さない。ログを組織のナレッジに変えるにまとめてあります。

つまずきやすいのは6つです。
選別して転記する、元のやり取りへのリンクを残さない、未対応の一覧を配信しない、個別のやり取りを上司が読む形にする、「注意すべき点」の欄を作らない、契約の範囲を確認せずに蓄積を始める。
どれも、全部を転記して、リンクを残して、毎朝配信して、件数と期限だけを見る形にして、自由記述の欄を作って、先に契約を確認すれば起きません。

受け皿の設計から一緒に詰めたい場合は、当社のAI伴走支援で、業務の洗い出しとAIワークフローの実装を現場の担当者と一緒に進めています。

記録が担当者の手元にしかないから、休むと止まる

担当者が休むと止まるのは、「経緯」「約束」「相手の状況」が担当者の手元にしかないからです。
代わりの人が対応すると、相手に同じ説明をさせることになります。
記録が残らない原因は、「書く手間がある」「場所と項目が決まっていない」「書いても使われない」の3つでした。
書く手間は自動転記で消し、選別せずに全部を転記して、あとから要約や抽出をかけます。

この順序のほうが、実務ではきちんと回ります。
記録する項目は6つで、要約の列を3つ足します。
相手が求めていること、約束したこと（期限つき）、「未対応の事項」のうち、いちばん価値があるのは未対応の事項です。

スレッドは、一定時間発言がなければまとめて要約する形にしておきます。
個別の発言を並べるより、そのほうがあとから読めます。

未対応の一覧は、毎朝それぞれの担当に配信します。
これが、記録を書いた人にとっての価値になります。
引き継ぎでは、経緯・条件・過去の要望・「注意すべき点」を渡せます。

いちばん渡せていない情報が「注意すべき点」なので、自由記述の欄を作って異動の際に埋めてもらいます。
あわせて契約の範囲・閲覧範囲・担当者名の扱い・保存期間の4点を確認し、「これは監視ではない」ことも明示しておきます。

まずは顧客とのやり取りが行われるチャンネルを1つ選び、記録の表に転記する形をつくってみましょう。