毎月10日頃になると、経理チームはいつも同じ依頼を送ります。各クライアントから5つのファイル、つまり銀行取引明細書、領収書アーカイブ、給与レポート、売上集計、そして在庫書類を提出してもらう必要があるのです。テンプレートは親しみやすく、正確で、テストも済んでいます。クライアントの名前を呼び、必要なファイルをリストアップし、明確な期限を提示します。最初の送信では、うまく機能します。クライアントは整ったリストを見て、それに応答します。

問題は、2通目のメールから始まります。

あるクライアントが4つのファイルだけを送ってきたと想像してください。5つ目の銀行取引明細書はいつまでも届きません。領収書アーカイブは届いていますが、対象月が間違っているため、チームはそれを却下します。給与レポートは、実は3日前にSlackで送られており、誰かがすでに処理済みです。在庫書類については、最初のメッセージを送った後に初めて、そのクライアントには全く不要なものであることが判明しました。もし元のテンプレートを再送すると、再び5つのファイルを要求することになります。そのうち4つの要求は無意味であり、1つは誤解を招くものです。文言自体は問題ありません。ただ、メールには「記憶」がないのです。

メールテンプレートは、名前、日付、指示の管理には優れています。単発の小さな依頼であれば、通常それで十分です。一人の担当者がメールを送り、クライアントが返信し、同じ担当者がそのタスクを完了させる。履歴は一つの頭脳と一つの受信トレイの中に収まっています。

問題が発生するのは、次のメッセージが「最初のメールの後に起きた出来事」に依存する場合です。テンプレートには依然として元のリストが表示されたままです。昨日、銀行取引明細書が届いたことも、給与レポートが却下されたことも、テンプレートは知りません。それらのデータは受信トレイ（おそらく複数の受信トレイ）の中にあり、リマインダーを生成するアプリケーションにはそれを読み取る手段がないのです。

「Open（未完了）」だけでは不十分なとき

リクエスト全体を「Open（未完了）」のような単一のステータスとして追跡してしまうと、重要な詳細を見失ってしまいます。各項目は独立して動くものです。次のコミュニケーションを正確なものにするためには、それぞれの項目に独自のステータスが必要です。

  • 銀行取引明細書: 未提出。クライアントから送られていない。
  • 領収書アーカイブ: アップロード済みだが未確認。内部チェック待ちでフォルダに置かれている状態。
  • 給与レポート: 却下。クライアントは何かを送ってきたが、形式が違うか、対象となる給与期間が間違っている。
  • 売上レポート: 別チャネルで受領済み。Slack、電話、または郵送で届いており、チームはすでに記録済み。
  • 在庫書類: 該当なし。このクライアントには提出の必要がなく、システムは要求を停止すべきである。

このような内訳がなければ、リマインダーは「盲目」です。未提出のファイルと却下されたファイルを同じように扱ってしまいます。すでに手元にあるファイルを、まるで届いていないかのように扱います。これはクライアントの時間を無駄にし、信頼を損なう行為です。無関係なリマインダーが2、3回続くと、クライアントは内容を読み飛ばすようになります。そして、あなたのシステムは壊れているのだと思い込むのです。

必要なものだけを作る

最初から巨大なルールエンジンを作る必要はありません。初日から20もの条件分岐を持つワークフロー自動化など必要ないのです。まずは、「クライアントによるアクションがまだ必要なものは何か？」という一つの問いに答えるために、必要最小限のデータを追跡することから始めましょう。

要求された各項目には、永続的な結果（記録）が必要です。つまり、アプリケーションが次のメッセージを作成する際に読み取れる場所、つまりメールのスレッドの外にある記録のことです。その記録は複雑である必要はありません。項目名、現在のステータス、タイムスタンプ、短いメモを保持する構造化されたテーブルのような、シンプルなもので構いません。重要なのは、データが受信トレイを超えて存続することです。

これにより、メールの役割が変わります。テンプレートは引き続きトーンと構造を制御します。挨拶は温かく、指示は明確なままです。しかし、書類のリストはリクエストのデータから取得しなければなりません。リマインダーは「クエリ」へと変わります。クライアントのアクションが必要な項目だけを表示するようにリストをフィルタリングします。内部レビュー待ちの項目は除外します。すでに受理された項目も除外します。

アップロードが却下された場合は、リマインダーでその旨を伝え、理由を説明すべきです。クライアントが単に送り忘れたかのように、その書類を単なる一般的なリストに黙って戻すべきではありません。クライアントは自分が何かをアップロードしたことを知っています。それとは違うふりをするのは、組織として無秩序に見えるだけです。

引き継ぎテスト

この追加のデータモデルが必要かどうかを知るための、簡単な方法があります。こう問いかけてみてください。

「他のチームメンバーが、メールのスレッド全体を読み込むことなく、このリクエストを引き継ぐことができるだろうか？」

単一のファイルであれば、その答えは重要ではありません。しかし、多くの要素が絡み合う毎月の定型的なリクエストとなると、話は大きく変わります。もし主担当者が休暇中だった場合、同僚は数秒で何が不足しているかを把握できるでしょうか？マネージャーは、10通ものメールや3つの共有フォルダを開くことなく、クライアントの対応状況を確認できるでしょうか？もし却下された記録が、署名や転送メールに埋もれたスレッド内の4番目のメッセージにしかないとしたら、あなたのシステムは、データベースが行うべき作業を人間に強いていることになります。

テンプレートはメッセージの質を高めます。追跡可能なリクエストは履歴を保存します。一方は「伝え方」を、もう一方は「把握している情報」を扱います。

スクリプトではなく、クエリを

アイテムレベルの状態が管理できていれば、メールの生成はスクリプト作成からクエリ実行へと移行します。以前は、段落を書き上げ、それがまだ正確であることを祈るしかありませんでした。しかし今では、データに対して「これらのアイテムのうち、クライアントの対応が必要なものはどれか？」と問いかけることができます。そのフィルタリングされたリストに基づいて、リマインダーを作成するのです。対応が必要なものがなければ、リマインダーは一切送信しません。もし2つのアイテムに対応が必要で、そのうち1つが特定の理由で却下されていた場合、メールはその事実に基づいて自動的に構成されます。

これは