jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/roi-calculator-builder/references/ai-benefit-categories.md

@@ -0,0 +1,101 @@
+# AI Benefit Categories
+
+Use this reference when quantifying benefits. Each category includes how to baseline, how to model uplift, and the trap to avoid.
+
+Every benefit line should follow:
+
+`benefit = users × frequency × baseline metric × uplift × realization × (currency conversion)`
+
+## 1. Labor productivity (time saved)
+
+**What it is**: Reduction in time per task for a defined user population.
+
+**Baseline**: Tasks per user per period, current minutes per task. Source from logs, time-and-motion studies, or SME interviews.
+
+**Uplift**: Minutes saved per task. State as low / base / high.
+
+**Conversion**: Minutes × loaded hourly rate. State whether the rate is fully-loaded or salary-only.
+
+**Trap**: Hours saved are not cash unless the client actually reduces or backfills headcount. Default to "capacity reallocated to higher-value work" framing and flag the cash-vs-capacity distinction explicitly. If the client commits to a specific headcount or contractor reduction, model that as a separate, named line.
+
+## 2. Throughput / cycle-time reduction
+
+**What it is**: More units of work processed in the same window, or the same units processed faster.
+
+**Baseline**: Current throughput per period and current cycle time.
+
+**Uplift**: Percent throughput increase or hours of cycle-time reduction.
+
+**Conversion**: For revenue-bearing work, throughput × revenue per unit. For SLA-bound work, cycle-time reduction × penalty avoided or customer-experience proxy.
+
+**Trap**: Higher throughput only realizes value if there is demand to absorb it or a downstream constraint that lifts.
+
+## 3. Quality / error reduction
+
+**What it is**: Fewer defects, rework loops, escalations, or compliance misses.
+
+**Baseline**: Current error or rework rate, cost per error event.
+
+**Uplift**: Percent reduction in error rate.
+
+**Conversion**: Avoided rework hours, avoided refunds or chargebacks, avoided regulatory fines, avoided escalations.
+
+**Trap**: AI can introduce new error classes (hallucinations, miscategorization). Net the gross reduction against new error costs and assumed remediation effort.
+
+## 4. Revenue lift
+
+**What it is**: Higher conversion, larger deal size, faster sales cycles, better cross-sell, reduced churn.
+
+**Baseline**: Current conversion rate, average deal size, sales cycle, churn rate.
+
+**Uplift**: Percent change in the relevant metric.
+
+**Conversion**: Incremental revenue × gross margin (not revenue alone — finance partners will discount revenue-only claims).
+
+**Trap**: Attribution. State how the lift will be measured and whether a holdout, A/B, or pre-post comparison is feasible.
+
+## 5. Risk avoidance
+
+**What it is**: Reduced exposure to regulatory fines, security incidents, fraud loss, or safety events.
+
+**Baseline**: Frequency of events × cost per event, or expected loss from current risk model.
+
+**Uplift**: Percent reduction in event frequency or severity.
+
+**Conversion**: Expected-loss reduction. State explicitly that this is a probabilistic benefit and may not appear in any single year's P&L.
+
+**Trap**: CFOs heavily discount risk-avoidance claims. Show them, but do not lean the headline ROI on them.
+
+## 6. Capacity reallocation
+
+**What it is**: Freed analyst, support, or specialist capacity that gets redirected to higher-value work.
+
+**Baseline**: Hours per week consumed by the current workflow.
+
+**Uplift**: Hours per week reclaimed.
+
+**Conversion**: Reclaimed hours × value of the redirected work (project hours, advisory hours, customer-facing hours). If the redirected work has no quantified value yet, present capacity in hours and flag the conversion as pending.
+
+**Trap**: Double-counting. Do not count the same hour as both "labor productivity cash savings" and "capacity reallocated".
+
+## 7. Cost-to-serve reduction
+
+**What it is**: Lower marginal cost per transaction, ticket, claim, or interaction.
+
+**Baseline**: Current cost per unit (people + tools + overhead).
+
+**Uplift**: Percent reduction in cost per unit, multiplied by volume.
+
+**Conversion**: Direct cost out the door if the resources are actually shed; otherwise capacity reallocated.
+
+**Trap**: Same as labor productivity — only model as cash if the cost actually leaves the organization.
+
+## Choosing categories
+
+Most AI use cases land in 2–3 of these categories. Pick the ones the workflow actually changes and avoid stacking categories that overlap (for example, throughput and capacity reallocation often double-count).
+
+## Always state
+
+- Source label per line (`logged`, `interview`, `benchmark`, `hypothesis`)
+- Whether the benefit is cash, capacity, or risk-avoidance
+- Currency, period, and realization factor used

