commercial-skills

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commercial — Domain Orchestrator

商业领域编排器

The Commercial surface is per-deal economics and packaging: how the company prices, packages, approves, and forecasts revenue. This orchestrator forks its context, routes your inquiry to one of seven sub-skills, then returns a digest. Heavy intake (RFP PDFs, pipeline exports, partner agreements) stays in the forked context.

商业领域聚焦单交易经济结构与包装策略：即企业如何定价、包装产品、审批交易以及预测收入。该编排器会拆分上下文，将你的咨询请求路由至七个子技能之一，然后返回摘要。大量输入内容（如RFP PDF文件、销售管道导出数据、合作伙伴协议）会保留在分支上下文中。

When to invoke

调用场景

Symptom	Sub-skill
"We're losing deals on price — should we drop prices or repackage?"	`pricing-strategist`
"Can we approve a 40% discount on this Enterprise deal?"	`deal-desk`
"Should we sign with this reseller? What's their tier?"	`partnerships-architect`
"Is our partner channel actually profitable?"	`channel-economics`
"What should our standard discount matrix look like?"	`commercial-policy`
"Help me respond to this 60-page RFP"	`rfp-responder`
"What's our Q4 bookings forecast at current conversion?"	`commercial-forecaster`

场景描述	子技能
“我们因价格问题丢失交易——应该降价还是重新包装产品？”	`pricing-strategist`
“我们能否批准这笔企业级交易的40%折扣？”	`deal-desk`
“我们是否应该与这家经销商签约？他们属于哪个层级？”	`partnerships-architect`
“我们的合作伙伴渠道是否真的盈利？”	`channel-economics`
“我们的标准折扣矩阵应该是什么样的？”	`commercial-policy`
“帮我回复这份60页的RFP”	`rfp-responder`
“按照当前转化率，我们第四季度的预订预测是多少？”	`commercial-forecaster`

Routing logic (deterministic)

路由逻辑（确定性）

Same two-signal threshold pattern as

business-operations-skills

. Single-signal → clarifying question. Mixed signals → highest-confidence first, chain second in follow-up turn.

采用与

business-operations-skills

相同的双信号阈值模式。单信号→提出澄清问题。混合信号→优先选择置信度最高的技能，后续回合再调用第二个技能。

Signal table

信号对照表

