Projects a customer's cost from prior usage data across seat-based, usage-based, and hybrid SaaS pricing models. Use when asked to "project cost", "estimate BYO cost", "estimate spend", "how much will this cost", "size a deal", or to build an enterprise-style usage/cost projection.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Projects a customer's cost from prior usage data across seat-based, usage-based, and hybrid SaaS pricing models. Use when asked to "project cost", "estimate BYO cost", "estimate spend", "how much will this cost", "size a deal", or to build an enterprise-style usage/cost projection.
Answer Pricing Skill
Setup required: Before using this skill, update knowledge/platform_credits.md with your product's pricing model (seat-based, usage-based, or hybrid), your rate constants, and any tier-specific details. The scripts ship with no hardcoded values — you supply them via environment variables or CLI flags.
Use this skill to project a prospect or customer's cost from their prior usage data. It standardizes the projection math across seat-based, usage-based, and hybrid pricing models.
Always read knowledge/platform_credits.md first — it holds the pricing
model taxonomy, rate configuration, conversion options, and projection
formulas. Cite it in your answer.
Prerequisites
METABASE_API_KEY in the environment — only needed for Step 0 (pulling a
customer's usage from a data warehouse). If you already have usage numbers, skip it.
Rate config — set the relevant env vars from knowledge/platform_credits.md
for your pricing model (e.g. SEAT_PRICE, USAGE_UNIT_PRICE,
INCLUDED_UNITS_PER_SEAT). No rates ship in the repo.
Python 3 (the scripts are stdlib-only; no pip install needed).
Inputs
The user typically provides:
Pricing model — seat-based, usage-based, or hybrid. Confirm from
the pricing sheet or contract if not stated. (Required.)
Current usage or spend and the it covers (e.g. "10,000 API
calls over 7 days", "$3,000 inference spend last month"). If given a
team/account ID instead, pull it with Step 0.
window
(Required.)
Rate constants — set via env vars (see knowledge/platform_credits.md).
No defaults ship in the repo. (Required.)
Conversion assumption — if you need to convert from one metric to the
billable unit (e.g. inference spend → compute hours), state the ratio and
its source explicitly. (Required if applicable.)
Whether they self-host / BYOC — if so, billed compute = $0; optionally
quantify the avoided infrastructure cost.
If an optional input is missing, use the documented approach and state the
assumption. Rate inputs have no built-in defaults — set them via env vars
or CLI flags before running.
Workflow
Step 0 (optional): Pull usage by account/team ID
If you only have a customer name or account ID, fetch their usage from the
data warehouse first. This gives you observed usage numbers — the best anchor
for any conversion assumption.
Always scope by account/team ID, not email domain — domain filters miss
service accounts and bots that still consume usage.
Requires METABASE_API_KEY.
Step 1: Confirm the pricing model and gather rate constants
Read knowledge/platform_credits.md to identify the applicable model
(seat-based, usage-based, or hybrid). Set the relevant env vars for the
customer's tier — no rates are committed to the repo. If the user references
older figures, confirm which rate was in effect so the numbers reconcile.
Step 2: Identify and state any conversion assumptions
If you need to convert from an observed metric to the billable unit (e.g.
inference tokens → compute hours, API calls → seats), this is the biggest
uncertainty lever (±30–50% typical error). Prefer the customer's own observed
ratio from Step 0. Otherwise choose and state an assumption explicitly —
pass it via CLI flag or env var. Note the direction of the lever.
Step 3: Run the projector
Don't do the math by hand. Set rate env vars first (or pass flags); the script
ships with no hardcoded values:
It prints a one-line headline and a compact monthly/annual grid across the
configured scenarios. Set PRICE_GRID / USAGE_GRID to compare several
price/volume points. Use --json for full multi-horizon detail, or
--self-test to confirm model arithmetic after any edit.
Step 4: Write the answer
Use the output format below. Lead with the pricing model used, the key numbers,
and any savings vs. an alternative (e.g. current spend vs. projected, or
self-hosted vs. managed). State the conversion assumption in one line.
Keep it short — don't dump every horizon or sanity-check row.
Output Format
Keep the reply short and scannable: one headline (pricing model + key inputs),
the projection result, a savings/comparison line if applicable, and one basis
line. Default to the monthly horizon (annual in parens). Offer other horizons
or price points only if asked.
---BEGIN FORMAT---
[Customer] — Cost Projection ([Pricing Model])
[Usage] / [W] days → monthly run-rate: $[mo]/mo ($[yr]/yr)[ Self-hosted, so compute = $0.]
Scenario comparison:
[Scenario A, e.g. "10 seats @ $X/seat"] → ~$[mo]/mo
[Scenario B, e.g. "20 seats @ $X/seat"] → ~$[mo]/mo
[Alternative, e.g. "usage-based @ $Y/unit"] → ~$[mo]/mo
→ [Scenario A] is ~[S]% [cheaper/more expensive] than [alternative].
Basis: [conversion ratio and source]; directional (±~30–50% without full history).
---END FORMAT---
Guidelines
Keep the reply presentable. Short headline, neutral scenario options, one
comparison line, one basis line. Don't dump every horizon or sanity-check row.
Show scenarios plainly. When comparing multiple price points or models,
present them neutrally without labeling any as preferred.
Never quote a single point estimate for usage-derived costs — show a
range or multiple scenarios so uncertainty is visible.
Use account/team ID, not email domain, when sourcing usage data (service
accounts hide behind non-customer domains).
Be evidence-driven. Base rates on knowledge/platform_credits.md; keep
facts (configured rates) vs. assumptions (conversion ratios) clearly separated.
After Completing
For a one-off answer, reply inline. For a deliverable, save a markdown brief to
reports/pricing/pricing_<customer>_<YYYY-MM-DD>.md and create a PR. For a
formatted deck/xlsx, the skill produces the numbers and brief —
deck formatting is out of scope.
