Pricing / TCO method

This file is the home of the cost method — how you turn incomparable sticker prices into a comparable, risk-bearing TCO. It owns the reasoning: teardown → parameter-union questionnaire → 3-point bands → 4-bucket rollup, band-width-as-cost-risk, count-each-package-once, annotate-excluded-costs. The field shapes it produces (pricing, costModel, workPackages, the four buckets) live in contract.md; cite it, don’t restate it here.

Cost is a separate axis from Fit, and the pricing pass runs after the deep-dive scoring — you need to know what the survivors cost before you can recommend, but cost must never contaminate the Fit score (the doctrine is model.md § The four axes). Fold price into the weighted score and you hide the very cost-vs-value trade-off the buyer needs to see. The pass can run as its own short mini-loop, or fold into the deep-dive research (have the research agent return each tool’s pricing model + parameters alongside its scores — see the deep-dive brief in research-briefs.md).

Why this needs a method at all: real candidates price on incompatible models — per-seat, per-resolution, per-conversation, AI credits, tiered-with-caps, self-host. Sticker prices are not comparable. The method below makes them comparable and — just as important — surfaces cost risk (how far a tool’s bill can swing), which is often more decision-relevant than the midpoint.

The mini-loop: teardown → questionnaire → compute

Step 1 — Pricing-model teardown (per surviving tool)

For each survivor, document how it charges and decompose it into cost components, each tied to the parameter that drives it — one row per tool: the billing model, the cost formula (its components), the parameters that drive the cost, and the band width (how far it can swing).

Read the teardown for shape: flat/tiered tools have narrow bands (cost-safe, maybe a higher floor); usage-priced tools have wide bands (cheaper at low volume, exposed at peak). And annotate excluded costs — ops labour, a mandatory second product or KB, integration effort. A cash figure that quietly drops them lies, and the lie favours exactly the tool that looks cheapest.

Step 2 — Parameter union, split two ways

Collect every parameter across all the teardowns, then divide them:

(A) Org-usage parameters → the questionnaire. Shared across tools, so you ask them once and the answers feed every tool’s formula. Typical set: seats; email volume + active months; AI-draft events/mo; chatbot conversations/mo; deflection/resolution rate; languages; season peak multiplier + peak weeks; #bots/instances; AI-assist seats; annual-vs-monthly commitment.

(B) Billing-mapping assumptions → modelling choices you set (with justification). NOT user questions — they are your decisions, and they are the source of the optimistic↔pessimistic spread: what counts as one billable unit; multi-turn chat = 1 or many; annual-commit discount applied or not; included allotments before overage; one-time onboarding; how to treat unverified rates (assume high in the pessimistic case).

The teaching point: asking pricing questions per tool is chaos. Enumerating each tool’s parameters and taking the union yields one short questionnaire whose answers drive every formula — and keeps the tools comparable.

Step 3 — Elicit user inputs as RANGES, not points

For uncertain usage parameters, ask for low / expected / high. Uncertainty is a feature here: it is the optimistic/pessimistic spread. “Don’t know, somewhere between X and Y” is a perfectly good, useful answer. (Same disciplined interview style as Phase 2 — requirements-interview.md.)

Step 4 — Compute a 3-point parametric TCO per tool

Cost = f(params), evaluated at three scenarios using the same usage vector across all tools (this is what keeps them comparable):

• Optimistic — low volume + annual-commit discount + favourable billing mapping.
• Expected — realistic volume + normal mapping.
• Pessimistic — sustained-peak volume + overage rates + worst-case mapping + unverified rates assumed high.

Report year-1 (incl. one-time) and steady-state; for usage-priced tools flag the peak-period bill separately. Cap each tool at its 2–3 dominant drivers — don’t model every line item at three levels (combinatorial explosion); hold minor items fixed.

The bundled tool-level explorer ships a calculator scaffold that implements exactly this shape — scenario vectors + one formula per tool + a sortable band table (cockpit.md § The bundled explorer). Fill in one formula per surviving tool from the teardown and it computes the bands live. It’s a scaffold, not a fixed engine: every engagement’s per-tool formulas differ.

Step 5 — Band width IS a result; price is a SEPARATE axis

• The width of a tool’s optimistic→pessimistic band measures cost risk. Flat/tiered tools have narrow bands (predictable); usage-priced tools have wide bands — a tail that bites exactly when volume spikes (e.g. a seasonal peak). Surface this explicitly; it is often more decision-relevant than the midpoint.
• Never fold price into the weighted Fit score. Keep it a separate axis and present a cost-vs-value view (Fit score vs cost band) at synthesis. Mixing cost into the 0–N score hides the very trade-off the buyer needs to see. (Axis doctrine — model.md.)

