「要対応」を自動で仕分ける。受信箱を意思決定の場に変える

受信箱を開いたとき、何から手をつけるかを毎回その場で判断しています。

100通並んでいるなかから、対応が必要なものを探すだけで5〜10分かかり、それを1日に数回繰り返します。
探すたびに判断が必要になるので、単純に疲れます。
疲れてくると、後回しにするという判断のほうが増えていきます。

今回は、Gmailのようなメールに、AIで自動でラベルを付けて仕分ける設計について書いていきます。
自動化の全体像はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

受信箱が積み上がるのは、同じ判断を繰り返しているから

何が起きているのでしょうか？
整理すると、損失は4つあります。
対応が必要なものを探すのに時間がかかり、同じ判断を100回繰り返し、「後で対応しよう」と閉じたものを次に開いてまた判断し直し、返信したかどうかを覚えていないため対応済みかも分からない、この4つです。

いちばん損失が大きいのは、同じ判断を繰り返す2つの損失です。
まったく同じ判断を、何度も繰り返しているからです。
だから、一度判断した結果をその場に残します。
これが、仕分けという施策の本質になります。

要対応をAIが判定するという発想

やることは、届いたメールについて対応が必要かどうかを判定し、そこに印を付けておくことです。
そのために、「対応が必要」の定義を先に決めておきます。
質問が含まれている、依頼が含まれている、期限が明示されている、確認や承認を求めている、この4つは対応が必要です。
逆に、情報提供や定例の報告、通知や案内、すでに完了した件の連絡は対応が不要です。

判定の基準は4〜6個に絞ります。
網羅的にしようとすると、精度のほうが落ちます。

「対応が必要かの判定」と「緊急かどうかの判定」は、別のものとして扱います。
対応が必要だけれども急がない、というメールがあり、この2つを混ぜると仕分けそのものが機能しなくなります。

重要度の判定のほうは重要な連絡を埋もれさせない。メールの優先度判定を自動化するにまとめてあります。

導入はラベルで仕分けてから、優先度つきの通知に進みます

導入は、段階を踏んで進めます。
最初にやるのは、対応が必要と判定されたメールにラベルや印を付けるところまでで、この段階では通知しません。
判定の精度を確認するのがこの段階の目的で、精度が分からないうちに通知を飛ばすと、誤った通知が仕組みへの信頼を失わせます。
確認の方法は、2週間分について印が付いたものと付かなかったものを自分で見て、見落としと過検知の件数を数えることです。

見落としが1件でもあれば、基準のほうを見直します。
対応が必要なのに印が付かないことが、最も問題になるからです。
期間の目安は2〜3週間で、ここで精度が安定してから次に進みます。

精度が安定したら、優先度をつけて通知する段階に入ります。
優先度は3段階にして、高は期限3営業日以内または重要な相手から、中は対応は必要だが期限に余裕がある、低は確認だけで済むもの、と分けます。
また、通知の頻度も分け、高は即時、中と低は1日1回まとめます。

通知に入れるのは4つで、送信元、件名、何を求められているか(1行)、メールへのリンクです。
なかでも効くのが「何を求められているか」です。
「見積の提出を求められている」「日程の確認を求められている」といった一行があれば、メールを開かずに優先順位を判断できます。

もうひとつ見ておきたいのが、1日の通知件数です。
高が5件を超えてくると、優先度という区分の意味そのものが薄れるので、そのときは基準を絞ります。

タスク管理に接続すると、依頼を一元管理できます

最後に、対応が必要と判定されたものをタスクリストに登録する形にします。
「メールを開かなくても、やることが一覧になっている」状態を作るということです。
登録するのは4項目で、何を求められているか、相手、期限、メールへのリンクです。
また、完了の管理はタスクリストのほうで行い、メールの受信箱では管理しません。

この形の利点は3つあります。
一度タスクになれば再判断が不要になり、対応済みかどうかはタスクの状態でそのまま管理され、メールで来た依頼と会議で決まった宿題を同じ場所で一元管理できる、この3つです。

いちばん価値があるのは、最後の一元管理です。
依頼の経路によって管理の場所が分かれてしまっている状態が、そこで解消されるからです。
会議で決まったことのタスク化は決まったことが実行されない。アクションアイテムを自動でタスク化、依頼そのもののToDo化は依頼の取りこぼしをゼロにする。ToDo化を自動で走らせるにまとめてあります。

過検知には型があり、見落としには備えが要ります

実務で必ず起きる問題についても書いておきます。
過検知の典型は3つあります。
「ご確認ください」という定型の案内に依頼が含まれてしまうもの、複数人が宛先に入っていて自分の担当ではない依頼、「対応ありがとうございました」のような完了した件の確認が求められていると判定されるもの、この3つです。
定型の案内は送信元を除外し、完了した件の確認は「新しい依頼かどうか」を基準に加えて対処します。

ただ、いちばん難しいのは、自分宛でない依頼です。
誰の担当なのかは、メールの内容だけでは判断できないことがあるからです。
現実的な対処は、複数人宛のものは優先度を中か低に下げておくことです。

一方、見落としのほうは避けられません。
だから備えのほうを設計しておきます。
判定されなかったメールについても、1日1回件数だけは確認します。
「印が付かなかったが対応が必要だった」ものは記録して、基準に反映していきます。

もうひとつ、週に1回は受信箱を通しで見る工程を残しておきます。
判定に依存しきらないためで、時間は10分もあれば足ります。

判定は完璧にはならないので、「これで見落としがなくなります」とは現場に言わないほうが安全です。
そう言ってしまうと、確認そのものがされなくなるからです。

期限の管理は期限管理を人の記憶から外す。リマインドの設計と営業日計算、メール対応の標準化はメール対応の品質と速度を組織でそろえる。返信・要約の標準化で扱っています。

つまずきやすいのは6つです。
「対応が必要か」と「緊急か」を混ぜる、精度を確認せずに通知する、判定の基準を10個以上作る、「何を求められているか」を入れない、過検知の除外を運用しない、判定に依存しきる、この6つです。
どれも2つの判定を分け、まず印を付けるだけにして、基準を4〜6個に絞り、1行の要約を添え、除外の一覧を運用し、週1回通しで見る工程を残せば避けられます。

受信箱の判定基準づくりから仕組みの実装までは、私たちのAI伴走支援でも、現場の担当者と一緒に手を動かしながら進めています。

受信箱は、一度判断した結果を残す場に変わります

受信箱が積み上がるのは、探す時間がかかり、同じ判断を繰り返し、一度見たものを再度見て、対応済みかが分からなくなるからです。
だから、一度判断した結果をその場に残します。
「対応が必要」の定義は質問・依頼・期限の明示・確認や承認の4つで、基準は4〜6個に絞り、「緊急かどうか」の判定とは明確に分けます。

進め方は3段階です。
まず印を付けるだけにして2〜3週間かけて精度を確認し、次に優先度つきで通知し、最後にタスク管理へ接続します。
タスク管理の最大の価値は、メールで来た依頼と会議で決まった宿題を、同じ場所で管理できるようになることです。
過検知の典型は、定型の案内、自分宛でない依頼、完了した件の確認の3つで、見落としには週1回10分の通し確認を備えます。

受信箱を開いたとき、いま何を基準に手を付けていますか？
まずは「対応が必要」の定義を4〜6個書き出し、印を付けるだけの形にします。