Stop Approving AI Pilots on a Spreadsheet: Build an Investment Admission Ledger

A proposed AI project can show a positive return on investment before anyone has proved that the problem exists, that the baseline is measurable, or that a financial benefit can actually be captured. The spreadsheet is usually arithmetically correct. The decision is still wrong.

That distinction matters in Switzerland, where small and medium-sized enterprises represent 99.7% of companies and 66.9% of employment according to the Federal Statistical Office's SME portrait. Most of those firms cannot absorb an indefinite sequence of pilots, duplicated subscriptions, integration surprises, and change programmes that never reach operations. Their scarce resource is not merely capital. It is management attention.

The right decision question is therefore not, “Does the business case show a positive ROI?” It is: has this investment earned the right to proceed to the next evidence stage?

This article turns the usual ROI worksheet into an investment admission ledger. The ledger preserves the useful ideas in the original Swiss SME guide to AI and digital-transformation ROI, but adds controls that a finance lead, operations owner, and technical lead can audit together. It separates measured facts from assumptions, prevents saved minutes from being counted as cash, prices the human work around the model, and defines a kill rule before enthusiasm makes stopping politically difficult.

The objective is not to promise a return. It is to make a go, redesign, hold, or stop decision defensible.

Why a positive ROI is not an admission ticket

The familiar formula is useful:

ROI = (benefits - costs) / costs

The problem is not the formula. The problem is what teams put into “benefits” and what they omit from “costs.” A project can pass the formula through four accounting illusions.

First, time saved is entered as cash saved. If an assistant reduces a task from forty minutes to twenty, the company has created capacity. It has not automatically reduced payroll, avoided a hire, increased billable output, or produced revenue. Capacity becomes cashable only when an operating decision captures it.

Second, the comparison is made against a fictional baseline. A team estimates the old process from memory after seeing the pilot. Slow exceptional cases receive too much weight, while rework, seasonality, and queue time are mixed with touch time. The resulting “before” number is impossible to reproduce.

Third, the denominator contains software licences and little else. Data preparation, integration, testing, security review, employee training, human verification, model monitoring, incident handling, and vendor exit work disappear. These are not edge costs. They are part of operating the system.

Fourth, a plausible improvement is treated as attributable to AI. Sales rise after a new assistant launches, but pricing changed, the campaign mix moved, and the sales team received training at the same time. Without a counterfactual, correlation becomes a benefit claim.

This is also a claims-control problem, not only an internal-finance problem. The US Federal Trade Commission's business guidance tells companies to examine whether an AI product actually performs better than a non-AI alternative and to retain adequate proof for comparative claims in its guidance on AI claims. A management forecast is not an advertisement by default, but the evidentiary discipline is transferable: a claimed advantage needs a defined comparator and support.

The current evidence supports caution. The OECD's 2025 report on AI adoption by SMEs finds positive associations between AI use and productivity, but also explains that advantages shrink when firm characteristics and complementary capabilities are considered. It notes that benefits may arrive only after investments in skills, processes, and organisation, producing a J-shaped path in which measured productivity can fall before it rises.

PwC's 2026 Swiss CEO findings provide the necessary counterweight to optimistic adoption stories: 67% of surveyed Swiss companies reported no upside from AI yet, while only 5% reported both cost savings and revenue gains. The study does not prove that any particular SME project will fail. It does show why adoption is not evidence of realised value.

An admission ledger answers that uncertainty with stages. It never asks management to believe the five-year forecast all at once.

Define the decision unit before measuring it

“AI transformation” is not a measurable unit. “Customer-support automation” is often still too broad. A valid decision unit has one process boundary, one accountable owner, one affected population, one evaluation window, and one observable outcome.

Consider a fictional twenty-five-person industrial supplier. It wants to classify incoming requests, retrieve relevant product documents, and prepare a response for a service employee to approve. The decision unit is not “deploy generative AI in service.” It is:

For German- and French-language product-information requests received through the shared support inbox, test whether an assisted workflow can reduce median handling time without increasing material answer errors during a six-week controlled pilot.

That sentence contains five controls:

• Population: product-information requests, not every support case.
• Channel: one shared inbox, not all customer contact.
• Human boundary: the employee approves the response.
• Outcome: handling time and material errors, not a vague productivity score.
• Window: six weeks, long enough to encounter variation but short enough to stop.

The scope also declares exclusions. Contract changes, safety incidents, payment disputes, and requests containing special-category personal data remain outside the pilot. An exclusion is not an admission of weakness. It prevents the easy cases from silently authorising expansion into high-consequence work.

