共通窓口には何を必須入力する？代表メールと人物を分ける項目表

青葉商会の受付担当小林は、森製作の共通窓口から相談D07を受けました。送信元は部門共用で、本文には担当者名がありません。

CRMが氏名を必須にしているため、小林は森様という架空の人物名で登録しそうになりました。共用窓口を個人扱いすると後から人物数が増えます。

共通窓口に必要な欄と人物に必要な欄を分け、氏名未確認の相談を受け付けられる最小項目を決めます。 参照資料「HubSpot: Default contact properties」で確認した範囲は、人物属性、接点の日付、ライフサイクルという異なる欄。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「会社G05 森製作」の入力は、会社名は確認済みです。ここでは取引先の既存記録を使います。記録の判断欄には「会社IDを必須」と残します。

「窓口C05 生産部共用」の入力は、人物名は未確認です。ここでは宛名に架空の姓を補いません。記録の判断欄には「窓口種別を共用にする」と残します。

「相談D07」の入力は、設備相談、受付日10月10日です。ここでは人物名は確認後に関連付けます。記録の判断欄には「用件と担当営業を必須」と残します。

比較表は横に動かして全ての列を確認できます。

小林と田中は受付を進めるために必要な情報を先に選びます。この例では会社、用件、受付日、処理担当が必須で、共用窓口の人物名は必須にしません。

氏名を無条件必須にする方式は見た目の空欄を減らしますが、仮名入力を誘発します。種別に応じて人物名を求める方式なら、人物が未確認という状態を記録として残せます。

入力規則は人物が分かったかではなく受付を進められるかで試します。会社と用件、受付日、処理担当があれば相談を確認へ回せますが、会社が不明なら共用メールだけで同じ顧客と判断しません。

同じ共用窓口から岡と山田が別々に返答したら、本文や署名で人物を確認して個別記録を関連付けます。一つの共用メールを二人の唯一の同一判定キーにはしません。

最小項目はこの会社の受付に必要な範囲です。請求や契約に必要な名義の確認を省くものではなく、連絡可能という欄も案内送信の許可とは別に管理します。

岡と山田の署名が確認できても、共用メールの送信者が常に同じ人とは限りません。小林は返答ごとに確認できた人物を関連づけ、署名のない返答は共用窓口からの活動として残します。

小林はD07を受付済みにし、佐藤へ窓口人物の確認タスクを渡します。田中は共用窓口・個人窓口の二例で必須欄の試験を行ってから入力ルールを共有します。

共用窓口の氏名が未確認でもD07を保存でき、個人窓口で名前が足りなければ確認表示になるかを確かめます。既存の森様記録は根拠を調べて訂正候補へ分けます。

田中は人物名なしの共用窓口、本人確認済みの個人窓口、会社不明の入力を試します。保存できることだけでなく、確認担当へ用件が届くかを高橋が確認します。架空名が残っていたら根拠を調べて訂正します。

必須欄を決める前に共用窓口と個人窓口の二種類を定義します。人物がいないという誤記録と、人物が未確認という状態を区別します。

受付を進める条件と本人へ連絡するための条件は異なります。未確認の人物名を埋める代わりに、人物確認のタスクを受付へ付けます。

小林は三つの入力例の判定結果を残し、田中は受付の遅延や仮名の有無を点検します。規則の変更後も人物確認が必要な相談を追える形にします。