仕組みの設計

顧客・商談・時間・お金・施策・指標。SFAの数字がずれる原因を6つの数え方に分解し、自己診断10問で着手順を決める

異動で過去の実績が動く、予測の精度が測れない、単価の改善が本物かわからない。営業データで詰まりやすい5つの論点と、繰り返し使える5つの設計パターン

Kimball流のスタースキーマ、データ品質のテスト、SFAと分析基盤の往復。目標と実績の比較を「2つの表を同じ物差しで並べる」問題として設計する

見る人によって数字が違う、定義の持ち主がいない、営業が入力しない、定義を黙って変える。決めた数え方を組織の中で守り続けるための4つの論点

概念設計→論理設計→物理設計→分析活用。今どの層の問題かを切り分ける思考の地図

10領域の業務がどんなデータを生み、どのシステムに溜まるかの見取り図

3層構造の役割分担と、GTMデータ基盤でどう使い分けるかの実務論点

CRMのSSOT化、名寄せ、ウォーターフォールエンリッチメントなどGTMデータ基盤の作り方

ICP定義をルールベース・MLベースで数値化し、ティアリングへ落とし込む実務

「提案」ステージの中身が人によって違う、リードの引き継ぎで揉める。営業プロセスを、縮尺・出口条件・役割・引き継ぎの4つで設計する

商談が遅いのは、作業が遅いからではない。例外の道、待ちの見える化、判断の段階分けで、営業プロセスの流れを良くする

壊れたプロセスを自動化すると、間違いが速く大量に起きる。自動化と人の境界、量・速さ・質の測定、改善の回し方、プロセスとデータの対応を整理する

商談プロセス実装・リードルーティング・データ品質監査などCRM運用の実務論点

メールインフラ・シーケンス設計・AIパーソナライゼーション・HITL設計の実務論点

ヘルススコアのパイプライン化、オンボーディング自動化、チャーン予兆ワークフローの実装

ツールは増えたのに、どこを見ればいいかわからない。機能の多さで選んで使いこなせない。ツールの役割分担、要件に基づく選定、標準かカスタムかの判断を整理する

項目が増えすぎて入力されない。誰でも全顧客を見られる。自動化が衝突して値が上書きされる。SFAの設定でよく壊れる、項目・入力体験・権限・自動化の置き場所を整理する

本番を直接触って入力が止まる。使われない項目が溜まる。使っていない席に払い続ける。ツール運用でよく壊れる、環境と変更の流れ・技術的負債・費用と出口を整理する

In/Out of Scopeの明文化、MoSCoW法、Big Bang vsフェーズドロールアウトの判断基準

BtoB/BtoC・成長フェーズ・業界特性に応じたデータモデル設計の差分

他システム連携、ビルドvsバイの判断基準、環境戦略など実装フェーズの典型論点

標準機能→AppExchange→ビルドの判断フローと、代表的な連携カテゴリの見取り図

契約・既存org・権限設計・データ品質など、構築着手前に確認すべき7つの観点

マーケティング・セールス・データ連携基盤・AIなど部門別に、どんな種類のツールが並ぶかの構成例

SFAと請求システムで顧客の住所が食い違う。双方向の連携で値が消える。名前でつないで別会社に上書きする。連携設計の基本、正の所在・方向とタイミング・キーを整理する

再送のたびにレコードが増える、失敗に数週間気づかない、APIの上限でほかの連携まで止まる。連携を止まらず二重に動かない仕組みにする3つの論点

相手が選択肢を1つ追加しただけでデータが漏れる、担当者の退職で連携が止まる、作った人しか直せない。連携を長く動かし続けるための4つの論点

外部SaaSとCRMをつなぐ連携実装で、コードを書く前に決めておくべき3つの設計ステップ

SalesforceとGoogleスプレッドシートの連携を、アドオン・iPaaS・Google Apps Script（GAS）などのやり方で比べ、向き不向きと、どのやり方でも先に決めておくこと（向き・正しい値の持ち主・突合キー）を実務の目線でまとめます

iPaaS、ハブ&スポーク構成、Reverse ETLなどGTMシステム連携の設計原則

勝率が30%から40%に上がった。それは改善か、偶然か。測るもの・比べる相手・ばらつきの3つで、営業の数字を読む前に確かめること