Every ledger entry should have a named business owner and a named technical owner. The business owner owns the outcome and the capture mechanism. The technical owner owns system behaviour, cost telemetry, and failure containment. If nobody owns benefit capture, the benefit is not admitted. If nobody owns failure containment, the pilot is not admitted.

The ledger's unit is a decision, not a tool. A vendor demo, model benchmark, or licence discount can inform the decision, but none of them defines it.

Establish a baseline that another person can reproduce

A baseline is not a single average. At minimum, it records volume, touch time, elapsed time, first-pass quality, rework, escalation, and an outcome relevant to the process. Each field needs a source, owner, sampling method, and measurement date.

For the fictional support workflow, a four-week pre-pilot observation might record ticket arrival time, first human action, final resolution, number of document searches, whether the draft required correction, and whether the case was escalated. The company should stratify the sample by language and case type. Otherwise, a week dominated by simple German requests can make the pilot look better than a baseline containing complex bilingual cases.

Use medians and percentiles for skewed process times rather than relying only on the mean. A few multi-day cases can distort an average. Keep volume and error counts as integers. Preserve the raw observation identifiers so an auditor can trace a summary back to evidence without exposing customer content in the investment file.

The baseline also needs a data-quality statement. Missing timestamps, inconsistent status codes, and manual work outside the ticket system are part of the decision. If 30% of the process is invisible, a precise benefit estimate is not credible. The correct response may be a short instrumentation phase, not an AI pilot.

Build a counterfactual, not a before-and-after story

A before-and-after comparison is vulnerable to staffing, seasonality, product launches, marketing campaigns, and learning unrelated to the tool. A stronger pilot preserves a comparison path.

Depending on operational constraints, the company can use one of four designs:

1. Parallel shadow mode. The system produces an output, but employees continue the normal process. Reviewers compare the output without exposing customers to it.
2. Randomised assignment. Eligible cases are assigned to assisted or normal handling. This is strongest when volume is sufficient and the operational risk is low.
3. Matched cohorts. Assisted cases are compared with similar cases by language, product family, complexity, and arrival period.
4. Interrupted time series. Repeated measurements before and after launch are examined, with known external changes annotated. This is weaker than random assignment but better than selecting one convenient “before” week.

The counterfactual design belongs in the ledger before the pilot starts. Choosing it after seeing results invites cherry-picking.

Freeze the success and stop definitions

The team should define three different thresholds:

• Safety floor: the result below which the pilot stops immediately, such as a material-error rate above the accepted baseline or an uncontained data exposure.
• Operational threshold: the minimum evidence needed to move from shadow mode to limited live use.
• Investment threshold: the minimum risk-adjusted benefit and confidence needed to fund scaling.

These are not universal percentages. They depend on the process and the cost of error. A drafting assistant for an internal meeting note can tolerate a different error profile from a system proposing a safety instruction. The ledger forces the team to write the distinction instead of hiding it inside one composite score.

Classify benefits before converting them into money

The safest benefit model starts with categories. Only then should a category be converted to money, and only when a capture mechanism exists.

Benefit class	What may be measured	When it becomes financial	Typical evidence	Common overclaim
Cashable cost	Invoice, overtime, contractor spend, avoided hire	A budget line actually falls or an approved cost is avoided	Ledger, invoice, approved workforce plan	Multiplying every saved minute by salary
Capacity	Hours released at accepted quality	Work is reassigned to a constrained activity with measured output	Time study, queue and throughput records	Calling free capacity “savings”
Revenue	Incremental gross margin attributable to the intervention	A counterfactual links the change to qualified volume, conversion, price, or retention	Controlled cohort, CRM and margin records	Counting total sales after launch
Risk reduction	Lower expected loss from a defined event	Probability and impact assumptions are bounded and approved	Incident history, control testing, insurance or audit evidence	Treating avoided catastrophe as guaranteed cash
Service quality	Lower error, faster response, higher availability	A contract, retention effect, or cost of failure connects it to value	Quality review, SLA records, complaint data	Monetising satisfaction without a causal path
Option value	Learning that changes a later build/buy/stop decision	The experiment retires a named uncertainty at an agreed cost	Decision log, technical test, vendor comparison	Calling all experimentation strategic value

This table prevents double counting. Suppose the assisted workflow releases 300 hours in a year. If those hours allow the same team to absorb growth without a planned hire, the benefit may be an avoided cost. If they improve response time and retention, the benefit may be incremental margin. They cannot be counted fully in both categories.

Capacity has value even when it is not cashable, but it should remain labelled capacity. A director can then decide whether the organisation has a credible redeployment plan. Without one, the conservative financial value is zero, while the operational metric remains visible.