Rolling up to a solution: the 4-bucket TCO

Everything above prices a tool. A solution-design engagement prices a solution (a composition), and the move that makes buy, compose, and build comparable is to split every solution’s cost into the same four buckets — then sum within each bucket across whatever the composition contains. The bucket shapes (and which costModel / workPackages fields feed each) are in contract.md § Solutions; the buckets themselves are:

• ① Project / build + integration — all one-time costs to stand the solution up: effort (set up, build the custom pieces, glue the tools together) and cash (hardware, perpetual licence, setup fees, any non-recurring outlay).
• ② Maintenance / year — ongoing labour to run it.
• ③ License / rent / year — recurring software fees, summed across every tool in the composition.
• ④ Usage / year — volume-driven costs (resolutions, conversations, AI tokens) across every tool.

Year-1 = ① + ② + ③ + ④; Ongoing/yr = ② + ③ + ④. The three solution kinds differ only in where the weight sits, not in the buckets:

• Rent (SaaS subscription): ③/④ dominate; ① is light (discovery + config) and mostly effort; ② is small.
• Buy (perpetual licence / hardware): ① carries the cash — hardware, perpetual licence, setup fees — but little ongoing effort; ③ shrinks (no rent) or vanishes; ② depends on how much you run.
• Compose: ③/④ across several tools, plus a real ① (integration effort + any setup cash) and a heavier ② (more surface to maintain) — the composition’s hidden tax.
• Build (Eigenbau): ① dominates and is mostly effort (the whole thing is your time), with some setup cash for parts; ③ shrinks to hosting, ④ is raw infra/token cost, ② is yours forever.

This is the point of the whole exercise: a SaaS sticker price (mostly ③) and a custom build (mostly ①) are not comparable as quoted, but their four-bucket totals under one Scenario are. Evaluate each bucket at the three points as before — the band still carries the cost risk, and ①’s optimistic↔pessimistic spread doubles as the Termin-Sicherheit signal for the build-heavy solutions. Count each work package once per solution; never sum a shared package across solutions — shared setup is identical across paths, so summing it double-charges the comparison (the unit doctrine is model.md § Composition). And keep cost a separate axis: never blend the four-bucket total into the Fit score.

Output

Write the teardown + 3-point result into each tool’s pricing object (and a solution’s costModel / workPackages) — schema in contract.md § The pricing field / § Solutions. The cockpit renders the band. Mark each figure verified once a human has confirmed the rate against the vendor’s pricing page.

Worked illustration (Die Skischule, 8 finalists, seasonal year-1 basis, USD≈EUR)

The full Skischule engagement end-to-end is examples.md; here is just the pricing pass, because it is the clearest demonstration of band-width-as-cost-risk. Teardown split the field into narrow-band / cost-safe (OMQ, moinAI, hosted Zammad — flat/tiered) vs wide-band / usage-exposed (Intercom, Zendesk, Freshdesk, Userlike — per-resolution/conversation). Questionnaire answers were deliberately uncertain (chatbot 1k–10k/yr, peak up to 10×, draft-trigger policy undecided), which produced the spreads:

Tool	Opt	Exp	Pess	Band
Zammad (excl. ops + chatbot bolt-on)	440	740	1,330	3.0×
Userlike / Lime	1,400	3,840	10,100	7.2×
Freshdesk / Freshchat	1,640	3,410	7,170	4.4×
Intercom / Fin	1,940	3,690	8,920	4.6×
Zendesk	3,730	6,920	16,300	4.4×
HubSpot	4,060	6,720	13,560	3.3×
moinAI (chatbot-only add-on)	5,140	5,450	13,500	2.6×
OMQ	20,000	21,500	24,000	1.2×

Three things the method surfaced that a single sticker price would have hidden:

1. Priciest can be safest. OMQ’s language/tier gate sets a high but flat floor (predictable); everyone else is cheaper but variable. Cheapest-looking ≠ cheapest.
2. The lowest number can mislead. Zammad’s figure excludes ops labour and a mandatory chatbot bolt-on (a second product + second KB). The model must annotate excluded costs or it lies.
3. Usage-priced tools carry the peak tail. A 10× peak pushes Zendesk’s worst case to ~4× its best — that volatility, not the midpoint, is the real cost story for a seasonal business. Band width = cost risk.