Skip to main content

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 are the realised, often measurable results of delivered AI work. Where an ICE score 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 or an Expert Request. 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 ScoreOutcome
Captured byThe team delivering the workAnyone with write access to the parent — including you
WhenAt planning (estimated) and at closeout (final)At closeout, and any time afterwards as new results materialise
What it describesThe team’s account of deliveryThe realised business result
Locks?Final score locks shortly after closeoutNo 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:
FieldRequired?What it’s for
TitleYesA short, plain-English headline
Outcome typeYesOne of: revenue won, cost reduced, productivity gained, adoption milestone, other
NarrativeYesThe story — what changed, who noticed, why it’s attributable to the work
Metric valueOptionalThe number — e.g. 2000000
Metric unitRequired if value is setThe unit — e.g. GBP, hours/week, users, %
Metric periodOptionalone_off, weekly, monthly, quarterly, or annual
Evidence URLOptionalA link to a supporting source — a board paper, a dashboard, an email
File attachmentsOptionalDocuments 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

TypeExample
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”
OtherAnything that doesn’t fit the four above — and is still worth recording

Capturing Outcomes

Outcomes can be captured in two places.
1
At closeout
2
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.
3
Any time afterwards
4
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. 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

ICE Scoring

The scoring model that Outcomes back up

Deliverables

Where most Outcomes attach — committed work delivered inside a project

Expert Requests

The other parent for Outcomes — standalone expert work

Reports

Where Outcomes roll up at the organization level