Risk reduction deserves similar discipline. Expected loss can be expressed as probability multiplied by impact, but both inputs are uncertain. Use a range and document the evidence. Do not manufacture a precise annual probability from one incident. If the new system introduces a new failure mode, include that exposure rather than only the risks it claims to reduce.

Revenue claims require gross margin, not top-line revenue. If an assistant helps produce additional sales, delivery costs still exist. Attribution must also reflect other simultaneous changes. A holdout or matched cohort is preferable; otherwise, apply a conservative attribution factor and show the decision under several assumptions.

Price the complete operating system, not the model endpoint

Total cost of ownership should be built from the operating architecture. A model request is one component. The cost ledger should include at least the following:

• process discovery and baseline instrumentation;
• data cleaning, access control, and document lifecycle work;
• integration, orchestration, logging, and evaluation tooling;
• model or application subscriptions and consumption;
• security, privacy, procurement, and legal review;
• subject-matter-expert time for evaluation and exception design;
• employee training and workflow redesign;
• human review during both pilot and steady state;
• monitoring, incident response, regression testing, and model changes;
• vendor management, data export, replacement, and exit testing;
• internal opportunity cost for people pulled away from other work.

The Swiss federal government's digitalisation programme offers a useful public-sector framing: automation is intended to simplify procedures, shorten processing times, improve quality, and release resources for important tasks, according to SECO's October 2026 announcement. Those are distinct outcomes. A shorter processing time does not necessarily lower cost, and released resources require an explicit destination.

Separate one-time costs from recurring costs and from volume-dependent costs. Then model at least three demand cases. A proof of concept can be cheap because it processes a curated sample and uses manual setup. Production may require peak capacity, multilingual evaluation, audit retention, user support, and redundancy. Conversely, a fixed enterprise licence can look expensive at pilot volume but economical after verified scale. The ledger makes both effects visible.

Include the cost of being wrong

Expected failure cost belongs in the denominator or as a separate risk adjustment. Define failure events, their detection paths, their maximum credible impact, and the controls that reduce exposure. Examples include a wrong product statement reaching a customer, confidential data entering an unauthorised service, an integration silently dropping cases, or employees over-trusting a fluent draft.

Do not convert every risk to money when evidence is weak. A red-line control can be more honest: if a critical event is observed, the stage fails regardless of the financial estimate. This keeps an apparently attractive ROI from overriding a non-negotiable boundary.

Exit cost is also real. Before admission, ask whether prompts, evaluation sets, logs, configuration, and business records can be exported in usable formats. Record how the workflow returns to manual operation. A pilot that cannot be reversed safely is already a production dependency.

Use gates that buy evidence in small increments

The ledger should move through gates. Each gate spends only enough to answer the next important uncertainty.

flowchart TD
  A[Problem evidence] --> B{Baseline reproducible?}
  B -- No --> B1[Instrument the process]
  B1 --> B
  B -- Yes --> C[Define counterfactual and kill rules]
  C --> D[Offline evaluation]
  D --> E{Safety floor passed?}
  E -- No --> X[Stop or redesign]
  E -- Yes --> F[Shadow mode]
  F --> G{Operational threshold passed?}
  G -- No --> X
  G -- Yes --> H[Limited live cohort]
  H --> I{Benefit captured and costs reconciled?}
  I -- No --> J[Hold: fix capture mechanism]
  I -- Yes --> K[Scale one bounded increment]
  K --> L[Post-launch benefits review]
  L --> M{Value persists?}
  M -- No --> N[Rollback or retire]
  M -- Yes --> O[Continue with monitoring]

Gate 0 — problem evidence. Confirm that the queue, error, delay, or opportunity is material enough to investigate. If the process is rare, unstable, or poorly owned, fix that first.

Gate 1 — baseline readiness. Confirm the measurement window, data completeness, case taxonomy, owner, and counterfactual. No benefits are projected beyond a broad range at this point.

Gate 2 — offline feasibility. Test representative historical cases in a protected environment. Measure task success, material error, abstention, latency, and unit consumption. Do not let a demo set define success.

Gate 3 — shadow operation. Run beside the real workflow without acting on customers. Measure how often employees agree, correct, ignore, or overrule the output. Record the human review time; it is part of recurring cost.

Gate 4 — limited live cohort. Expose a narrow eligible population with monitoring, escalation, and rollback. Reconcile forecast cost against actual invoices and actual internal effort.

Gate 5 — bounded scale. Expand one dimension at a time: volume, language, product family, autonomy, or user group. Changing several dimensions simultaneously destroys diagnostic value.