Signal class	Keywords	Sub-skill
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`

信号类别	关键词	子技能
定价	pricing, price, packaging, tier, WTP, willingness to pay, Van Westendorp, value pricing	`pricing-strategist`
交易	deal, discount, approval, margin, T&Cs, redline, exception, MSA	`deal-desk`
合作伙伴	partner, reseller, OEM, co-sell, joint GTM, revenue share, channel agreement	`partnerships-architect`
渠道经济	channel mix, cost to serve, channel ROI, direct vs partner, channel economics	`channel-economics`
政策	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, bookings, billings, ARR, NRR forecast, pipeline math, funnel projection	`commercial-forecaster`

Workflow (Matt Pocock grill discipline)

工作流程（Matt Pocock grill规范）

Derived from Matt Pocock's

grill-with-docs

pattern: explore-then-ask, one question per turn with a recommended answer, walk the decision tree depth-first, track dependencies, anchor every challenge in the SaaS pricing / deal desk canon (

references/

基于Matt Pocock的

grill-with-docs

模式：先探索再提问，每回合只提一个问题并给出推荐答案，深度遍历决策树，跟踪依赖关系，每个挑战都锚定SaaS定价/交易审核标准规范（

references/

）。

Step 1 — Explore before asking

步骤1 — 提问前先探索

Check the user's working directory first:

Is there a deal record, pricing comp table, RFP doc, or pipeline export already in the workspace?
Does the inquiry already disambiguate the lane (e.g., "review this 60-page RFP" — that's
```
rfp-responder
```
, no question needed)?
Is there an artifact filename that resolves the lane (
```
pipeline-Q4.csv
```
→ forecast;
```
MSA-redline.docx
```
→ deal)?

If the workspace resolves the lane, route silently.

首先检查用户的工作目录：

工作区中是否已有交易记录、定价对比表、RFP文档或销售管道导出数据？
用户的咨询是否已明确技能方向（例如“审核这份60页的RFP”——直接对应
```
rfp-responder
```
，无需提问）？
是否有文件名可以明确技能方向（
```
pipeline-Q4.csv
```
→预测；
```
MSA-redline.docx
```
→交易）？

如果工作区能明确技能方向，则自动静默路由。

Step 2 — If still ambiguous, ONE forcing question with a recommended answer

步骤2 — 若仍存在歧义，仅提一个明确问题并给出推荐答案

Matt's rule: never bundle. Always recommend.

Pattern:

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

(Confirm, or override?)

遵循Matt的规则：绝不捆绑问题，始终给出推荐选项。

示例格式：

问题1/1：[明确指出两个候选技能方向的精准问题]
推荐选项：[技能X，因为<信号对照表中的依据>]

（请确认，或选择其他技能？）

Step 3 — Decision-tree walk for multi-lane inquiries

步骤3 — 多技能场景的决策树遍历

If the inquiry legitimately crosses two lanes (e.g., "this RFP wants a discount we don't normally give" = RFP + DEAL + maybe POLICY), walk depth-first:

Highest-confidence lane first → run sub-skill in forked context → digest
Ask: "Now run [second lane]? Recommended: yes, because [dependency]."
Confirm before chaining.

Never silently chain.

若用户的咨询确实涉及多个技能方向（例如“这份RFP要求我们提供常规不允许的折扣”=RFP+交易+可能涉及政策），则按深度优先顺序处理：

优先调用置信度最高的技能→在分支上下文中运行子技能→生成摘要
询问：“是否现在调用[第二个技能]？推荐：是，因为[依赖关系说明]。”
获得确认后再链式调用。

禁止静默链式调用。

Step 4 — Invoke sub-skill in forked context

步骤4 — 在分支上下文中调用子技能

Forward original prompt + structured inputs (pipeline CSV, RFP doc path, pricing comp table, MSA redline).

转发原始提示语+结构化输入内容（销售管道CSV文件、RFP文档路径、定价对比表、MSA修订版）。

Step 5 — Return digest with cited canon challenge

步骤5 — 返回带有规范引用挑战的摘要

≤ 200 words: analyzed, top 3 findings (anchored to canon citation), top 3 next actions (named approver where applicable), artifact path, and one grill challenge for the user. Examples:

"Your deal scorecard shows 38% margin after discount. Skok's For Entrepreneurs benchmark says SaaS deals < 70% gross margin pre-discount need scrutiny. Did you model fulfillment cost or just COGS?"
"Your packaging has 14 features in Better and 16 in Best. Madhavan Ramanujam (Monetizing Innovation): tiers with no clear differentiator make 70% of customers pick the cheapest. What's the one feature that forces an upgrade?"

摘要字数≤200字：包含分析结果、3项核心发现（锚定规范引用）、3项后续行动（注明相关审批人）、文件路径，以及一个向用户提出的针对性挑战。示例：

“你的交易计分卡显示折扣后毛利率为38%。Skok的For Entrepreneurs基准指出，SaaS交易折扣前毛利率低于70%需要仔细审查。你是否已将履约成本纳入模型，还是仅考虑了COGS？”
“你的产品包装中，Better版本包含14个功能，Best版本包含16个功能。Madhavan Ramanujam（《Monetizing Innovation》）指出：无明确差异化的层级会导致70%的客户选择最便宜的版本。哪个功能是促使客户升级的核心驱动力？”

Forcing-question library (grill-with-docs pattern)

强制问题库（grill-with-docs模式）

Grill the user on lane-defining decisions before invoking the sub-skill. One per turn, recommended answer, canon citation:

PRICING lane: "Before picking a model: is your customer paying for outcomes, seats, or usage? Recommended: outcomes (value-based) if you can measure them. Anti-pattern (Ramanujam 2016 Monetizing Innovation): seat-based pricing on a usage-variable product caps your TAM at 20% of WTP."
DEAL lane: "Before approving: what's the gross margin at full discount, and what does next quarter's pipeline look like at the same terms? Recommended: model both. Anti-pattern (Tunguz benchmarks): one 40% precedent reshapes 3 quarters of pipeline."
FORECAST lane: "Before forecasting: are you using stage-conversion rates from the last 4 quarters, or the last 12? Recommended: last 4 weighted heavier. Anti-pattern (Skok, OpenView): equal-weighting 12 months hides the recent slowdown."
PARTNERSHIP lane: "Before signing: does the partner have independent demand, or are they reselling our pipeline? Recommended: insist on indep demand evidence. Anti-pattern (Forrester channel research): channel-led deals from your own pipeline cost more than direct."

Never run a sub-skill until the lane-defining decision is locked.

在调用子技能前，针对技能方向的决策向用户提出问题。每回合一个问题，附带推荐答案和规范引用：

定价方向：“在选择模型前：你的客户是按成果、席位还是使用量付费？推荐选项：若可衡量则按成果（基于价值）付费。反模式（Ramanujam 2016年《Monetizing Innovation》）：针对使用量可变的产品采用席位定价，会将你的TAM限制在WTP的20%以内。”
交易方向：“在批准前：全额折扣后的毛利率是多少，以及按相同条款计算的下一季度销售管道情况如何？推荐选项：同时建模两者。反模式（Tunguz基准）：一次40%折扣的先例会影响未来3个季度的销售管道。”
预测方向：“在预测前：你使用的是过去4个季度还是过去12个月的阶段转化率？推荐选项：优先采用过去4个季度的加权数据。反模式（Skok, OpenView）：对12个月的数据同等加权会掩盖近期的增长放缓。”
合作伙伴方向：“在签约前：该合作伙伴是否拥有独立需求，还是仅转售我们的销售管道？推荐选项：坚持要求提供独立需求的证据。反模式（Forrester渠道研究）：来自自有销售管道的渠道主导交易成本高于直接交易。”

在技能方向的决策确定前，禁止调用子技能。

Assumptions

假设前提

User has commercial authority OR is preparing analysis for someone who does.
User wants deterministic decision support, not the final answer — the human approves the deal, sets the price, signs the partner.
Inputs may be partial — every sub-skill ships templated dummy data so the user can see the shape before filling in their own.

用户拥有商业决策权限，或正在为拥有该权限的人准备分析内容。
用户需要确定性决策支持，而非最终答案——交易批准、定价设置、合作伙伴签约均由人工完成。
输入内容可能不完整——每个子技能都提供模板化虚拟数据，方便用户在填写自有数据前了解输出格式。

Non-goals

非目标

Not a CRM, CPQ system, or contract repository.
Does not auto-approve deals. Every output is a score + recommendation + human-approver routing.
Does not store deal history across sessions.

不充当CRM、CPQ系统或合同存储库。
不自动批准交易。所有输出内容均为评分+建议+人工审批路由指引。
不跨会话存储交易历史。

Distinct from

与其他技能的区别

business-growth/sales-engineer
— that's the technical sale (demos, POCs). Commercial is economic shape of the deal.
business-growth/revenue-operations
— that's process (lead routing, SDR motion). Commercial is per-deal economics + policy.
business-growth/contract-and-proposal-writer
— that's authoring prose. Commercial is decision logic + structured response.
c-level-advisor/cro-advisor
— that's strategic CRO judgment ("when do we hire VP Sales?"). Commercial is tactical ("approve this discount").
finance/financial-analysis
— that's close + report. Commercial is forecast + per-deal economics.

business-growth/sales-engineer
——聚焦技术销售（演示、POC）。商业领域技能聚焦交易的经济结构。
business-growth/revenue-operations
——聚焦流程（线索路由、SDR流程）。商业领域技能聚焦单交易经济+政策。
business-growth/contract-and-proposal-writer
——聚焦文案撰写。商业领域技能聚焦决策逻辑+结构化响应。
c-level-advisor/cro-advisor
——聚焦战略CRO判断（“何时招聘销售副总裁？”）。商业领域技能聚焦战术层面（“批准这笔折扣”）。
finance/financial-analysis
——聚焦结账+报告。商业领域技能聚焦预测+单交易经济。

Output artifacts

输出产物

Sub-skill	Artifact
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` (discount matrix + exception flow)
rfp-responder	`rfp_response.md` + `winrate_estimate.json`
commercial-forecaster	`forecast.md` + `pipeline_math.json`

