実際の質問を中心に導線を作る
訪問者は提供内容を理解してから連絡します。Tsumiraでは説明と対応フォーム、設定済みの見積や予約先を結べます。価値は受信後に担当者が質問を理解して回答できることです。送信は質問がある証拠であり、受注や有望商談の成立そのものではありません。
元の文脈を残す
名前、連絡先、本文、元ページに加え、対応項目として題目や希望日を保持します。担当者はメールアドレスだけから推測する必要がありません。希望日は予約の確定とは異なります。実際の空きと確認を伴う予約を終えていなければ、確定した予定として案内しません。
- 連絡先と本文
- 問い合わせ元ページ
- 希望日と確定予約を区別
対応状態を整える
新規、既読、返信済み、スパムを扱い、該当する処理で既読や返信の時刻を残します。未回答と対応済みを分け、実際の連絡と一致する状態を付けます。返信済みにしたことだけでは、送信メールが相手へ届いた証拠にはなりません。必要な場合は配信の証跡を別に確認します。
- 新規と対応済みを区別
- 既読・返信時刻
- 通常対応からスパムを分離
顧客の仕事に続ける
対応する処理で問い合わせをCRMの連絡先文脈へ結び付けられます。曖昧な本人情報やスパムを理由に別人を統合しません。内容を理解してから回答、見積、実際の予約、プロジェクトなどを選びます。すべての送信から全業務が自動生成されるという約束ではありません。
- 対応するCRM連絡先の関連
- 慎重な本人確認
- 意図した次の行動
具体的な業務の流れ
提供内容を説明
具体的な訪問者の疑問に答えます。
問い合わせを受信
本文、入力情報、元ページを保持します。
確認して返信
担当を決め、実際の対応状態を反映します。
関係を続ける
顧客の文脈から見積、予約、作業を選びます。
実務を想定した例
例：訪問相談への問い合わせ
訪問者がサービスを読み、希望日を添えて質問します。チームは本文と元ページを確認し、実務上の質問に答えます。空きを確認した上で設定済みの予約へ案内します。問い合わせの返信状態と、後で確定する予約は別の記録として扱います。
この機能についての質問
希望日で予約されますか。
いいえ。希望と、実際の空きや確認を伴う予約は別です。
すべて商談になりますか。
いいえ。連絡先の関連と内容確認から適切な次の対応を決めます。
未回答を見分けられますか。
新規、既読、返信済み、スパムと該当時刻で対応を整理できます。
返信済みなら配信も成功ですか。
対応状態と配信証跡は別です。必要に応じて実際の配信を確認します。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