Gate 6 — benefit reconciliation. Finance and operations compare admitted benefits with captured benefits after the novelty period. Capacity that was never redeployed is reclassified. A forecast avoided hire that still occurred is removed. New support costs are added.

At every gate, the decision options are proceed, redesign, hold, or stop. “Proceed” is not the default. A stopped pilot can be successful if it retired uncertainty cheaply.

Implement the ledger as data, not presentation

A decision deck is easy to rewrite. A ledger should retain the assumptions and evidence used at each approval. The following executable JavaScript example uses fictional values solely to demonstrate the control logic. It does not represent a benchmark or expected Swiss-market return.

// Fictional demonstration data: replace every value with observed evidence.
const investment = {
  stage: "limited-live",
  evidence: {
    baselineReproducible: true,
    counterfactualDefined: true,
    sampleCoverage: 0.91,
    materialErrorRate: 0.012,
    acceptedMaterialErrorRate: 0.015,
  },
  annual: {
    cashableCostReduction: 18000,
    incrementalGrossMargin: 7000,
    riskAdjustedLossReduction: 3000,
    capacityOnlyValue: 24000, // displayed, deliberately excluded from cash ROI
    recurringCashCost: 14500,
    humanReviewCost: 5500,
    monitoringAndExitReserve: 3000,
  },
  oneTimeCost: 26000,
  confidence: 0.72,
  minimumConfidence: 0.70,
  maximumPaybackMonths: 24,
};

function evaluateAdmission(x) {
  const e = x.evidence;
  const passesEvidence =
    e.baselineReproducible &&
    e.counterfactualDefined &&
    e.sampleCoverage >= 0.85;

  const passesSafety =
    e.materialErrorRate <= e.acceptedMaterialErrorRate;

  const cashBenefit =
    x.annual.cashableCostReduction +
    x.annual.incrementalGrossMargin +
    x.annual.riskAdjustedLossReduction;

  const recurringCost =
    x.annual.recurringCashCost +
    x.annual.humanReviewCost +
    x.annual.monitoringAndExitReserve;

  const annualNetCash = cashBenefit - recurringCost;
  const paybackMonths = annualNetCash > 0
    ? (x.oneTimeCost / annualNetCash) * 12
    : Infinity;

  const decision = !passesEvidence || !passesSafety
    ? "STOP_OR_REDESIGN"
    : x.confidence < x.minimumConfidence
      ? "HOLD_FOR_EVIDENCE"
      : paybackMonths > x.maximumPaybackMonths
        ? "REJECT_OR_REPRICE"
        : "ADMIT_NEXT_STAGE";

  return {
    decision,
    cashBenefit,
    recurringCost,
    annualNetCash,
    paybackMonths: Number.isFinite(paybackMonths)
      ? Math.round(paybackMonths * 10) / 10
      : null,
    capacityShownButNotMonetised: x.annual.capacityOnlyValue,
  };
}

console.log(evaluateAdmission(investment));

The important line is not the payback calculation. It is capacityShownButNotMonetised. The evaluator refuses to hide useful operational capacity, but it also refuses to convert that capacity into cash without a capture mechanism.

In production, store each input with source, owner, observedAt, confidence, and expiry. An assumption that was reasonable during a pilot should not remain silently authoritative after pricing, staffing, or model behaviour changes.

Apply confidence to claims, not to the whole project

A single “confidence score” is convenient but blunt. Maintain confidence by benefit and cost line. Licence price may be contractual and high-confidence. Annual case volume may be moderately stable. Revenue attribution may be weak. Risk reduction may be a range.

Run sensitivity analysis on the uncertain lines. The executive question is not whether the central estimate is positive. It is which assumption changes the decision. If a small change in reviewer time turns the return negative, reviewer time is a measurement priority before scale. If the result remains acceptable even when volume is lower and costs are higher, the decision is more robust.

Do not compensate for low-quality evidence by choosing an aggressive discount rate or an ornate model. Better mathematics cannot repair missing observations.

Reconcile benefits after launch

Approval is the start of financial control, not its end. Create a benefits-realisation schedule with reviews after initial live use and after the workflow stabilises. The exact calendar depends on volume and seasonality, but every benefit needs a date on which it will be accepted, reclassified, or removed.

At reconciliation, compare:

• forecast eligible volume with observed eligible volume;
• forecast automation or assistance rate with accepted use;
• forecast human review time with measured review time;
• expected unit consumption with invoices and telemetry;
• claimed capacity with documented redeployment;
• expected cost avoidance with the approved budget;
• expected margin with attributable gross margin;
• expected quality with sampled, severity-weighted errors;
• expected risk reduction with control performance and incidents;
• planned exit readiness with a tested export and rollback.

