依頼の取りこぼしをゼロにする。ToDo化を自動で走らせる

依頼のメールを読んで、「後で返信しよう」と思って閉じると、たいていはそのまま忘れます。

思い出すのは、相手から「先日お願いした件は」と連絡が来たときで、思い出さないまま終わることもあります。
この種の取りこぼしは、どこにも記録として残りません。
起きたこと自体に気づかないので、そもそも件数すら分からないのです。

今回は、依頼メールからタスクを自動作成して、この取りこぼしを潰していく設計について書いていきます。
自動化の全体像はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

依頼は、「読む」と「判断する」のあいだで止まります

なぜそこで止まってしまうのでしょうか？
構造のほうから書いておきます。
依頼を受け取ってから完了するまでには、読む(内容を把握する)、判断する(すぐ返せるか、作業が必要か)、作業する(必要な場合)、返信する、という4つの段階があります。

なかでも「すぐ返せない依頼」は、作業が必要だと分かった時点でそのまま後回しになり、読むと判断するのあいだで止まります。
後回しにしたこと自体はどこにも記録として残らず、ただ受信箱の中に埋もれていくだけです。

だから「判断したその時点で、記録する」。
この一点が、この施策の設計の核心になります。

具体的なパターンも整理しておくと、すぐ返せないので後回しにしてそのまま忘れる作業が必要な依頼、他の人に確認してから返す必要があり確認を依頼したところで止まる確認が必要な依頼、誰かが対応すると思って結局誰も対応しない複数人宛の依頼、この3つです。
また、件数がいちばん多いのは、最初の作業が必要な依頼です。
もっとも見落とされやすいのは確認が必要な依頼で、自分では「確認中」だと思っているぶん、止まっているという認識がそもそもありません。
複数人宛の依頼のほうは、個人の工夫だけでは解決しない組織の側の問題で、「担当が明示されていない依頼」で決まって起きます。

依頼メールを、判定してタスクにします

対処の構成は、依頼を含むメールを判定し、タスクとして登録することです。
判定の基準は4つで、質問が含まれている、依頼が含まれている、期限が明示されている、確認や承認を求めている、です。
作られるタスクに入れるのは5項目で、何を求められているか(1行で、たとえば「見積の提出」「日程の確認」)、誰から、期限(明示されていない場合は3営業日後といった既定の期限)、メールへのリンク、状態(未着手・作業中・確認待ち・完了)になります。
なかでも状態に「確認待ち」を入れておくのが要点で、「他の人の返答を待っている」という状態が、それで可視化されます。

要対応の仕分けそのものは「要対応」を自動で仕分ける。受信箱を意思決定の場に変えるにまとめてあります。

確認待ちには催促を、複数人宛には担当を決めます

確認待ちの依頼と複数人宛の依頼は、対処の作り方が違います。
まず確認待ちへの対処ですが、「確認待ち」の状態にあるタスクについて、その待ち時間のほうを見ます。
「3営業日以上、確認待ちになっているもの」は通知し、「この件、確認の返答が来ていませんが」というリマインドが自分自身に届く形にします。
これがあると、待ちの状態でそのまま止まることがなくなります。

確認を依頼した相手にも、「Aさんに確認を依頼中」という状態が見えるようにタスクを共有しておきます。
ただし相手のタスクリストに直接入れるかどうかは、別の判断が必要です。
勝手にタスクを追加されると、相手側の管理が混乱するからです。

通知するだけに留めるほうが無理がありません。
また、期限のない依頼はまず動かないので、確認の依頼にも必ず期限を付けておきます。

複数人宛の依頼のほうは、組織としての設計が必要になります。
担当を決める経路を作ること、既定の担当を決めること、誰も対応していないものを検出すること、この3つをやります。
複数人宛の依頼が来たら誰が対応するかを朝の短い確認の場やチャットで決め、「特に指定がない場合はAさんが一次対応する」形にして振り分け、一定時間経っても状態が変わっていないものを通知する、という中身です。

いちばん実務的なのは、既定の担当を決めておくことです。
一次対応の担当を決めておくだけで、取りこぼしがはっきり減ります。

その担当は輪番にして、1人に負荷が集中しないようにします。
週ごとに交代する形が回りやすいはずです。
期限そのものの管理は期限管理を人の記憶から外す。リマインドの設計と営業日計算にまとめてあります。

顧客リクエストは共有の台帳で管理します

顧客からの依頼は、社内の依頼とは扱いを分けます。
期限の厳しさが違うこと、記録が必要になること、複数人が把握している必要があること、理由はこの3つです。
顧客からの依頼は遅れるとそのまま信頼に影響しますし、何を依頼されていつ対応したかは後から問われる可能性があります。
そのうえ担当が休んでも対応できる状態にしておく必要があるので、顧客リクエストは個人のタスクリストではなく共有の台帳で管理します。