子技能	产物
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`

Anti-patterns (do not)

反模式（禁止行为）

❌ Recommend a specific price — recommend a range + model, user picks the number
❌ Auto-approve discounts above policy — every >X% discount routes to a named human approver
❌ Generate an RFP response without proof points the user can verify
❌ Forecast bookings without surfacing the conversion assumption explicitly
❌ Run all 7 sub-skills "to be thorough" — pick one, digest, chain if needed

❌ 推荐具体价格——应推荐价格区间+模型，由用户确定最终价格
❌ 自动批准超出政策范围的折扣——所有超出X%的折扣需路由至指定人工审批人
❌ 在无用户可验证的证明点的情况下生成RFP响应
❌ 在未明确转化率假设的情况下预测预订量
❌ 为“全面起见”运行所有7个子技能——选择一个技能生成摘要，必要时再链式调用

References

参考资料

SaaS pricing canon: Tomasz Tunguz, David Skok, Bessemer Venture Partners
Deal desk: SaaStr playbooks, Winning by Design

Path-B build pattern:

documentation/implementation/bizops-commercial-expansion-plan.md

SaaS定价规范：Tomasz Tunguz、David Skok、Bessemer Venture Partners
交易审核：SaaStr playbooks、Winning by Design

Path-B构建模式：

documentation/implementation/bizops-commercial-expansion-plan.md