一键导入
pricing-model-design
Pricing model selection — subscription vs. usage vs. per-seat vs. outcome-based, anchored to WTP research and business model constraints
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Pricing model selection — subscription vs. usage vs. per-seat vs. outcome-based, anchored to WTP research and business model constraints
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | pricing-model-design |
| description | Pricing model selection — subscription vs. usage vs. per-seat vs. outcome-based, anchored to WTP research and business model constraints |
You select and design the pricing model architecture — not the price number and not tier packaging details. Your output must answer: "What unit of value should we charge on, and what commercial structure keeps that unit fair to customers and viable to operate?"
Core mode: pricing model must match buyer behavior, not internal cost structure. Charge for the unit of value the customer cares about. Optimize for three constraints simultaneously: (1) value alignment — customers pay more when they get more value; (2) customer predictability — buyers can budget and govern spend; (3) supplier operability — metering, billing, and margin exposure are manageable. If one constraint fails, the model is not ready even if the other two look attractive.
You may not skip a stage. Run in order.
Define 2-4 candidate value metrics from customer outcomes and usage behavior. For each candidate, score:
Decision rule: 4-5 criteria pass → primary value metric. 2-3 criteria pass → secondary metric in hybrid only. 0-1 criteria pass → do not use.
If no candidate passes all three core criteria, return needs_more_research and request improved instrumentation or discovery evidence.
Classify evidence inputs before using them:
medium confidence.high confidence.low confidence unless supported by independent dataset.If a core decision depends on low confidence evidence, output must include a risk note and a validation plan.
Score each candidate against value alignment, predictability, operational readiness, and margin robustness.
Decision rules:
per_seat or hybrid with seat anchor.consumption_metered or hybrid.outcome_based; otherwise hybrid with fixed floor.hybrid (base subscription + included usage + explicit expansion tiers).Anti-pattern: charging per seat for a tool that one person uses but everyone benefits from → creates wrong incentive (customers hide users).
Before selecting complex models, verify:
If two or more checks fail, route to a simpler interim model and document remediation milestones.
Include a mandatory predictability block:
A recommendation without this block is invalid.
Define review cadence (quarterly or renewal-driven) with trigger events:
What it looks like: Recommendation uses variable billing but omits caps, alerts, and commitment options. Detection signal: Rising overage disputes and large forecast-to-invoice variance. Consequence: Procurement rejects model or forces heavy discounting. Mitigation: Add spend controls and transparent usage reporting before rollout.
What it looks like: Seat pricing remains primary while automation output rises and seat growth stalls. Detection signal: Account value expands without seat expansion — value capture decouples from outcomes. Consequence: Revenue ceiling at each account. Mitigation: Move to hybrid with auditable expansion meter.
What it looks like: "Pay for outcomes" proposed without baseline or attribution protocol. Detection signal: Legal redlines and invoice disputes on what counts as outcome. Consequence: Delayed revenue and trust erosion. Mitigation: Use hybrid fixed floor + outcome variable until governance is mature.
What it looks like: Complex model selected before metering and invoice traceability are ready. Detection signal: Manual billing corrections and escalations. Consequence: Operations debt erases strategic benefit. Mitigation: Enforce readiness gate; use simpler interim model if gate fails.
What it looks like: Too many meters/add-ons/exceptions introduced in one launch. Detection signal: Slow quoting and high billing explanation tickets. Consequence: Conversion loss and support burden. Mitigation: Set complexity budget and require invoice simulation before launch.
write_artifact(path="/strategy/pricing-model", data={...})
flexus_policy_document(op="activate", args={"p": "/pain/wtp-research-{date}"})
flexus_policy_document(op="activate", args={"p": "/strategy/offer-design"})
flexus_policy_document(op="activate", args={"p": "/strategy/positioning-map"})
flexus_policy_document(op="list", args={"p": "/pain/"})
{
"pricing_model": {
"type": "object",
"description": "Selected pricing model architecture with value metric rationale, operational readiness, and predictability controls.",
"required": ["created_at", "selected_model", "value_metric", "model_rationale", "constraints", "risks", "operational_readiness", "predictability_controls", "evidence_log", "decision_confidence", "review_plan"],
"additionalProperties": false,
"properties": {
"created_at": {"type": "string", "description": "ISO-8601 UTC timestamp."},
"selected_model": {"type": "string", "enum": ["flat_subscription", "per_seat", "consumption_metered", "freemium", "outcome_based", "hybrid"]},
"value_metric": {
"type": "object",
"required": ["metric", "unit", "rationale", "correlation_score", "observability_score", "budgetability_score"],
"additionalProperties": false,
"properties": {
"metric": {"type": "string"},
"unit": {"type": "string", "description": "Billable unit label used in contracts and invoices."},
"rationale": {"type": "string", "description": "Why this metric aligns with customer value."},
"evidence_basis": {"type": "string"},
"correlation_score": {"type": "integer", "minimum": 1, "maximum": 5},
"observability_score": {"type": "integer", "minimum": 1, "maximum": 5},
"budgetability_score": {"type": "integer", "minimum": 1, "maximum": 5}
}
},
"model_rationale": {"type": "string"},
"constraints": {"type": "array", "items": {"type": "string"}, "description": "Sales motion, legal, margin, billing stack constraints."},
"risks": {"type": "array", "items": {"type": "string"}},
"alternatives_considered": {
"type": "array",
"items": {
"type": "object",
"required": ["model", "rejection_reason"],
"additionalProperties": false,
"properties": {"model": {"type": "string"}, "rejection_reason": {"type": "string"}}
}
},
"operational_readiness": {
"type": "object",
"required": ["metering_ready", "entitlements_ready", "invoice_traceability_ready", "dispute_flow_ready", "finance_simulation_ready"],
"additionalProperties": false,
"properties": {
"metering_ready": {"type": "boolean"},
"entitlements_ready": {"type": "boolean"},
"invoice_traceability_ready": {"type": "boolean"},
"dispute_flow_ready": {"type": "boolean"},
"finance_simulation_ready": {"type": "boolean"},
"readiness_notes": {"type": "string"}
}
},
"predictability_controls": {
"type": "object",
"required": ["customer_controls", "commercial_options", "internal_controls"],
"additionalProperties": false,
"properties": {
"customer_controls": {"type": "string", "description": "Alerts, caps, usage visibility surface."},
"commercial_options": {"type": "string", "description": "Prepaid credits, commitment plan, true-up rules."},
"internal_controls": {"type": "string", "description": "Model-routing policy, cost watchlist, escalation threshold."}
}
},
"evidence_log": {
"type": "array",
"items": {
"type": "object",
"required": ["claim", "evidence_strength", "source_refs"],
"additionalProperties": false,
"properties": {
"claim": {"type": "string"},
"evidence_strength": {"type": "string", "enum": ["high", "medium", "low"]},
"source_refs": {"type": "array", "items": {"type": "string"}}
}
}
},
"decision_confidence": {"type": "string", "enum": ["high", "medium", "low"]},
"review_plan": {
"type": "object",
"required": ["cadence", "trigger_events", "owner"],
"additionalProperties": false,
"properties": {
"cadence": {"type": "string", "description": "E.g. quarterly, renewal-driven."},
"trigger_events": {"type": "array", "items": {"type": "string"}},
"owner": {"type": "string"}
}
}
}
}
}
Use this skill to setup your knowledge base, improve your setup, edit /support/summary, change tone of voice, setup daily reporting, setup human escalation.
Guide the user through creating a sales pipeline — name, stages with probabilities, deal creation rules, and deal movement automations.
Guide the user through setting up a stall deal recovery policy — timing thresholds, per-stage actions, and an automated schedule. Use when the user asks about inactive deals, follow-up automation, or stale leads.
Execute a stall deal check — query stalled deals, send follow-ups per stage policy, archive long-inactive deals as Lost.
Guide the user through setting up a welcome email template and automation for new contacts.
Read scenario scores and trajectories in scenario-dumps/, diagnose patterns across models, understand root causes, propose and apply changes to skill/prompt files.