Value Leakage: Attribution
Objective. Open Attribution and confirm that each high-value finding has a named, accountable owner, because an un-owned leak is not a recovery plan.
This screen answers 'who can actually act on this leak?' It attributes findings to an owner, turning a sized number into something a real person is accountable for.
See it in the demo
What this screen answers
A sized leak with no owner is just a statistic. Attribution answers 'who can act on this, and who is accountable for recovering it?' A Sales person uses it to show the customer that findings become assignable work, not just a report; a CSM uses it to make sure every high-value finding has a named owner before it goes into a recovery plan.
The task
Open Attribution at the cited route. For the top findings, check that each has an owner and that the owner is a real accountable role, not a vague team label. Note any high-value finding that is un-owned - that is the gap to close. Describe ownership at the level the app supports; do not invent an assignment control or workflow you have not confirmed with product.
How to read it
Attribution tells you who can act; it does not tell you the leak is solved or that the value is recovered. The misread to avoid: treating an assigned owner as progress. Assignment is the start of accountability, not evidence of recovery - recovery status lives on the Recovery screen. Also watch for the same owner carrying overlapping findings, where two entries may describe the same hours and should not be counted twice against them.
Honest limits
This screen proves findings can be attributed on seeded demo data. It does not prove the customer's real org model, roles or who is genuinely accountable. How ownership maps to the customer's structure and whether assignment drives any real workflow are customer-specific - confirm with product. Owner coverage (the share of high-value findings with a named owner) is a useful adoption measure to agree with the customer.
Interpretation check
Attribution names who can act; it is not evidence that the leak is recovered. An assigned owner is the start of accountability, not progress - recovered value is only what the Recovery screen verifies.
Practical task
Open Attribution, list the top findings and their owners, and flag any high-value finding that is un-owned or owned only by a vague team label - that is the first ownership gap to close with the customer.
Self-check
Why insist every high-value finding has a named owner?
Because an un-owned leak is not a plan - no one is accountable for recovering it. Owner coverage is what turns a sizing exercise into a living recovery programme.
A finding has an owner assigned. Can you report it as progress?
No. Assignment is the start of accountability, not recovery. Progress and recovered value are tracked on the Recovery screen with evidence and status.
What is a good adoption measure this screen supports?
Owner coverage - the share of high-value findings that have a named, accountable owner. A low figure means leaks are sized but not yet actionable.
What should you confirm with product about attribution?
How ownership maps to the customer's real roles and org structure, and whether assignment drives any downstream workflow - the demo shows the concept on seeded data, not the customer's model.
Verified vs demo. Screen is live in the demo at /#/attribution; exact controls and figures are SME-validation-pending.