台帳に入れるのは6項目で、受付日、顧客、依頼内容、期限、担当者、状態です。
「期限を超えたものを週に1回まとめて抽出する」工程が、そのまま取りこぼしの検出になります。
対応そのものの記録も残しておくと、いつ、どう対応したのかを後から経緯として追えます。

顧客とのやり取りの記録そのものは顧客とのやり取りを記録に残す。属人化を防ぐ情報の受け皿で扱っています。

管理の設計をまとめると、個人のレベルでは自分のタスクリスト、チームのレベルでは顧客リクエストの台帳と期限を超えたものの一覧になります。
「上司が見るのは、期限を超えたものだけ」にします。
全部を見る形にすると、途端に管理のための管理になってしまうからです。

あわせて、確認待ちが長いものも上司が見ます。
何らかの支援が必要になっている可能性があるからです。
確認そのものは週に1回・10分で終わる形にし、見るのは期限を超えたものと確認待ちが長いものの2つだけで足ります。
さらに「取りこぼしの件数」、つまり相手から催促が来た件数も記録しておくと、そのまま施策の効果を測る指標になります。

会議で決まったことのタスク化は決まったことが実行されない。アクションアイテムを自動でタスク化にまとめてあります。

判定には限界があり、通しの確認が最後の備えになります

判定の精度そのものの問題についても書いておきます。
過検知の典型は3つで、「ご確認ください」という定型の案内に依頼が含まれてしまうもの、複数人宛で自分の担当ではないもの、「対応ありがとうございました」のような完了した件の連絡が確認を求めていると判定されるものです。

対処はそれぞれ違い、定型の案内は送信元を判定から除外し、自分宛でないものは宛先が自分だけのものを優先する条件を加え、完了した件の連絡は「新しい依頼かどうか」を基準に加えます。
「作られたタスクを、簡単に削除できる形にしておく」ことも大切で、過検知されたタスクを1クリックで削除できるようにしないと、タスクリストのほうが埋まって使われなくなります。
削除の記録までは求めておらず、記録を求めた時点でそもそも削除されなくなるからです。

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

判定は完璧にはならず、見落としも起きるので、週に1回、受信箱を通しで見る工程を残します。
それも10分もあれば足ります。

「これで取りこぼしがなくなります」とは言わず、「取りこぼしが減ります」と言うようにします。
「なくなります」と言ってしまうと、確認そのものがされなくなるからです。
もうひとつ、相手から催促が来たらその都度記録すると、そのメールがなぜ判定されなかったのかを見て基準の改善につなげられます。

つまずきやすいのは7つです。
依頼を受け取った時点で記録しない、「確認待ち」の状態を作らない、確認の依頼に期限を付けない、複数人宛の依頼の担当を決める経路を作らない、顧客リクエストを個人のタスクリストで管理する、上司が全部のタスクを見る形にする、過検知されたタスクの削除を面倒にする、この7つです。
どれも判断した時点で記録し、状態に確認待ちを持たせ、確認にも期限を付け、一次対応の担当を決め、共有の台帳に移し、期限超過と確認待ちだけを見せ、1クリックで削除できるようにすれば避けられます。

依頼の記録を台帳とつなぐ仕組みは、私たちのAI伴走支援でも、業務の洗い出しからAIワークフローの実装まで、現場の担当者と一緒に手を動かして作っています。

依頼は、判断した瞬間に記録すれば止まりません

依頼が止まるのは、すぐ返せない依頼が「読む」と「判断する」のあいだで後回しになり、それがどこにも記録されないからです。
だからこそ、判断したその時点で記録します。
取りこぼしのパターンは3つで、作業が必要な依頼(最も多い)、確認が必要な依頼(最も見落とされる)、複数人宛の依頼(組織の問題)です。
タスクに入れるのは5項目で、「状態」に「確認待ち」を入れておくのが要点です。

3営業日以上、確認待ちのものは通知し、確認の依頼にも忘れず期限を付けます。
複数人宛の依頼は、既定の一次対応の担当を決めておくのがいちばん実務的で、担当は輪番にして負荷を分散します。
顧客リクエストは、期限の厳しさ、記録の必要性、複数人が把握している必要という3つの点で社内の依頼と違うので、共有の台帳で管理します。
見える化は、上司が期限を超えたものと確認待ちが長いものだけを見る形にすれば、確認は週に1回、10分もあれば足ります。

いま止まっている依頼は、自分の受信箱に何件残っているでしょうか？
まずは自分の依頼について、「確認待ち」の状態を持つタスクリストをつくってみます。