The Enterprise Outcome Record
A schema for recording what actually happened after a technology decision: the baseline that makes it comparable, the costs vendors leave out, what was descoped, what else changed, and whether the organisation would do it again.
Version 0.1, draft, published 2026-08-11. A record of what actually happened after a technology decision, in a shape that can be compared.
There are ZERO real outcome records. The example below is illustrative and labelled as such in every field that could be mistaken for a measurement. When real records exist, this page will state how many and from how many organisations, because a database of outcomes with an unstated n is a database of anecdotes.
Why the schema before the data
Every roadmap in this project has eventually pointed at the same asset: a database of technology outcomes. It is the one thing a competitor cannot copy, buy or generate, because it is made of what happened to real organisations over real time. It is also the thing most completely gated on having customers, which is why the SCHEMA is worth building first: the day a pilot produces its first outcome, the shape it must be recorded in already exists and has been argued about while nothing was at stake.
The hard part is not storage
Not the storage. The hard part is that an outcome is only meaningful against a BASELINE captured before the decision, and baselines are almost never captured, because at the moment of deciding nobody wants to spend a week measuring the thing they have already agreed to replace. A record without a pre-decision baseline can describe what happened and cannot support any claim that it happened BECAUSE of the decision. This schema makes that distinction structural rather than a caveat: a record with no baseline is valid, and is marked uncomparable.
What a record must carry
| Field | Why it is required |
|---|---|
problem | The problem as stated BEFORE the solution was chosen. Recorded afterwards it is always the problem the chosen solution happens to solve. |
decision | What was chosen, and the alternatives that were rejected. A decision with no rejected alternatives was not a decision. |
baseline | The measurement taken before the change, with its date. Absent, the record is marked uncomparable rather than being quietly treated as if a baseline existed. |
implementation | What was actually done, including what was descoped. Descoping is the most common reason a projected benefit does not arrive and the least often recorded. |
cost | Total, separated into licence, implementation, internal effort and run. Vendor cases quote licence; the internal effort is usually the largest line and the one nobody tracks. |
elapsed | Decision date to steady state, not to go-live. Go-live is when the work starts being visible. |
outcome | The same measurement as the baseline, taken after steady state, by the same method. A different method makes a comparison a coincidence. |
attribution | What else changed in the same window. An enterprise is never a controlled experiment, and a record that pretends otherwise overstates the decision's effect. |
would_repeat | Would the organisation make the same decision again, and why. This single field carries more signal than the cost numbers and is the one a vendor case study never contains. |
Rules
- A record with no baseline is VALID and marked `comparable: false`. It may be read; it may not be aggregated into any claim about effect.
- Cost is recorded in the currency it was spent in, with the date. Converting to a single currency for a headline hides the exchange-rate assumption inside a number that looks measured.
- An outcome is recorded at steady state, and steady state is defined per record rather than assumed. Six weeks after go-live is still implementation for most estates.
- The organisation is never named without written permission, and is described by size, sector and region only. A record identifiable by its description is a named record with extra steps.
- Aggregates state n and the number of distinct organisations separately. Ten records from one organisation is one organisation's experience.
- A record is never edited after publication. A correction is a new version with the previous one still readable, the same rule the frozen forecast holds us to.
- Nothing is aggregated below five distinct organisations. Below that the range IS the finding, and a median from four is a number in the position of maximum influence.
A worked example
Illustrative. WORKED EXAMPLE. Every figure below is composed to exercise the schema and describes no real organisation. It is here so the fields have a shape a reader can argue with, and it is excluded from any count of real records.
problem | Termly reporting took two weeks of staff time and results were assembled by hand in spreadsheets, with transcription errors found after publication. |
decision | Consolidate records into the existing ERP and generate reports from it (rejected: Replace the ERP; Keep spreadsheets and add a review step) |
baseline | 142 hours — Staff hours per reporting cycle, counted from timesheets, captured 2026-01-10 |
descoped | Parent-facing dashboards; Historical data before 2024 |
cost | implementation PKR 850,000, internal 310 staff hours, run PKR 120,000 |
elapsed | 134 days to steady state, defined as: Two consecutive reporting cycles with no manual reconciliation |
outcome | 38 hours — same measure and method as the baseline, 2026-05-29 |
attribution | The additional hire plausibly accounts for part of the reduction. The record does not attempt to separate them, and any aggregate using it must carry that. |
would repeat | Yes, with the data migration scoped separately — The migration consumed most of the internal effort and was estimated as a fraction of it. |
The attribution row is the one that makes this different from a case study. A vendor would report the reduction and stop. This record says an extra hire landed in the same window and may account for part of it, which weakens the claim and is the reason the claim can be believed.
How this format gets gamed
- Recording only the outcomes that went well, which is how every vendor case study library is built and why none of them is evidence.
- A baseline reconstructed after the fact from whatever supports the result. If the baseline date is later than the decision date, it was reconstructed.
- Steady state declared early, while the benefit curve is still rising and before the operational cost has appeared.
- Attribution left empty, which reads as 'nothing else changed' and is almost never true.
- Aggregating across organisations of wildly different size to increase n. Ten records is not a population if two of them are a bank and eight are a school.
Questions to ask of any outcome claim
- Where is the baseline, and was it captured before the decision date or after?
- What was descoped during implementation, and was the benefit projection revised when it was?
- How is steady state defined in this record, and who decided it had been reached?
- What else changed in the same window?
- How many DISTINCT organisations are in this aggregate, as opposed to how many records?
- Which outcomes went badly, and are they in here?
Status
Version 0.1, draft, and zero records. It becomes useful at five distinct organisations, which is the floor below which this schema refuses to aggregate anything. Until then it is a shape, published so it can be argued with before there is anything at stake in the answer.
Everything here is free and stays free. There is no form in front of any document. If you want to know when new guides and templates go up, leave an email.
Roughly monthly. Unsubscribe in one click. We do not share your address, and we will not call you.