> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kowalah.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Outcomes
> Capture the realised, often measurable results of delivered AI work — the receipts that back up your Deliverables and Expert Requests.
Outcomes are the realised, often measurable results of delivered AI work. Where an [ICE score](/platform/scoring) describes what your team *expected* and what they *judged* once the work was done, an Outcome captures what your business *actually realised*.
A Deliverable that saved your support team 200 hours per week is one Outcome. A change request that won a £500K expansion deal because the customer's CTO referenced your new AI policy is another. Outcomes are the receipts.
Outcomes attach to a [Deliverable](/platform/projects/deliverables) or an [Expert Request](/platform/expert-requests). They're how the platform turns "we shipped it" into "and here's what changed in the business."
## Why Outcomes are separate from scoring
ICE scores and Outcomes do different jobs:
| | ICE Score | Outcome |
| --------------------- | ----------------------------------------------- | ----------------------------------------------------------------- |
| **Captured by** | The team delivering the work | Anyone with write access to the parent — including you |
| **When** | At planning (estimated) and at closeout (final) | At closeout, *and any time afterwards as new results materialise* |
| **What it describes** | The team's account of delivery | The realised business result |
| **Locks?** | Final score locks shortly after closeout | No lock — outcomes can be added or edited at any time |
You can think of Outcomes as the evidence backing your Deliverable's final Impact score. They sit on the same parent, but they're the things you'd actually quote in a board update.
## What an Outcome contains
Every Outcome captures:
| Field | Required? | What it's for |
| -------------------- | ------------------------ | --------------------------------------------------------------------------------- |
| **Title** | Yes | A short, plain-English headline |
| **Outcome type** | Yes | One of: revenue won, cost reduced, productivity gained, adoption milestone, other |
| **Narrative** | Yes | The story — what changed, who noticed, why it's attributable to the work |
| **Metric value** | Optional | The number — e.g. `2000000` |
| **Metric unit** | Required if value is set | The unit — e.g. `GBP`, `hours/week`, `users`, `%` |
| **Metric period** | Optional | `one_off`, `weekly`, `monthly`, `quarterly`, or `annual` |
| **Evidence URL** | Optional | A link to a supporting source — a board paper, a dashboard, an email |
| **File attachments** | Optional | Documents that back up the result |
The discipline of an Outcome is that you can usually put a number on it. *"Reduced AWS supplier spend by £2M annually"* is an Outcome. *"Improved team morale"* is a story. The platform will still let you log the story — it'll just gently warn you that ROI rollups exclude Outcomes without a metric.
### The five outcome types
| Type | Example |
| ----------------------- | -------------------------------------------------------------------------- |
| **Revenue won** | "Won a £500K expansion contract — their CTO referenced our AI policy work" |
| **Cost reduced** | "Reduced AWS supplier spend by £2M annually" |
| **Productivity gained** | "Saved 200 hours/week across the support team" |
| **Adoption milestone** | "Hit 65% weekly active adoption against a 60% target" |
| **Other** | Anything that doesn't fit the four above — and is still worth recording |
## Capturing Outcomes
Outcomes can be captured in two places.
When a Deliverable or Expert Request closes, the closeout form includes an **Outcomes** section alongside the final ICE score. Add as many Outcomes as you have at the time of closing — there's no minimum and no maximum.
Cost reductions often realise months after delivery. Revenue wins can be later still. The Outcome panel on a Deliverable or Expert Request stays open: you can add a new Outcome whenever fresh evidence lands, edit an existing one as the picture sharpens, or soft-delete one if it turns out the result wasn't really attributable to the work.
There's no lock window on Outcomes. Unlike the final score — which locks shortly after closeout to preserve the prediction-vs-result narrative — Outcomes are intentionally living. The dashboard becomes more honest over time.
## Who can capture Outcomes
Anyone with write access to the parent Deliverable or Expert Request can capture, edit, or soft-delete Outcomes. That includes:
* Kowalah team members working on the parent
* Your organization's admins and Core Team
* **Customer-side stakeholders** linked to the parent — the people closest to the realised result, who often see the evidence first
Soft-deleted Outcomes stay in the database for historical queries but don't appear on the Deliverable, Expert Request, or rollup dashboards.
## Attribution: one Outcome, one parent
An Outcome belongs to exactly one Deliverable or Expert Request. When the same realised business result is genuinely attributable to multiple pieces of work — say, a cost reduction driven by three concurrent Deliverables — capture it as **separate Outcome rows on each parent**, rather than fanning a single row across many.
Duplicated narrative is preferable to ambiguous attribution. Rollup queries can dedupe headline numbers at the dashboard layer if double-counting bites in practice.
## Evidence: links and files
Every Outcome can carry two kinds of evidence:
* **An evidence URL** — a link to a board paper, a dashboard, a customer email, an internal report
* **File attachments** — PDFs, spreadsheets, screenshots that back up the claim
Both are optional. An Outcome with neither is still valid — but linked evidence dramatically increases the weight an Outcome carries when leadership reads the rollup.
## Where Outcomes show up
Once captured, an Outcome appears on:
* **The parent Deliverable or Expert Request** page, in an Outcomes section
* **The project rollup**, summarised across all Deliverables in the project
* **The organization-level ROI view**, where Outcomes with metrics are aggregated by type
The scoring model that Outcomes back up
Where most Outcomes attach — committed work delivered inside a project
The other parent for Outcomes — standalone expert work
Where Outcomes roll up at the organization level