コンテンツ・紹介・入札が別表に入り、同一グループの別事業部が新規になる。
01 Industry judgment
提案と年枠 · 企業向けサービス
企業サービス成約は「提案送付済」で死ぬ。診断・異論・年枠起算を遡れるようにする
診断参加者・提案異論・年枠周期が個人メモだけだと、更新前に当時の人日約束を突合できない。グループと事業部が複数新規になり、入札勝率と更新リスクが経営会議に入らない。
コンサル・アウトソース・実装・年枠制。診断・提案レビュー・更新がある。顧客と商機を管理し、PMツールは代替しない。
企業向けサービス · 業務のつなぎ方
リード入庫
- ニーズフォーム
- 紹介
- 入札情報
アカウント台帳
- グループ／事業部
- 決裁委員会
- 利用中ベンダー
フォローアクション
- 提案版メール
- レビュー日
- 利用量と更新
マネージャーボード
- 重複フォロー
- デモ済でレビュー日なし
- 更新前未再訪
02 Process diagnosis
提案—年枠判断のあと六項。グループと事業部を同一アカウントへ。決裁委員会と提案版を商機へ。更新前に利用量とサービス課題を読む。範囲変更は先に記録してから追加販売。レビュー日なしのデモは有効推進にしない。
提案の多回説明後に比較選考。決裁委員会名簿と次レビュー日がなく、商機が返信待ちで止まる。
転換が難しい
顧問デリバリと営業が別群。更新2か月前に利用量低下に気づく。
管理が難しい
售前の人日がデリバリで超過し、顧客は当時のデモ資料しか認めない。
信頼が難しい
月次は新規契約額だけ。入札勝率・更新リスク・紹介ソースが定例に入らない。
意思決定が難しい
意思決定交渉力と提案版管理が同時に要る。售前増員だけ／システム導入だけでは年枠が揃わない。
解決が難しい
03 Matching management actions
01 · 獲得が難しい
グループと事業部を同一アカウントへ
フォームで予算周期と利用中ベンダー。紹介と入札を分列。名刺再訪は担当へ。
02 · 転換が難しい
決裁委員会と提案版を商機へ
各版は指定者へメール。次レビュー日なしをデモ済にしない。
03 · 管理が難しい
更新2か月前に利用量シグナル
デリバリと営業が同一会社を読む。售前人日を商機に書き、デリバリで突合。
04 · 信頼が難しい
範囲変更を商機から契約へ照合
通話・メールはその会社に。範囲外は先に変更記録、その後追加販売。
05 · 意思決定が難しい
入札停滞と更新空白で投下評価
勝率は段階、更新は期限、ソースはチャネルで分列。
06 · 解決が難しい
まずアカウントと商機を揃え、その後スクリーニング
フォーム・メール・名刺で意思決定チェーンを閉じる。沈黙商機の需要が明確になってから外呼。
Business architecture
企業サービスはアカウント＋商機。グループ・決裁委員会・提案版・更新は同一会社上。
リード入庫
ニーズフォーム
紹介
入札情報
アカウント台帳
グループ／事業部
決裁委員会
利用中ベンダー
フォローアクション
提案版メール
レビュー日
利用量と更新
マネージャーボード
重複フォロー
デモ済でレビュー日なし
更新前未再訪
Product role on this path
solutions.capabilitiesLead
Three questions before go-live
Sales will not fill forms, it fights the current stack, data will not migrate — almost every team asks these three.
プロジェクト型サービスになぜCRM？
更新と追加販売で人を探す必要がある。提案版・決裁者・更新日は顧客上に。
PMツールと重複？
PMはタスク。CRMは誰が顧客か、どの範囲版か、次に誰が連絡するか。
パートナーが顧客を共有したくない
共有なしでは引き継げない。システムは現担当を記す——誰が先にWeChat追加したかではない。