Say who needs the change.
“Customers need a receipt for a completed order” gives the team a reason to act. Explain the present difficulty so people can judge whether the proposed work fits it.
The Loop · Outcomes and evidence
Choose a useful outcome.
Show what changed.
Agree what should be different and what would let you check it. Keep delivery, expected benefits and unanswered questions clear enough for the team to make its next decision.
- Intended outcome
- Relevant evidence
- Next decision
A result the team can judge
Define what should change
A useful outcome
can be checked.
Start with the people or process the work should help. Describe the current problem, the change you intend and the conditions that matter. Name an owner responsible for that outcome within their area of responsibility.
Describe the checkable result.
“Customers can download their own receipt from the order page” describes behavior you can try. Add acceptance criteria for correctness, access and relevant failure handling.
Keep the hope testable.
“Fewer receipt requests reach Support” is a benefit to investigate. Agree the evidence and observation period before claiming that it happened. It may take longer to observe than the delivery itself.
Choose evidence for the question
Use a check that fits the outcome.
There is no single measure for every Focus. A technical fix, a handover, an investigation and a new service need different checks. Choose sources the people reviewing the work are allowed to read.
| Question | Useful evidence | Limit to record |
|---|---|---|
| Can the intended action be completed? | Acceptance checks, a test result or a recorded walkthrough of the agreed behavior. | Say which conditions were tested. A test environment does not prove the result is available to every intended user. |
| Can people use what was delivered? | A relevant person trying the task, with the unclear steps and access problems recorded. | A walkthrough gives useful evidence for those conditions. It does not represent every user or situation. |
| Did the expected benefit happen? | Relevant records from comparable periods, such as the same category of support request before and after a change. | Keep the scope, dates and source consistent. Other changes may also explain the difference. |
| Did an investigation support a decision? | The options considered, findings, constraints and a decision checked against agreed criteria. | Record assumptions and unanswered questions. New evidence may change the decision. |
For each check, agree who will gather the evidence, where it will be kept and when it is useful to review it. Use the existing sources and tools you have. Record missing evidence instead of filling the gap with an assumption.
Distinguish activity from change
Work moved.
What became possible?
Tasks completed, meetings held and agent requests finished describe activity. They can help explain the effort, but they do not by themselves show that the intended outcome or benefit happened.
Ask what the delivered work now lets someone do. Then ask whether you have evidence of the broader change you expected. Keep those conclusions separate when the evidence supports only one of them.
Delivery evidence.
A saved test result, accepted design, reviewed document or usable service can show that the agreed output exists. Check it against the work’s acceptance criteria.
Outcome evidence.
A relevant observation can show what changed for the intended people or process. Explain the source, conditions and period it covers.
Delivery flow.
Where enabled, Tellenze Insights describes recorded work flow, such as completion, blockers and time in stage. Use it to examine delivery. It does not by itself prove a customer benefit.
Read what delivery measures meanA synthetic worked example
Self-service receipts.
Two different checks.
A team plans a Focus so customers can download a receipt. It also hopes this will reduce manual support work. The example below is an evidence plan and a decision rule, not a report of measured customer results.
DELIVERY / THE AGREED CAPABILITY
Check the download behavior.
The acceptance criteria cover a correct receipt for a completed order, access to the customer’s own receipt and a useful response to a failed download.
- 1Prepare the evidence.
Keep the test conditions, expected behavior and results with the work.
- 2Review the result.
The responsible reviewer checks each criterion and the linked output.
- 3State what it proves.
If the checks pass, record the delivered capability and the conditions under which it was verified.
BENEFIT / A HYPOTHESIS TO CHECK
Observe the support work.
The hoped-for benefit is fewer manual receipt requests. Agree which requests count, which periods are comparable and who can inspect the relevant records.
- 1Choose a comparable source.
Use the same request category and a clearly recorded scope and period.
- 2Keep uncertainty visible.
If no comparable evidence is available, record “Not measured yet.” Do not turn passed delivery checks into a claimed reduction.
- 3Choose the next action.
Agree whether another observation or a separate improvement is useful. Give approved follow-up work an owner and a clear check.
Keep the limits beside the finding
Say what you know.
Say what you still need.
Record what was checked, the source and the conditions. Name missing history, a narrow sample, inaccessible evidence or another change that might explain the result. Separate a recorded fact from your interpretation of it.
An agent can summarize accessible evidence and point out gaps. Ask for source references, then check them. A confident answer is not extra evidence.
Agree people’s and agents’ responsibilities- Question
- What change are we trying to check?
- Source
- Which result or record supports the finding, and when was it checked?
- Finding
- What does that evidence show under these conditions?
- Limits
- What is missing, uncertain or outside this check?
- Decision
- What will we keep, change or check next, and who will follow through?
Use a shared document or the work item’s saved context. These are suggested headings, not new required product fields.
Bring the evidence back to people
Review the value.
Choose what follows.
Review when there is a useful result to judge. A Focus may be timeboxed, but time spent is not proof of success. Different outcomes can need different intervals and observation periods.
Check the agreed result.
Bring in the people who can judge its value. Compare the outcome and acceptance criteria with the saved evidence. Keep a missing review or approval visible while it remains.
Close with a clear boundary.
The Focus can close when its main delivery value is achieved, even if some tasks remain. Keep unfinished tasks in their true state and put that work in an explicit follow-up Focus.
With project planning enabled in Tellenze, Close & snapshot records membership and releases the tasks. It does not complete them.
Read Focus closure behaviorLet the finding change later work.
Keep the lesson, its reason and where it applies. Decide whether to update guidance, improve a check or prepare a new Focus. Review AI-suggested changes before accepting them.
See learning in practiceKeep the record usable in Tellenze
A source to revisit.
A report you can review.
Use Definition and Completion summary to explain the task’s delivered result. Outcome documents can link supporting Knowledge. Use Conversation for useful decisions and progress.
Where Reviews is enabled, choose evidence from work you can access and prepare a report for its intended audience. Preview the actual report before publishing an edition to named readers.
Prepare and share a reviewed resultCheck the scope and freshness.
A review captures selected evidence; it does not continuously update itself. Refresh changed evidence before generating or publishing, and read the source references in proposed text.
Keep access specific.
Publishing an approved edition shares its report with named readers. It does not grant access to the linked source work. Private workshop evidence requires the relevant participants and source access.
Use available measures carefully.
Check delivery coverage, filters and sample counts when using Insights. A target date or delivery forecast describes a plan or estimate; it does not prove that the outcome has already happened.
A few useful details
Make the conclusion fit the evidence.
Does every outcome need a numerical target?
Use a check that fits the work. A delivery can have observable acceptance criteria. An investigation can lead to a decision checked against agreed criteria. A claimed numerical benefit needs relevant measurements; do not invent a number just to make the outcome look precise.
Can we verify delivery before the wider benefit is known?
Yes. State the delivered capability and what was verified. Keep the expected benefit separate and record when it has not yet been measured. Agree who will check it and whether that needs follow-up work.
Can a Focus close while a task remains unfinished?
It can close when its main delivery value is achieved. Give unfinished work an explicit follow-up Focus and keep its actual stage and history. Closing the Focus is a separate action from completing its tasks.
Will Tellenze automatically prove our expected benefit?
Enabled delivery views calculate recorded work measures. The team still chooses relevant outcome evidence, checks its limits and makes the decision. An agent summary, planned date or forecast does not replace that judgment.
Use the result in the next Focus
A clear finding.
A useful next decision.
Keep the evidence and its limits, then choose one change the next piece of work can use.
Carry learning into later workContinue with a practical step
Keep the work connected.
COME TAKE A LOOK
A little less busy.
A lot more together.
Curious? Join the waitlist and see how we welcome your team.
Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.
Join waitlist Start with your email. No payment needed to join.