法人と個人の相談が混ざるCRMは？顧客種別と必要項目の整理

青葉商会の受付小林は、法人の森製作と個人事業の岡工房から設備相談を受けます。共通の受付フォームは会社部署を必須にしており、岡工房では該当しません。

部署へなしを入力すると実際の部署名と同じ扱いになり、法人限定の集計へ個人事業も混ざります。

顧客種別と欄の意味を定義し、適用する項目・対象外・未確認を入力状態として区別します。 参照資料「HubSpot: Create and edit properties」で確認した範囲は、レコードの属性欄、標準欄と独自欄、空欄の区別。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「法人 森製作」の入力は、会社名・部署・窓口です。ここでは未記入なら未確認にします。記録の判断欄には「部署は確認対象」と残します。

「個人事業 岡工房」の入力は、屋号・窓口です。ここでは0やなしという部署名を作りません。記録の判断欄には「部署は対象外」と残します。

「種別が不明の相談」の入力は、名称だけ届くです。ここでは法人と個人のどちらにも確定分類しません。記録の判断欄には「種別未確認」と残します。

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

小林と田中は会社名という欄が法人名と屋号のどちらを受けるかを定義します。種別に応じた表示を作る場合も、元の確認状態を残し、見た目の空欄だけで不備を判定しません。

共通項目だけに絞れば受付は軽くなりますが、法人の部署別対応には不足します。種別ごとに必要項目を分けると、岡工房へ存在しない部署を尋ねずに済みます。

対象外はその種別に項目が必要ない状態、未確認は必要な情報をまだ確認していない状態です。部署が存在しない岡工房へ未確認を使うと、不要な確認依頼が続きます。

一人法人でも法人種別にします。従業員人数だけで個人事業へ分類せず、窓口が示した取引名義を確認します。顧客の属性が分からない間は受付担当が確認を引き受けます。

この分類は営業情報の整理を目的にします。税務・法令上の取扱いや本人確認の要件をこの項目表だけで決めるものではありません。

小林は取引名義が法人か屋号かを確認するタスクを持ちます。種別が変わったと判明した場合は確認日を残し、過去の相談の名義までまとめて書き換えません。

小林が法人・個人事業・不明の三例を使い、田中が各欄の定義と適用条件を項目表へ記します。営業へ渡す際は不足項目と対象外項目を別に表示します。

岡工房の部署が入力エラーにならず、森製作の部署未確認が要確認として見えるかを点検します。法人だけの一覧で不明種別を含めるかも明示します。

田中は法人、個人事業、種別不明の三入力で必要欄の判定を試します。人数だけで種別が変わる設計になっていないか確認し、誤分類を直す際は取引名義の根拠を添えます。

共通の受付情報と種別ごとの情報を分けます。対象外と未確認を別の状態にすると、空欄を埋めるための仮入力を減らせます。

会社名の欄へ法人名と屋号のどちらを記すかを定義します。一人法人の部署がないことと、個人事業であることを混同しません。

小林が種別の確認を引き受け、田中は三種類の入力を照合します。必要でない欄が空でも受付を進められるかを確認します。