顧客・商談CRM
位置づけ: 後続フェーズ
顧客・商談CRMは、顧客情報を世帯（Household）単位で管理し、訪問販売・催事・反響・パートナーの全チャネルを1本の商談パイプラインで扱う。前確（訪問前確認）架電、契約後チェック（ローン審査・団信）、施工進捗、発注、申請、経理向け入金予定までを商談（Deal）配下の独立した軸として持ち、業務全体を1画面から追跡できるようにする。
先行リリース（催事＋アイテム＋商社）の後続フェーズに位置づけ、催事モジュールで獲得したアポの正式な取り込み先、商社（卸）モジュールの発注・仕入先情報の受け皿となる。試作実装（crm_app/app/src/lib/crm.ts ほか）で型定義と主要画面が動作しており、以下は試作の挙動に基づく。
スコープ・対象
Section titled “スコープ・対象”- 対象チャネル（
Channel）は訪問販売・催事・反響・パートナーの4種。テレマは現状実施しておらず対象外。 - 対象範囲は、顧客・世帯・人物、商談パイプライン、活動ログ・案件ロール・マイルストーン、前確・契約後の架電、契約後チェック、施工、発注、申請、経理向け入金予定、担当者アサインまで。
- 価格・見積・粗利の算出ロジックは 見積・価格表 が正本。本ページでは商談が保持する金額項目（提案金額・仕切り・粗利）の位置づけのみ扱う。
- KPI集計・予実管理は KPI・予実ダッシュボード が正本。本ページは集計元となる案件ロール・失注理由の保持方法のみ扱う。
先行モジュールとの接続点は次のとおり。
| 接続点 | 先行側 | 後続側（本ページ） | 内容 |
|---|---|---|---|
| 催事アポの取り込み | 催事モジュール（/events） | Deal(status=アポ, channel=催事) | 催事で獲得したアポを商談として正式登録する |
| 商社・発注 | 商社（卸）モジュール（/wholesale） | DealItem.supplier / Order / LeadtimeInfo | 商材の仕入先・発注状況を案件配下で管理する |
| 価格・商流別価格 | アイテムマスタ（価格非保持） | Deal.proposal / Deal.cost / Deal.margin | 商談の提案金額・仕切り・粗利として反映する |
| KPI集計 | — | Roles / lostReason | 案件ロール・失注理由をKPI予実の分析軸として供給する |
| エンティティ | 主なフィールド | 内容 |
|---|---|---|
| Household（世帯） | name / postal / pref / city / addr | 世帯名（代表姓）・住所 |
| Household | adults / children / taxable | 大人・子ども人数、課税有無。補助金・ローン審査の事前判定材料 |
| Household | memo | 運営メモ（在宅時間帯・連絡のつきやすさ等の自由記述） |
| Person（人物） | relation | 続柄（夫/妻/子/本人/その他） |
| Person | mobile / tel / email | 連絡先。個人単位で複数手段を保持 |
| Property（物件） | builtYear / area / layout / pinType | 築年・面積・間取り・種別 |
| Property | existing[] | 既設設備（太陽光/エコキュート/IH/ガス給湯器）の有無・設置年・メーカー・容量。提案根拠として保持 |
世帯配下に人物（Person）を複数ぶら下げる。商談応対者（Deal.respondentId）と契約名義人（Deal.contractorId）は人物FKとして分離し、応対した人と契約する人が異なるケースを扱う。世帯の表示名は「本人 → 夫 → 世帯の先頭」の優先順で導出し、フルネームをそのまま表示する（敬称は付けない）。
商談（Deal）
Section titled “商談（Deal）”| フィールド | 内容 |
|---|---|
status | 商談パイプラインのステータス（後述） |
channel | 商流（訪問販売/催事/反響/パートナー） |
venue | channel=催事 のときの催事場所 |
hankyoMedia | channel=反響 のときの大元媒体（タイナビ等） |
subject / agency | 実施主体（自社/代理店）と代理店名。登録時にログインユーザーの所属から自動判定 |
roles | 案件ロール（獲得/前確/クローザー/設計） |
items[] | 商材明細（DealItem：種別・メーカー・型番・仕様・保証・仕入先・納期） |
milestones[] | 工程マイルストーン（現調/着工/完工/連携/設備認定/入金） |
tasks[] | 案件タスク（前確/太陽光調査設計） |
notes[] | 活動ログ（DealNote：日付・記入者・自由記述） |
postContract | 契約後チェック（成約時に自動生成） |
construction | 施工フラグ（工事開始時に自動生成） |
payment | 決済・入金（支払方法・決済形態） |
orders[] | 発注（Order） |
applications[] | 申請（Application） |
proposal / cost / margin | 提案金額・仕切り・粗利 |
lostReason | 失注・前確NGの理由 |
商談パイプライン（DealStatus）
Section titled “商談パイプライン（DealStatus）”パイプラインは全チャネル共通の1本。channel は入口属性としてのみ保持し、ステータスをチャネル別に分岐させない。
| ステータス | 意味 | 主担当ロール |
|---|---|---|
| アポ | アポ獲得（入口フォーム送信直後） | 獲得 |
| 前確 | 訪問前確認の架電中 | 前確担当（バックオフィス） |
| 商談 | 前確OK後の訪問・クロージング | クローザー |
| 成約 | 契約成立。契約後チェックを自動生成 | クローザー／設計 |
| 工事 | 施工フェーズ。施工フラグを自動生成 | 設計／施工店 |
| 完了 | 全工程終了 | バックオフィス |
| 保留 | 商談後保留。リマインド対象として追い続ける | クローザー |
| 失注 | 前確NG・商談NG等。lostReason を保持する運用 | 前確担当／クローザー |
| クーリングオフ | 成約後の申込撤回（終了状態） | バックオフィス |
主パイプラインは「アポ→前確→商談→成約→工事→完了」の6状態（DEAL_STAGES）で、advanceStage はこの順で1段階ずつ進める。保留・失注・クーリングオフはこの並びの外側にある分岐・終了状態で、setStatus による明示的な変更で遷移する。
契約後チェック・施工・決済・発注・申請
Section titled “契約後チェック・施工・決済・発注・申請”| エンティティ | 主なフィールド | 内容 |
|---|---|---|
| PostContract | thanksCall / loan / reviewCall / danshin | サンキューコール・ローン審査（LoanStatus 7段階）・審査確認コール・団信を独立軸で管理 |
| Construction | scheduleStatus / photosStored / completionReport / kankosho / renkeiTachiai / renkeiStatus | 日程調整・現地写真・完了報告・完工書・連携日調整（立会有無で連絡経路が変わる） |
| Payment | method / settlement / downPayment / loanTermMonths | 支払方法（現金一括/現金半金/ローン）と決済形態（2社間/3社間） |
| Order | status / orderedAt / dueDate / mailLinked | 発注状況（未発注/発注済/納期回答済/納品済）。納期回答メールの自動紐付けフラグを持つ |
| Application | type / status / docs[] / deadline / linkedAt | 申請種別（9種）・必要書類・期限・連携日 |
| Receivable | due / overdue / amount | 経理向け入金予定一覧の1行（案件横断で算出） |
| 画面 | 内容 |
|---|---|
| 世帯・人物管理 | 世帯配下の人物一覧、続柄・連絡先の編集、物件の既設設備登録 |
| 商談パイプラインボード | ステータス別の案件一覧、advanceStage による段階遷移、保留・失注・クーリングオフへの分岐操作 |
| 案件詳細 | 活動ログ・案件ロール・マイルストーン・商材明細を1画面に集約 |
| 架電（前確）ボード | 本日期日のタスクを一覧化し、担当割り当てと架電結果（DealTask.result。自由記述文字列）を記録 |
| 契約後チェック | サンキューコール・ローン審査・団信・審査確認コールの進捗を独立管理 |
| 施工管理 | 日程・依頼書送付・現地調査・写真・完了報告・完工書回収・連携日調整をフラグで管理 |
| 発注管理 | 商材別の発注状況、商品マスタ優先・メーカー目安フォールバックの納期表示、着工日からの発注期限逆算 |
| 申請管理 | 申請種別ごとの必要書類照合、公的書類の失効期限による優先度表示 |
| 入金予定（経理向け横断ビュー） | ローン案件のうち完工書原本回収済み・入金未完了のものを予定日順に一覧表示し、超過分を強調 |
| 担当者アサイン | 職能ロール（前確/設計）に合う候補者を稼働中タスク数の少ない順に提示し、Slack通知プレビューを生成 |
業務ルール・ワークフロー
Section titled “業務ルール・ワークフロー”ステータス遷移の副作用
Section titled “ステータス遷移の副作用”- ステータスを「成約」に変更すると、
closeDate（成約日）が未設定なら当日を自動設定し、postContractが未設定ならローン前提の初期値で自動生成する。 - ステータスを「工事」に変更すると、
construction（施工フラグ）が未設定なら初期値で自動生成する。 - 成約時は社内チャットルームを自動作成し、代理店案件（
subject=代理店）の場合は代理店ルームも合わせて作成する。工事時は施工店チャットルームを自動作成する。
前確（訪問前確認）と契約後コール
Section titled “前確（訪問前確認）と契約後コール”- 前確は
初回訪問の前とクロージング訪問の前の2箇所にあり、パイプライン上のステータスは分岐させず、前確タスクのゲート（初回前/クロージング前）で区別する。 - サンキューコール・審査確認コールの結果は
CallResult型で未/不出/OK/NGの4値に固定される。「不出」は実運用スプレッドシートの語彙をそのまま採用している。前確タスク（DealTask）の結果はresult（自由記述文字列）に記録し、CallResult型そのものではない。「OK」のような値を入れる運用だが、型としては任意の文字列を許容する。 - 契約後もコールは続き、サンキューコール（クレーム予防、社内実施）と審査確認コール（ローン会社実施、正式可否とは別フラグ）を独立して記録する。
- 発注は工事日（着工）確定後に行う。
- 納期表示は、型番一致の商品マスタを最優先とし、一致がなければ種別×メーカーのメーカー目安（
LEADTIME_MASTER）にフォールバックする。 - 発注期限は着工日からリードタイム日数を逆算して算出する。
- 納品確認のチェック欄は置かない。連絡がなければ納品済みとみなし、納期回答メールの自動紐付けで代替する。
- 必要書類は申請種別ごとのマスター（
APPLICATION_DOC_MASTER）と照合し、案件生成時に自動展開する。 - 公的書類は発行から90日で失効するものとして扱い、書類の失効日・申請期限のうち近い方を緊急度として優先度順に抽出する。
- 入金予定日は、ローン案件かつ完工書の原本回収日（
kankoshoAt）があり、入金マイルストーンが未完了のときに算出する。 - 起算は完工書原本回収日からの営業日数で、ローン会社マスタに登録があればその値（2社間・3社間別）を優先し、なければ2社間3営業日／3社間6営業日を用いる。
- 予定日を超過した案件は経理向けビューで優先表示し、信販会社への確認対象として扱う。
案件ロール（Roles）は獲得・前確・クローザー・設計の4種で、分業体制（獲得担当と成約担当が別人）を前提にする。現状はユーザー名の自由文字列として保持し（DealTask.assignee も同様に自由文字列）、ユーザーFK化は将来対応の予定。バックオフィス担当（前確・設計）は職能ロールに応じた候補者から、現在の未完タスク数が少ない順に提示する。実施主体（自社/代理店）はログインユーザーの所属から自動判定し、代理店ユーザーが登録した案件は自動的に代理店扱いになる。
- 保留案件のリマインド通知経路（チャット/Slack連携の方式）
- 催事場所（
venue）の文字列管理から催事マスタFKへの置き換え時期 - 失注理由（
lostReason）の入力必須化のUIバリデーション実装 - タスク種別（前確/太陽光調査設計の2種）の拡張範囲。施工・申請系タスクとの統合可否
- 10kW超・法人申請における必要書類差分の反映
- 同一世帯への再アプローチ（別チャネルからの重複流入）の名寄せルール