commercial-skills

コマーシャル — ドメインオーケストレーター

コマーシャル領域が扱うのは、案件ごとの経済性とパッケージングです。つまり、企業がどのように価格を設定し、パッケージ化し、承認し、収益を予測するかです。このオーケストレーターはコンテキストを分岐し、問い合わせを7つのサブスキルのいずれかに振り分けてから、要約を返します。大量のインプット（RFP PDF、パイプラインのエクスポート、パートナー契約書）は、分岐したコンテキスト内に保持されます。

呼び出すタイミング

症状	サブスキル
「価格が原因で案件を逃しています。値下げすべきですか、それともパッケージを見直すべきですか？」	pricing-strategist
「このエンタープライズ案件で40％の割引を承認できますか？」	deal-desk
「この再販業者と契約すべきですか？ティアは何ですか？」	partnerships-architect
「パートナーチャネルは実際に利益を上げていますか？」	channel-economics
「標準の割引マトリクスはどのようなものにすべきですか？」	commercial-policy
「この60ページのRFPへの回答を手伝ってください」	rfp-responder
「現在のコンバージョン率で、第4四半期の受注額はいくらになりそうですか？」	commercial-forecaster

ルーティングロジック（決定論的）

business-operations-skills と同じ2シグナルのしきい値パターンです。シグナルが1つの場合は、明確化の質問をします。シグナルが混在する場合は、信頼度が最も高いものを先に処理し、次のターンで2つ目を続けます。

シグナル表

シグナルクラス	キーワード	サブスキル
PRICING	pricing, price, packaging, tier, WTP, willingness to pay, Van Westendorp, value pricing	pricing-strategist
DEAL	deal, discount, approval, margin, T&Cs, redline, exception, MSA	deal-desk
PARTNERSHIP	partner, reseller, OEM, co-sell, joint GTM, revenue share, channel agreement	partnerships-architect
CHANNEL_ECON	channel mix, cost to serve, channel ROI, direct vs partner, channel economics	channel-economics
POLICY	commercial policy, discount matrix, T&C library, exception policy, deal framework	commercial-policy
RFP	RFP, RFI, RFQ, proposal request, vendor questionnaire, security questionnaire	rfp-responder
FORECAST	forecast, bookings, billings, ARR, NRR forecast, pipeline math, funnel projection	commercial-forecaster

ワークフロー（Matt Pocockのグリル規律）

Matt Pocockのgrill-with-docsパターンに基づきます。調査してから質問し、推奨回答を添えて1ターンにつき質問は1つにする。意思決定ツリーを深さ優先でたどり、依存関係を追跡し、SaaSの価格設定／案件審査の原則（references/）に基づいてすべての確認を行います。

ステップ1 — 質問する前に調査する

まず、ユーザーの作業ディレクトリを確認します。

• 案件レコード、価格比較表、RFP文書、パイプラインのエクスポートがすでにワークスペースにありますか？
• 問い合わせから、処理する領域をすでに特定できますか（例：「この60ページのRFPを確認して」ならrfp-responderであり、質問は不要です）？
• 処理する領域を特定できるファイル名がありますか（pipeline-Q4.csv → 予測、MSA-redline.docx → 案件）？

ワークスペース内の情報から処理する領域が特定できたら、何も尋ねずにルーティングします。

ステップ2 — まだ曖昧な場合は、推奨回答を添えて、判断を促す質問を1つだけする

Mattのルール：質問をまとめてはいけません。必ず推奨案を示します。

パターン：

Q1/1: [precise question naming the two candidate lanes]
Recommended: [Lane X, because <signal-table rationale>]

(Confirm, or override?)

ステップ3 — 複数領域にまたがる問い合わせでは、意思決定ツリーをたどる

問い合わせが正当に2つの領域にまたがる場合（例：「このRFPでは、通常は提示しない割引を求められています」＝RFP＋DEAL＋場合によってはPOLICY）、深さ優先で進めます。

1. 信頼度が最も高い領域を先に処理 → 分岐したコンテキストでサブスキルを実行 → 要約
2. 「続けて［2つ目の領域］も実行しますか？依存関係を考慮すると、実行を推奨します。理由：[依存関係]」
3. 続ける前に確認を取ります。

黙って連鎖実行してはいけません。

ステップ4 — 分岐したコンテキストでサブスキルを呼び出す

元のプロンプトと構造化された入力（パイプラインCSV、RFP文書のパス、価格比較表、MSAの修正履歴）を渡します。

ステップ 5 — 根拠となる引用付きの検討課題とともに要約を返す

200 語以内：分析内容、根拠となる引用に基づく主な発見 3 件、次のアクション 3 件（該当する場合は承認者を明記）、成果物のパス、そしてユーザーへの検討課題を 1 つ含めます。例：