勝率が上がったのは、難しい商談を避けたから。ウェビナー参加者の受注率が高いのは、買う気の高い人が来たから。営業の改善報告に潜む3つのわな

前後比較では、施策の効果はわからない。くじ引きで分ける実験、実験できないときの比べ方、指標を目標にしたときに起きるゲーム化、測定のコストを整理する

NRR・Rule of 40・ノーススターメトリックなど、部門横断でKPIを揃えるための共通言語

ARR純増を止めている要因を体系的に洗い出し、施策・トレードオフ・観測不能な領域まで管理する運用フレームワーク

管理会計そのものの解説ではなく、CRM/GTMデータが会計の数字とどう接続するかという実務の接続点に絞った整理

視聴者定義・指標の粒度・更新頻度など、意思決定に使われるダッシュボードを作るための設計原則

ファネル計測・マルチタッチアトリビューション・指標定義書の設計論点

MA実装・Speed to Lead・AEO/GEOなど、インバウンド獲得の技術基盤

採用シグナル・資金調達・Web訪問の匿名解除など購買意向シグナルの検知とルーティング設計

「AIに任せたら、それっぽいけど使えないものが返ってきた」。委任の単位、任せてよい仕事の見分け方、指示と文脈の渡し方を整理する

「完了しました」と報告されたのに、実際には直っていなかった。AIエージェントに渡す道具、承認の段階、評価の仕方、もっともらしい間違いへの備えを整理する

人の確認が形だけになる、同じ失敗を繰り返す、メール本文の指示に従ってしまう。AIエージェントを長く安全に回すための3つの論点

AIに受注率を聞くたびに違う数字が返ってくるのはなぜか。セマンティックレイヤー、オントロジー、AIに渡すデータと権限の設計を、営業データの視点で整理する

SFAにつないだAIに聞いた数字が、会議資料と違うのはなぜか。分母・日付・対象範囲・粒度・時点・項目の意味・正の所在・見える範囲の8つに分けて、AIに渡す説明書と答え合わせの作り方を整理する

プロンプトの体系化・AIワークフロー・評価ハーネス・HITLなど、AI GTMエンジニアリングの要点

仕組み全体の持ち主がいない。依頼が声の大きい順に処理される。分業の境目で熱量が落ちる。営業の仕組みを支える体制の、オーナー・役割分担・依頼の優先順位・組織構造を整理する

ルールを決めても守られない。入力されない。多くの原因は、目標・報酬・評価が決めた仕組みと逆を向いていること。営業の目標設計、報酬と評価の副作用、入力との連動を整理する

新人が立ち上がらない。外部に任せたら中身がわからない。人数が増えて体制が追いつかない。営業の仕組みを続けるための育成、内製と外部の分担、体制の進化を整理する

SFAを入れたのに半年後には誰も使っていない。導入と定着の違い、抵抗の正体、本人の得から話す目的の共有、小さく始める進め方を整理する

「上が使っていないなら、やらなくていい」。管理職から先に使う、現場の推進役を立てる、使わないと仕事が回らない形に組み込む、つまずいた瞬間に助ける

導入直後は使われていたのに、期末の忙しさと担当者の異動で元に戻った。定着を量と質で測り、揺り戻しを防ぎ、直す場を周期で回し続ける

「捨てる覚悟」としてのICP定義。ホリゾンタルSaaSスタートアップが陥りやすい罠の要約

GTM戦略の出発点となる市場理解のフレームワーク群を整理する

PLG・SLG・MLG・CLG・Partner-Ledの選び方と、営業生産性を測る指標群

事業仮説の言語化からGo-to-Market Fitまでの検証段階の考え方

TTV・ヘルススコア・タッチモデル・NPS・チャーン分析など既存顧客維持の基本フレーム

データ基盤・データモデリング・データアクティベーションの3層で収益システムを構築する考え方

CRMを入れたが専任担当がいない会社が、正社員採用と外部実務者活用のどちらを選ぶべきかの判断基準

SFA・指標の定義・スナップショット・正の所在・冪等性など、営業の仕組みづくりで使う用語を、8つの要素ごとにやさしく定義した用語集