おっと!フォームの送信中に問題が発生しました。
Saiが受信メールを読み取り、送信者名、メールアドレス、会社名、ドメイン、件名、目的、および記載されている電話番号や予算を抽出します。その後、メール1通につき1行を追加し、最後の列にJSON形式のコピーを保存します。記録された実行結果では、119件のメッセージをスキャンし、111件を分類、そのうち条件に合致した23件をログに記録しました。
The recording is a real session. The sheet on the right is what it produced.
Sai opens each profile, pulls the signal, and writes the row, live, in a real browser.
Eight columns, sorted by score, with a source link behind every claim.
Gmailへのアクセス権と対象のGoogleスプレッドシートが必要です。Gmailラベル、またはカテゴリの平易な説明のいずれかをご用意ください。
送信者名、メールアドレス、会社名、ドメイン、件名、目的、および記載された電話番号や予算を含むメール1通につき1行のデータと、一貫したキーを持つJSONコピーが最後の列に作成されます。タブ名、行範囲、実行前後のログ件数が報告され、除外された項目とその理由も併せて提示されます。
アクティブな受信メールには1時間ごとの実行が適しています。即時対応が不要な場合は、1日1回で十分です。
メールデータ抽出とは、受信メールの内容（送信者、組織、依頼内容、本文中の数値や日付など）を、他のシステムが読み取れる名前付きフィールドに変換するプロセスです。
メールは、ヘッダーセットと本文の2つの部分で構成されます。ヘッダーは標準化されており、RFC 5322で定義されています。 From フィールドはメッセージの作成者を示し、 Reply-To は作成者が返信先として指定したアドレスです。これらは異なる場合があり、その際は運用上、返信先アドレスが重要となります。ヘッダーにはメッセージ識別子、日付、件名も含まれます。
本文は標準化されていません。署名ブロック内の送信者名、所属企業、依頼の規模、言及された期限などは、送信者が選んだ形式で文章の中に現れます。定義された位置からこれらを読み取るパーサーは存在しません。
この分割構造こそが、メール抽出とフォーム送信の解析が異なる理由です。情報の半分は固定されたスキーマにありますが、残りの半分は自由記述であり、次に何が起こるかを決定するのは通常、この非構造化された半分の方です。
お問い合わせフォームは、フォーム側でフィールドが定義されているため、毎回同じ形式でデータが生成されます。一方、受信メールは送信者が書いた通りの形式で生成されます。
同じ内容の問い合わせであっても、署名ブロック付きの3行のメモとして届くこともあれば、予算が文中に記載された8段落のメッセージとして届くこともあります。どちらも同じ運用上の事実を含んでいますが、それらが同じ場所に記載されているわけではありません。
一般的な回避策には、それぞれ欠点があります。転送ルールはメールを移動させるだけで、内容は読み取りません。正規表現は電話番号を確実に抽出できますが、会社名の抽出は不確実です。ZapierのEmail Parserはサンプルメールに基づいたテンプレート作成が必要であり、レイアウトが固定された機械生成メールには有効ですが、人間が自由に書いた文章には対応できません。
その結果、実務上は受信メールを手作業でCRMやスプレッドシートに入力することになり、入力される項目も担当者が時間を割けた範囲のものに限られてしまいます。
インバウンドの問い合わせに対応する営業チーム。 リードは誰かが手入力するまでCRMではなく受信トレイに留まり、企業名、従業員数、予算、検討時期といったリードの質を判断するための詳細情報はメール本文の中に埋もれたままになります。
サポートおよびオペレーションデスク。 メールで届くリクエストは、ルーティングを行う前に、カテゴリ、依頼者、アカウント参照情報を特定する必要があります。
直接応募を受け付ける採用担当者。 候補者名、希望職種、現在の勤務先が、本文の文章と添付ファイルという形で届きます。
受信トレイの内容をスプレッドシートで管理しているすべての方。 転記作業そのものが業務のすべてとなってしまっています。
手作業による再入力は、すべての情報を正確に読み取ることができます。この表の中で唯一それが可能な手法であり、その理由から最初に記載しています。この手法の制約は精度ではなく、処理能力にあります。
Saiはユーザーの代わりにGmailを開き、指定されたメッセージを読み取って、指定したフィールドを含むJSON形式で返します。
フィールドリストは設定を行うのではなく、自然言語で記述します。送信者名、会社名、メールアドレス、リクエストタイプ、予算、期限を求めれば、その6つのキーが返されます。特定のフィールドが存在しないメールの場合でも、キーを省略せずにnullとして返すため、バッチ処理全体で出力形式が一定に保たれます。
ヘッダーフィールドはメッセージヘッダーから取得され、本文フィールドは文章から読み取られます。テンプレートを作成したり、学習用のサンプルメールを用意したりする必要はありません。
メールから抽出されたJSONは通常他のシステムに書き込まれるため、重複の管理が重要になります。Gmail APIには2つの識別子が用意されていますが、これらは互換性がありません。
id は、メッセージ（特定のメール1通）の不変のIDとして定義されています。 threadId は、そのメッセージが属するスレッド（会話）のIDであり、返信を含めたすべてのメッセージで共有されます。
スレッドをキーにすると、返信のたびに既存のレコードが更新されます。一方、メッセージをキーにすると、返信ごとに新しいレコードが作成されます。どちらが適切かは、業務の単位が「会話」なのか「個別のメッセージ」なのかによって決まります。この違いを理解せずに選択すると、意図しない上書きやリードの重複が発生する原因となります。
出力の有用性はフィールドリストの内容次第ですが、よくある失敗は必要以上に多くの項目を要求してしまうことです。
メールに確実に含まれるフィールドは値が埋まりますが、通常は存在しないフィールドを要求すると、ほとんどのバッチでnullが返されることになり、情報量が増えないままキーだけが増加してしまいます。
送信者、送信元、用件、および記載された数値や日付といった最小限のリストがあれば、ルーティングや適格性の判断のほとんどをカバーできます。フィールドは、最初のバッチで実際のメール内容を確認してから追加すれば十分です。
インバウンド処理ではなく、スケジュールされたアウトバウンド処理を行う場合は、 Gmailでのメール予約送信 が送信側を処理します。
抽出されたレコードがシートに反映され、そこに企業データを追加する必要がある場合、 リードリストのエンリッチメント がその後の工程を担います。
メールの内容よりも、どのメールに返信すべきかが重要となる受信トレイでは、 メール管理 がトリアージを行います。