• 「案件スコアカードでは、割引後の粗利益率が 38% です。Skok の For Entrepreneurs ベンチマークによると、割引前の粗利益率が 70% 未満の SaaS 案件は精査が必要です。フルフィルメントコストを試算しましたか。それとも売上原価だけですか？」
• 「パッケージには Better に 14 個、Best に 16 個の機能があります。Madhavan Ramanujam（Monetizing Innovation）によると、明確な差別化要素のない階層では、顧客の 70% が最安プランを選びます。アップグレードを決定づける機能は何ですか？」

強制質問ライブラリ（ドキュメントを用いた検討パターン）

サブスキルを呼び出す前に、レーンを定義する意思決定についてユーザーに確認します。1 回につき 1 問とし、推奨される回答と根拠となる引用を示します。

• PRICING レーン：「モデルを選ぶ前に確認します。顧客は成果、席数、それとも利用量に対して支払いますか？ 推奨：測定できるなら、成果（価値ベース）です。アンチパターン（Ramanujam、2016 年、Monetizing Innovation）：利用量が変動する製品に席数ベースの価格設定を適用すると、WTP の 20% に TAM が制限されます。」
• DEAL レーン：「承認する前に確認します。最大割引時の粗利益率はいくらですか。また、同じ条件で来四半期のパイプラインはどうなりますか？ 推奨：両方を試算します。アンチパターン（Tunguz のベンチマーク）：40% の前例が 1 件あるだけで、3 四半期分のパイプラインに影響します。」
• FORECAST レーン：「予測を立てる前に確認します。過去 4 四半期のステージ転換率を使っていますか。それとも過去 12 四半期ですか？ 推奨：直近 4 四半期の重みを高くします。アンチパターン（Skok、OpenView）：12 か月を均等に重み付けすると、直近の減速が見えなくなります。」
• PARTNERSHIP レーン：「契約する前に確認します。パートナーは独自の需要を持っていますか。それとも、当社のパイプラインを再販しているだけですか？ 推奨：独自の需要を示す証拠を必須にします。アンチパターン（Forrester のチャネル調査）：自社パイプラインからのチャネル経由案件は、直販よりもコストがかかります。」

レーンを定義する意思決定が確定するまで、サブスキルを実行しないでください。

前提条件

1. ユーザーは商業上の決裁権を持っているか、決裁権を持つ人向けの分析を準備しています。
2. ユーザーが求めているのは決定論的な意思決定支援であり、最終回答ではありません。案件の承認、価格設定、パートナーとの契約は人間が行います。
3. 入力が不完全な場合があります。各サブスキルには、ユーザーが自分の情報を入力する前に完成形を確認できるよう、テンプレート化されたダミーデータが含まれています。

対象外

• CRM、CPQ システム、または契約リポジトリではありません。
• 案件を自動承認しません。すべての出力はスコア＋推奨＋人間の承認者への振り分けです。
• セッションをまたいで案件履歴を保存しません。

次のものとは異なります

• business-growth/sales-engineer — こちらは技術営業（デモ、POC）です。Commercial が扱うのは案件の経済的な構造です。
• business-growth/revenue-operations — こちらはプロセス（リードの振り分け、SDR の営業活動）です。Commercial が扱うのは案件ごとの経済性＋ポリシーです。
• business-growth/contract-and-proposal-writer — こちらは文章の作成です。Commercial が扱うのは意思決定ロジック＋構造化された回答です。
• c-level-advisor/cro-advisor — こちらは戦略的な CRO の判断（「いつ VP Sales を採用するか？」）です。Commercial が扱うのは戦術的な判断（「この割引を承認するか？」）です。
• finance/financial-analysis — こちらは決算＋レポートです。Commercial が扱うのは予測＋案件ごとの経済性です。

出力成果物

サブスキル	成果物
pricing-strategist	pricing_model.md + wtp_analysis.json
deal-desk	deal_scorecard.md + discount_approval_routing.json
partnerships-architect	partner_tier_assignment.md + revshare_model.json
channel-economics	channel_mix_analysis.md + cost_to_serve.json
commercial-policy	commercial_policy.md（割引マトリクス＋例外フロー）
rfp-responder	rfp_response.md + winrate_estimate.json
commercial-forecaster	forecast.md + pipeline_math.json

アンチパターン（避けてください）

• ❌ 特定の価格を推奨する — 価格帯＋モデルを推奨し、金額はユーザーが選びます
• ❌ ポリシーを超える割引を自動承認する — X%を超える割引はすべて、指名された人間の承認者に回します
• ❌ ユーザーが検証できる証拠がないまま、RFPへの回答を生成する
• ❌ コンバージョンの前提を明示せずに、受注額を予測する
• ❌ 念のために7つのサブスキルをすべて実行する — 1つ選んで内容を把握し、必要に応じて連携させます

参考資料

• SaaS価格設定の定番資料：Tomasz Tunguz、David Skok、Bessemer Venture Partners
• ディールデスク：SaaStrのプレイブック、Winning by Design
• Path-Bの構築パターン：documentation/implementation/bizops-commercial-expansion-plan.md