Keep the original forecast visible. Do not overwrite it with actuals, because the variance is the learning. A project that delivers value for a different reason than forecast may still deserve continuation, but management should understand why the original model was wrong.

PwC's global AI performance study reports that 20% of surveyed organisations captured 74% of measured AI-driven returns, and associates that concentration with focused foundations and management practices. The survey covered 1,217 organisations and was primarily composed of large listed companies, so its percentages must not be imported as an SME forecast. Its useful contribution here is the operational contrast between activity and measurable outcomes, not a promised multiplier.

The OECD evidence also warns against judging too early. Complementary organisational change can delay productivity gains. That does not justify infinite patience. It means the pilot must specify which complementary investments are required, how much they cost, and what intermediate evidence would support continuing through the expected dip.

Failure modes the ledger must expose

The polished demo becomes the evaluation set

Demo cases are usually clean, known, and selected for visual impact. Build the evaluation set from representative historical cases, including rare but consequential categories. Freeze it before tuning, keep a separate holdout, and record exclusions.

Saved time has nowhere to go

Employees finish one task earlier, but the surrounding queue, approval, or staffing constraint prevents additional output. Record capacity, then identify the bottleneck that must change for value to be captured. Do not monetise the same minutes by default.

Human review is assumed to disappear

Review often becomes faster with familiarity, but it may also remain essential or grow as scope expands. Measure it. Include escalation, correction, and attention-switching time, not only the final click.

Average quality hides severe errors

An overall accuracy rate can look excellent while a rare class carries unacceptable impact. Use a taxonomy, severity weighting, and a red-line event list. An abstention can be safer than a confident wrong response and should be measured separately.

Pilot economics are projected directly to scale

Scale changes integration, support, governance, latency, and vendor pricing. It also changes the case mix. Re-estimate costs and outcomes at each bounded expansion rather than multiplying the pilot result by annual volume.

The vendor controls the evidence

A vendor-provided benchmark can inform feasibility but cannot substitute for the company's baseline and representative cases. Telemetry, invoices, evaluation records, and outcome data must remain independently auditable.

Management treats sunk cost as evidence

Money already spent does not improve the next-stage economics. The ledger should show incremental cost and evidence from the current point. A pre-agreed kill rule gives sponsors permission to stop without recasting the result as failure.

The organisation scales before it can reverse

If manual fallback, data export, or user-access removal has not been tested, the company has created lock-in before proving value. Exit readiness is a gate, not an appendix to procurement.

Final admission checklist

Before approving the next stage, the decision group should be able to answer every item with evidence:

• Is the decision unit one bounded process with explicit exclusions?
• Is there a business owner for the outcome and a technical owner for behaviour and containment?
• Can another analyst reproduce the baseline from retained observations?
• Are volume, time, quality, rework, escalation, and outcome metrics separated?
• Was the counterfactual design chosen before results were observed?
• Are the safety floor, operational threshold, and investment threshold distinct?
• Are cashable cost, capacity, revenue, risk reduction, quality, and option value labelled separately?
• Does every monetised benefit have a documented capture mechanism?
• Has double counting between capacity, avoided cost, and revenue been removed?
• Are revenue benefits based on gross margin and bounded attribution?
• Are integration, data, evaluation, security, training, review, monitoring, incident, and exit costs included?
• Are fixed, recurring, and volume-dependent costs modelled separately?
• Are severe error classes visible instead of hidden in an average?
• Are uncertain inputs expressed as ranges or scenarios rather than false precision?
• Does sensitivity analysis identify the assumptions that can reverse the decision?
• Is rollback operationally tested for the next stage?
• Is there a date and owner for benefits reconciliation?
• Will forecasts remain visible beside actuals?
• Is stopping treated as a valid result when the evidence fails?

If one of the first seven items is missing, do not improve the spreadsheet. Improve the experiment. If capture, cost, or rollback evidence is missing, hold the stage. If a safety floor fails, stop or redesign regardless of the projected return.

The decision is the product

An ROI percentage is an output. The investment admission system is the product that management needs.

It gives finance a traceable bridge from operational observations to cash. It gives operations a way to preserve capacity and quality outcomes without pretending they are already profit. It gives technical teams explicit evaluation, containment, and exit requirements. Most importantly, it makes uncertainty visible early, when changing course is still inexpensive.

The practical standard is simple: spend only enough to retire the next important uncertainty, preserve the evidence, and require benefits to survive reconciliation. An AI project has not earned scale because its forecast is attractive. It earns the next stage when the baseline, counterfactual, safety result, capture mechanism, full cost, and rollback path all remain defensible together.