package/.jumpstart/skills/roi-calculator-builder/references/ai-cost-categories.md

@@ -0,0 +1,112 @@
+# AI Cost Categories (TCO Stack)
+
+Use this reference to build a complete cost stack for an AI use case. AI TCO is dominated by recurring costs that generic IT models miss — model usage, eval, observability, governance, and adoption. Never zero these out to make ROI look better.
+
+Group costs into one-time build cost and ongoing run-rate. Show both per year across the horizon.
+
+## A. One-time build cost
+
+### A1. Discovery / Jump Start
+
+Workshop fees, discovery effort, value-case shaping, data readiness assessment.
+
+### A2. Pod or build delivery
+
+Engineering, design, architecture, and PM effort to deliver the MVP or pilot. State whether estimated using `bottom-up-estimation` or another approach.
+
+### A3. Data preparation
+
+Source identification, cleansing, chunking, labeling, golden-set creation, redaction, and any data contract work.
+
+### A4. Integration build
+
+API, identity, secrets, and data-pipeline work for systems-of-record. Often underestimated.
+
+### A5. Initial governance and RAI sign-off
+
+DPIA, RAI impact assessment, security review, model risk review (especially for FS / healthcare).
+
+### A6. Initial change management
+
+Persona research, training material, comms, role redesign.
+
+## B. Ongoing run-rate (per year)
+
+### B1. Model usage
+
+Token costs at expected volume. Model with three points: low / base / high token volume per user per month, multiplied by users and price per million tokens. State the model and pricing tier assumed and flag that pricing may change.
+
+Variables:
+- prompts per user per period
+- input tokens per prompt (system + retrieved context + user input)
+- output tokens per response
+- model and pricing tier (frontier vs. small vs. fine-tuned)
+- caching assumptions (prompt caching, semantic cache hit rate)
+
+### B2. Retrieval / vector / search infra
+
+Vector store (managed or self-hosted), index storage, query volume, hybrid search, reranking, embedding regeneration when content changes.
+
+### B3. Hosting and orchestration
+
+Compute for orchestration, queueing, function endpoints, memory store, agent runtime. Networking and egress where relevant.
+
+### B4. Evaluation and observability
+
+Eval set maintenance, regression eval runs on every prompt or model change, tracing and logging, drift monitors, red-team testing. This is recurring, not one-time.
+
+### B5. Governance, RAI, and compliance run-rate
+
+Periodic RAI reviews, audit logging, policy updates, security re-reviews, model-risk re-attestation (where required), regulatory reporting.
+
+### B6. Support and operations
+
+L1/L2 support, incident response runbooks, on-call, prompt and tool maintenance, dataset refresh.
+
+### B7. Change management run-rate
+
+Ongoing training, role-based enablement, internal comms, adoption coaching. Recurring as the user population grows or rotates.
+
+### B8. Licensing
+
+Copilot, Copilot Studio, AI Foundry, third-party SaaS, vector store SaaS, observability SaaS.
+
+### B9. Reserve for model and pricing change
+
+The first model is not the last model. Assume at least one model swap or pricing change inside the horizon and reserve a percentage of run-rate accordingly (commonly 10–20 percent on top of B1–B3).
+
+## C. Costs that often get missed
+
+- Prompt and tool maintenance over time
+- Embedding regeneration when underlying content changes
+- Eval set growth and re-labeling
+- RAI reattestation when models or use cases change
+- Data refresh pipelines for retrieval freshness
+- Internal training for new joiners after rollout
+- Decommission cost if the use case fails
+
+## D. Pricing inputs to state explicitly
+
+When you use placeholder rates, label them:
+
+- Token price per million (state model and date of pricing assumption)
+- Loaded hourly rate per role (state whether fully loaded)
+- Vector store cost per million vectors per month
+- Observability cost per ingested GB or per span
+- Pod day rate or blended rate (if pricing conversion is requested — see `bottom-up-estimation`'s `pricing-conversion-guide.md`)
+
+## E. Output pattern
+
+Show costs as a table by year:
+
+| Cost line | Y0 (build) | Y1 | Y2 | Y3 | Source |
+|---|---|---|---|---|---|
+| Pod delivery | ... | ... | ... | ... | estimate |
+| Model usage (base) | ... | ... | ... | ... | hypothesis |
+| Vector / retrieval | ... | ... | ... | ... | benchmark |
+| Eval and observability | ... | ... | ... | ... | hypothesis |
+| Governance and RAI | ... | ... | ... | ... | interview |
+| Change management | ... | ... | ... | ... | hypothesis |
+| Reserve for model change | ... | ... | ... | ... | assumption |
+
+State which lines are hypothesis and therefore candidates for sensitivity flexing.

package/.jumpstart/skills/roi-calculator-builder/references/risk-adjusted-roi.md

@@ -0,0 +1,76 @@
+# Risk-Adjusted ROI
+
+AI use cases carry risks that classic IT ROI models do not. A defensible business case applies an explicit risk discount and shows the adjusted view alongside the unadjusted view.
+
+The point is not to make the number smaller for its own sake. The point is to show the sponsor that the risk has been thought about, quantified, and the case still holds.
+
+## The three discounts
+
+Apply each discount as a multiplier on the relevant benefit lines, not on costs.
+
+### 1. Accuracy discount
+
+How much of the modeled benefit actually realizes given expected accuracy of the AI output.
+
+Reasoning:
+- If the AI must be right 100 percent of the time and is 92 percent accurate, the 8 percent error path eats into benefits via rework, escalation, or shadow review.
+- For high-stakes workflows, even small accuracy gaps compound.
+
+Pattern:
+- accuracy-adjusted benefit = gross benefit × (accuracy − required_accuracy_floor) / (1 − required_accuracy_floor), bounded at 0
+- or simpler: gross benefit × expected accuracy, with a separate line item for the cost of the error path (review, rework, escalation)
+
+State the assumed accuracy and how it was estimated (eval set, comparable rollout, hypothesis).
+
+### 2. Adoption discount
+
+How much of the eligible user population actually uses the system at the assumed frequency, given organizational and behavioral friction.
+
+Pattern:
+- adoption-adjusted benefit = gross benefit × adoption rate × usage frequency factor
+
+State the adoption rate and the basis (comparable rollout, change-readiness assessment, hypothesis). Adoption is consistently the single biggest reason AI ROI underdelivers — do not skip this.
+
+### 3. Dependency discount
+
+How much benefit is at risk because of integration, data, vendor, or governance dependencies that the Pod does not control.
+
+Pattern:
+- dependency-adjusted benefit = gross benefit × (1 − dependency risk factor)
+
+The dependency risk factor is a judgment call. A pragmatic approach:
+
+| Dependency posture | Factor |
+|---|---|
+| Clean access, owner identified, integration tested | 0.05–0.10 |
+| Access ambiguous, owner unclear, integration unproven | 0.15–0.25 |
+| Multiple unowned dependencies, governance gates unscheduled | 0.30+ |
+
+State the named dependencies and which ones drive the factor.
+
+## Combined risk-adjusted view
+
+Apply the three discounts in sequence on the relevant benefit lines:
+
+risk-adjusted benefit = gross benefit × accuracy factor × adoption factor × (1 − dependency risk factor)
+
+Recompute ROI, payback, and NPV using the adjusted benefits and report alongside the unadjusted base case.
+
+## Output pattern
+
+| Metric | Base case | Risk-adjusted | Drivers of the adjustment |
+|---|---|---|---|
+| 3-yr ROI | 180% | 110% | adoption 0.65, accuracy 0.92, dependency 0.15 |
+| Payback | 11 months | 14 months | same |
+| NPV @ 10% | $4.2M | $2.6M | same |
+
+If the risk-adjusted case is still positive, state that explicitly — that is the strongest sentence in the business case.
+
+If the risk-adjusted case is negative or marginal, say so and recommend the discovery actions that would reduce the discount factors (for example: validate adoption with a comparable rollout, run an accuracy eval on a representative sample, name dependency owners and confirm integration ownership).
+
+## What not to do
+
+- Do not apply the risk discount to costs. Costs are what they are.
+- Do not present the risk-adjusted number alone — always show alongside the base case so the sponsor sees both.
+- Do not assume 100 percent adoption or 100 percent accuracy. There is no AI rollout where both are true.
+- Do not invent precise risk factors. State them as judgment with a basis and offer to tighten them with named discovery actions.

package/.jumpstart/skills/roi-calculator-builder/references/roi-methodology.md

@@ -0,0 +1,93 @@
+# ROI Methodology
+
+Use this reference when building any ROI/TCO model. It defines the reasoning order, formulas, and benefit-realization logic.
+
+## Reasoning order
+
+1. Frame the use case (workflow, users, decision, horizon).
+2. Establish a baseline with labeled sources.
+3. Define the AI intervention — what step or outcome changes.
+4. Quantify benefits per category using `users × frequency × baseline × uplift × realization`.
+5. Build the cost stack (see `ai-cost-categories.md`).
+6. Compute headline metrics: ROI, payback, NPV, optionally IRR.
+7. Run sensitivity (see `sensitivity-analysis-guide.md`).
+8. Apply risk adjustment (see `risk-adjusted-roi.md`).
+9. Compare scenarios (do-nothing, proposed, optional buy and scale).
+10. Write the defensible narrative and the next-discovery questions.
+
+## Source labels
+
+Every benefit and cost line should carry a label so the reader can retrace it:
+
+- `logged` — pulled from a system, ticketing tool, or telemetry
+- `interview` — stated by an SME or workflow owner
+- `benchmark` — taken from an industry or analyst benchmark (cite source)
+- `hypothesis` — assumed for the model and needs validation
+
+If a line is `hypothesis`, it is a candidate variable for sensitivity analysis.
+
+## Formulas
+
+### ROI (simple)
+
+$$
+\text{ROI \%} = \frac{\text{Net Benefits}}{\text{Total Costs}} \times 100
+$$
+
+Net benefits = total benefits over horizon − total costs over horizon.
+
+### Payback period
+
+The first month or year in which cumulative net cash flow turns positive. State it in months for pilots and years for scale-ups.
+
+### NPV
+
+$$
+\text{NPV} = \sum_{t=0}^{T} \frac{CF_t}{(1+r)^t}
+$$
+
+Where $CF_t$ is the net cash flow in period $t$ and $r$ is the discount rate. Default to client WACC if known; otherwise use a labeled placeholder (often 8–12 percent for enterprise IT).
+
+### IRR
+
+Only include IRR if the user asks. State that IRR is unstable for short horizons and small cash flows and should be read alongside NPV, not instead of it.
+
+## Benefit-realization curve
+
+AI benefits do not start on day 1. Apply a realization factor to each year:
+
+| Year | Default realization | Notes |
+|---|---|---|
+| Year 0 (build) | 0 percent | benefits not yet flowing |
+| Year 1 | 40–70 percent | depends on adoption ramp and rollout phasing |
+| Year 2 | 80–95 percent | steady state if adoption holds |
+| Year 3 | 90–100 percent | mature; may decline if model drift unaddressed |
+
+Ramp slower for workflows that require behavior change or training. Ramp faster for workflows where AI is silently inserted into an existing tool.
+
+## Three-point ranges
+
+For each meaningful driver, model low / base / high. Examples:
+
+- Adoption rate: 30 / 55 / 75 percent of eligible users
+- Time saved per task: 2 / 5 / 9 minutes
+- Error reduction: 10 / 25 / 40 percent
+- Model run-rate: high / base / low based on token volume assumption
+
+The base case is what you defend. The low and high cases bound the conversation.
+
+## Headline metric pattern
+
+State headline metrics like this:
+
+> Base case: 3-year ROI of 180 percent, payback in 11 months, NPV of $4.2M at a 10 percent discount rate.
+> Low case: ROI 60 percent, payback 22 months. High case: ROI 320 percent, payback 7 months.
+> Risk-adjusted base case (after accuracy and adoption discounts): ROI 110 percent, payback 14 months.
+
+## Anti-patterns
+
+- Single-point ROI numbers with no range.
+- Treating year 1 benefits as full steady-state.
+- Comparing AI build cost to a baseline of zero rather than the real cost of the current process.
+- Hiding model, eval, or governance run-rate to make payback look faster.
+- Reporting IRR without NPV.

package/.jumpstart/skills/roi-calculator-builder/references/sensitivity-analysis-guide.md

@@ -0,0 +1,72 @@
+# Sensitivity Analysis Guide
+
+Sensitivity analysis is what separates a defensible model from a marketing slide. Without it, the headline number depends on assumptions the reader cannot see.
+
+## Goal
+
+Show the reader which 3–5 variables actually move the answer, by how much, and at what point the use case stops paying back.
+
+## Variables to flex first
+
+These are the variables that almost always dominate AI ROI sensitivity. Start here:
+
+1. **Adoption rate** — percent of eligible users who actually use the system at the assumed frequency.
+2. **Time saved per task** (or equivalent uplift metric for the workflow).
+3. **Token volume per user per month** (drives model run-rate).
+4. **Error reduction percent** (when the case relies on quality lift).
+5. **Realization curve** — how fast benefits ramp in year 1.
+6. **Loaded hourly rate** — when the case relies on labor productivity.
+7. **Conversion rate from hours saved to cash** — only relevant if the client is committing to actual headcount or contractor reduction.
+
+## Patterns
+
+### One-way sensitivity
+
+Hold all variables at their base case, flex one variable across its low / high range, and report the impact on ROI and payback.
+
+Output format:
+
+| Variable | Low | Base | High | ROI at low | ROI at high | Δ ROI |
+|---|---|---|---|---|---|---|
+| Adoption rate | 30% | 55% | 75% | ... | ... | ... |
+| Time saved per task | 2 min | 5 min | 9 min | ... | ... | ... |
+
+### Tornado chart (ranked one-way)
+
+Rank the one-way deltas largest to smallest. The top of the tornado is the variable the model is most sensitive to and therefore the variable to validate first in discovery.
+
+### Two-way sensitivity
+
+When two variables interact strongly (commonly adoption × time-saved, or token volume × prompts per user), show a 3×3 grid of ROI outcomes:
+
+|  | Adoption 30% | Adoption 55% | Adoption 75% |
+|---|---|---|---|
+| Time saved 2 min | ... | ... | ... |
+| Time saved 5 min | ... | ... | ... |
+| Time saved 9 min | ... | ... | ... |
+
+Highlight the cells where ROI turns negative or payback exceeds the horizon.
+
+### Breakeven / "what has to be true"
+
+Solve for the value of each key variable at which NPV = 0 or payback = horizon. State as: "Adoption must reach at least 28 percent for the case to break even at a 10 percent discount rate."
+
+This framing is highly defensible because it lets the sponsor judge whether the breakeven assumption is achievable.
+
+### Monte-Carlo-lite
+
+If the user wants probabilistic framing, model 3–5 key variables as triangular distributions (low / base / high) and report the percent of trials in which NPV is positive. Do not over-engineer — a 1,000-trial sample is plenty for a directional answer.
+
+## What to flag
+
+- Variables where the low case turns NPV negative or pushes payback beyond the horizon. These are the variables to validate first.
+- Variables that look high-impact but are actually dominated by another variable in the two-way view.
+- Variables labeled `hypothesis` in the benefit and cost worksheets — these are by definition unvalidated and belong in sensitivity.
+
+## Output pattern
+
+End the sensitivity section with:
+
+- a tornado-style ranking of the top 3–5 variables
+- one or two breakeven statements ("X must be at least Y for the case to clear breakeven")
+- a recommended next-discovery action for each top variable (run a usage log pull, do a 5-user time study, get token estimates from a comparable rollout, etc.)

package/.jumpstart/skills/roi-calculator-builder/templates/roi-model-template.md

@@ -0,0 +1,132 @@
+# ROI Model — [Use Case Name]
+
+## Business case framing
+
+- **Use case**: [named workflow and decision being supported]
+- **User population**: [count, role, geography]
+- **Time horizon**: [typically 3 years; 1 year for pilots]
+- **Currency**: [USD / EUR / ...]
+- **Discount rate**: [client WACC if known; otherwise labeled placeholder, e.g., 10% (assumed)]
+- **Fiscal calendar alignment**: [calendar year / client FY]
+- **Confidence level**: [pre-discovery / post-Jump Start / post-pilot]
+
+## Baseline
+
+Today's cost, throughput, error rate, or revenue contribution for the affected workflow.
+
+| Baseline metric | Value | Source |
+|---|---|---|
+| [e.g., tickets per month] | [n] | [logged / interview / benchmark / hypothesis] |
+| [current cycle time] | [n] | [...] |
+| [current error rate] | [n] | [...] |
+| [loaded hourly rate] | [n] | [...] |
+
+## AI intervention
+
+What the AI does in this workflow. Which step or outcome changes. Which step does **not** change.
+
+## Benefit model
+
+For each benefit line: `users × frequency × baseline × uplift × realization`. State category (cash / capacity / risk-avoidance) and source label.
+
+| Benefit line | Category | Y1 | Y2 | Y3 | Source | Notes |
+|---|---|---|---|---|---|---|
+| [labor productivity — first-line tickets] | capacity | ... | ... | ... | hypothesis | reallocated, not cash |
+| [throughput — tickets resolved] | cash | ... | ... | ... | logged | demand-bound |
+| [quality — escalation reduction] | cash | ... | ... | ... | interview | net of new error class |
+| [revenue lift — conversion] | cash | ... | ... | ... | hypothesis | gross-margin adjusted |
+| [risk avoidance — compliance miss] | risk | ... | ... | ... | benchmark | probabilistic |
+
+**Total benefits by year**: Y1 [...] / Y2 [...] / Y3 [...]
+
+## Cost stack (TCO)
+
+| Cost line | Y0 (build) | Y1 | Y2 | Y3 | Source |
+|---|---|---|---|---|---|
+| Discovery / Jump Start | ... | — | — | — | quoted |
+| Pod or build delivery | ... | — | — | — | bottom-up estimate |
+| Data preparation | ... | — | — | — | hypothesis |
+| Integration build | ... | — | — | — | estimate |
+| Initial governance / RAI | ... | — | — | — | interview |
+| Initial change management | ... | — | — | — | hypothesis |
+| Model usage (base) | — | ... | ... | ... | hypothesis |
+| Vector / retrieval | — | ... | ... | ... | benchmark |
+| Hosting / orchestration | — | ... | ... | ... | benchmark |
+| Eval / observability | — | ... | ... | ... | hypothesis |
+| Governance / RAI run-rate | — | ... | ... | ... | interview |
+| Support / operations | — | ... | ... | ... | hypothesis |
+| Change management run-rate | — | ... | ... | ... | hypothesis |
+| Licensing | — | ... | ... | ... | quoted |
+| Reserve for model / pricing change | — | ... | ... | ... | assumption |
+
+**Total costs by year**: Y0 [...] / Y1 [...] / Y2 [...] / Y3 [...]
+
+## Headline metrics
+
+| Metric | Low | Base | High |
+|---|---|---|---|
+| 3-year ROI | ...% | ...% | ...% |
+| Payback period | ... | ... | ... |
+| NPV @ [r]% | ... | ... | ... |
+| IRR (optional) | ... | ... | ... |
+
+State the base case in plain language:
+
+> Base case: 3-year ROI of [X]%, payback in [Y] months, NPV of [$Z] at a [r]% discount rate.
+
+## Sensitivity analysis
+
+Top variables, ranked by impact on ROI:
+
+| Variable | Low | Base | High | ROI at low | ROI at high | Δ ROI |
+|---|---|---|---|---|---|---|
+| Adoption rate | ... | ... | ... | ... | ... | ... |
+| Time saved per task | ... | ... | ... | ... | ... | ... |
+| Token volume per user / month | ... | ... | ... | ... | ... | ... |
+| Realization curve (Y1) | ... | ... | ... | ... | ... | ... |
+| Error reduction | ... | ... | ... | ... | ... | ... |
+
+**Breakeven statements**:
+
+- [Variable] must be at least [value] for the case to clear breakeven at the assumed discount rate.
+
+## Risk-adjusted ROI
+
+| Metric | Base case | Risk-adjusted | Adjustment drivers |
+|---|---|---|---|
+| 3-yr ROI | ...% | ...% | adoption [a], accuracy [b], dependency [c] |
+| Payback | ... | ... | same |
+| NPV @ [r]% | ... | ... | same |
+
+State whether the risk-adjusted case still clears the bar. If marginal or negative, list the discovery actions that would reduce the discount factors.
+
+## Scenario comparison
+
+| Scenario | 3-yr cost | 3-yr benefit | Net | Notes |
+|---|---|---|---|---|
+| Do nothing | ... | ... | ... | the cost of the current process continues |
+| Proposed Pod build | ... | ... | ... | base case |
+| Buy / SaaS alternative (optional) | ... | ... | ... | lower control, faster start |
+| Scale-up after pilot (optional) | ... | ... | ... | requires successful pilot exit criteria |
+
+## Defensible narrative
+
+[A short paragraph the sponsor can drop into a proposal, steering committee deck, or funding memo. Include the headline number, the assumptions it depends on, the risk-adjusted view, and what would break it.]
+
+## Open questions and next discovery
+
+1. [Top sensitivity variable] — confirm via [named action]
+2. [Baseline source needing validation] — confirm via [named action]
+3. [Dependency owner not yet named] — confirm with [named stakeholder]
+4. [Adoption assumption] — validate via [comparable rollout, change-readiness assessment]
+5. [Pricing or licensing assumption] — confirm with [vendor or sourcing]
+
+## Appendix: assumptions register
+
+| Assumption | Value | Source label | Sensitivity-tested? |
+|---|---|---|---|
+| Discount rate | [r]% | placeholder / WACC | yes / no |
+| Loaded hourly rate | ... | benchmark | yes / no |
+| Token price per million | ... | vendor pricing as of [date] | yes / no |
+| Adoption rate | ... | hypothesis | yes |
+| ... | ... | ... | ... |

package/.jumpstart/skills/roi-calculator-builder/templates/roi-worksheet-template.csv

@@ -0,0 +1,31 @@
+section,line_id,line_name,category,unit,low,base,high,year_0,year_1,year_2,year_3,source_label,sensitivity_tested,notes
+benefit,B1,Labor productivity - first-line tickets,capacity,USD,,,,0,,,,hypothesis,yes,reallocated capacity not cash
+benefit,B2,Throughput - tickets resolved,cash,USD,,,,0,,,,logged,yes,demand-bound
+benefit,B3,Quality - escalation reduction,cash,USD,,,,0,,,,interview,yes,net of new error class
+benefit,B4,Revenue lift - conversion,cash,USD,,,,0,,,,hypothesis,yes,gross-margin adjusted
+benefit,B5,Risk avoidance - compliance miss,risk,USD,,,,0,,,,benchmark,no,probabilistic
+cost,C1,Discovery / Jump Start,one-time,USD,,,,,0,0,0,quoted,no,
+cost,C2,Pod or build delivery,one-time,USD,,,,,0,0,0,bottom-up,no,
+cost,C3,Data preparation,one-time,USD,,,,,0,0,0,hypothesis,yes,
+cost,C4,Integration build,one-time,USD,,,,,0,0,0,estimate,yes,
+cost,C5,Initial governance / RAI,one-time,USD,,,,,0,0,0,interview,no,
+cost,C6,Initial change management,one-time,USD,,,,,0,0,0,hypothesis,yes,
+cost,C7,Model usage,run-rate,USD,,,,0,,,,hypothesis,yes,token volume x price
+cost,C8,Vector / retrieval,run-rate,USD,,,,0,,,,benchmark,yes,
+cost,C9,Hosting / orchestration,run-rate,USD,,,,0,,,,benchmark,no,
+cost,C10,Eval / observability,run-rate,USD,,,,0,,,,hypothesis,yes,recurring not one-time
+cost,C11,Governance / RAI run-rate,run-rate,USD,,,,0,,,,interview,no,
+cost,C12,Support / operations,run-rate,USD,,,,0,,,,hypothesis,yes,
+cost,C13,Change management run-rate,run-rate,USD,,,,0,,,,hypothesis,yes,
+cost,C14,Licensing,run-rate,USD,,,,0,,,,quoted,no,
+cost,C15,Reserve for model / pricing change,run-rate,USD,,,,0,,,,assumption,yes,10-20% on top of B1-B3
+parameter,P1,Adoption rate,driver,percent,0.30,0.55,0.75,,,,,hypothesis,yes,top sensitivity variable
+parameter,P2,Time saved per task,driver,minutes,2,5,9,,,,,hypothesis,yes,
+parameter,P3,Token volume per user per month,driver,tokens,,,,,,,,hypothesis,yes,
+parameter,P4,Realization Y1,driver,percent,0.40,0.55,0.70,,,,,assumption,yes,
+parameter,P5,Realization Y2,driver,percent,0.80,0.90,0.95,,,,,assumption,no,
+parameter,P6,Realization Y3,driver,percent,0.90,0.95,1.00,,,,,assumption,no,
+parameter,P7,Discount rate,driver,percent,,0.10,,,,,,placeholder,no,client WACC if known
+parameter,P8,Accuracy factor,risk,percent,0.85,0.92,0.97,,,,,hypothesis,yes,
+parameter,P9,Adoption factor (risk view),risk,percent,0.40,0.65,0.80,,,,,hypothesis,yes,
+parameter,P10,Dependency risk factor,risk,percent,0.05,0.15,0.30,,,,,judgment,yes,named dependencies drive this