ブランド開発プロジェクトの見積をお願いします。
元の問い合わせ · ウェブサイトからの問い合わせ
最初のメッセージを、もう一度転記しないために
新しい問い合わせには、名前、連絡先、相談の目的がすでに含まれます。別の名簿へ手入力し直すと、仕事を始める前に引き継ぎが増えます。Tsumiraは対応する受付の流れをCRMへつなぎます。返信する人は、空の顧客記録ではなく、届いた情報とその出所から対応を始められます。
Web問い合わせを顧客に関連付ける
対応するWeb問い合わせでは、CRM側で担当者を認識または作成し、顧客の言葉を活動に記録できます。問い合わせにも、その担当者との関連が残ります。メールや正規化した電話を認識に使います。すでに迷惑と分類された問い合わせは、この処理で顧客にはしません。元の問い合わせはWebサイトの作業領域で確認でき、対応の判断につながります。
- 問い合わせと担当者の関連
- 顧客活動に残る問い合わせ文
- 迷惑分類を考慮した処理
見積依頼や予約の出所を残す
見積依頼からは、元の依頼への参照を持つ商談と担当者の関連を作れます。予約の作成にも顧客情報と担当者の関連があります。それぞれ固有の検証や有効なモジュールを必要とする流れです。質問を送った人、見積の質問に回答した人、日時を予約した人では、次の対応が異なります。すべてを同じ一般的なリードへ置き換えず、その違いが分かる文脈を保ちます。
- 見積依頼の出所
- 予約と担当者の関連
- 受付経路ごとの検証
曖昧な一致を無理に確定しない
連絡先が複数の担当者に一致する場合、対応する問い合わせや見積依頼を、任意の一人へ結び付けません。CRMとの関連付けを見送り、元の受付を確認して解決できます。同じ受付の繰り返し処理でも、新しい活動をむやみに増やさない仕組みがあります。すべての人物を自動識別できると約束せず、確認できる顧客履歴を保ちます。
- 複数候補から任意に選ばない
- 元の受付を確認できる
- 出所を考慮した重複処理
具体的な業務の流れ
受付を用意する
問い合わせ、見積依頼、予約の設定を確認し、必要なモジュールと処理を利用可能にします。
顧客の情報を受け取る
元の受付に連絡先と質問、依頼、予約の内容が記録されます。
CRMの文脈を見る
関連する担当者や商談を開き、出所と活動を確認します。
対応を引き受ける
担当と次の行動を定め、曖昧な関連付けは確認してから利用します。
実務を想定した例
利用例：Webからの相談を追う
Webフォームから、今後の業務について相談が届いたとします。対応する処理はメールから既存の担当者を認識し、相談文を活動に残します。担当者は会社との関連を確認し、次回の連絡日を決めます。もし同じメールに複数候補があれば、元の問い合わせを確認して判断し、強制された関連付けには頼りません。
この機能についての質問
すべての外部チャネルから必ず顧客が作られますか。
一律のルールではありません。問い合わせ、見積、予約、各チャネルには固有の前提と認識の動作があります。
迷惑と分類した問い合わせはどうなりますか。
Web問い合わせのCRM処理は、すでに迷惑とされたものを見送ります。その処理から新しい顧客は作りません。
同じメールが複数の人に使われていたらどうなりますか。
問い合わせと見積の処理では、任意の一人に割り当てることを避けます。元の依頼を見て、チームで関連を確認します。
モジュールやバックグラウンド処理なしでも動きますか。
いいえ。関係するモジュールと処理が利用可能である必要があります。説明される関連が、すべての環境で全チャネルの設定済みを意味するわけではありません。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
