01 / Section
Start with an evidence-linked attempt
Review business work as an attempt to reach an outcome, not as a list of applications or clicks. A captured batch can connect recorded actions to a business result such as preparing a report, resolving a request, or updating a case. Keep the source evidence attached to each part of that account so another person can see where it came from.
A citation establishes provenance: it shows which captured material supports a statement. It does not prove that the statement is complete, correct, or representative. The review should therefore use careful language such as “the batch records” or “this attempt appears to include,” rather than treating the record as a definitive account of intent or time spent.
02 / Section
Separate the record from the interpretation
Every review should label three different things. Recorded evidence is what the captured material shows. Interpretation is the explanation a reviewer gives that evidence—for example, that a handoff or lookup may be a repeated part of the workflow. Planning assumptions are choices about a possible future design, such as which system would become the source of truth or when a person would approve an exception.
This separation makes disagreement useful. A colleague may accept the recorded sequence but reject the interpretation, or agree with the interpretation while questioning an assumption about policy. Those distinctions are harder to maintain when observations and recommendations are written as one conclusion.
- Recorded evidence: what the batch contains and where it came from.
- Interpretation: the workflow pattern the evidence may indicate.
- Planning assumption: a condition that must be confirmed before designing a change.
03 / Section
Compare attempts, but keep discovery signals in their place
Compare distinct attempts at the same or similar outcome. Recurring handoffs, lookups, duplicate entry, or review steps can reveal a workflow pattern worth examining. Differences matter too: they may indicate different request types, policies, exceptions, or outcomes rather than inconsistency that should be removed.
App and site sequences can help with discovery, but they are not by themselves a workflow definition or proof of business purpose. Use them to locate questions for review, then connect those questions to the recorded outcome and supporting evidence. Do not infer verified working time, effort, or performance from sequence alone.
04 / Section
Make assumptions visible before choosing automation
Before proposing a change, write down the conditions it depends on. These might include stable input formats, permission to use a particular system, an agreed exception path, a required approval, or a rule for handling missing information. Mark each condition as confirmed, open, or proposed. An open assumption is a review task, not a hidden detail of the design.
Then present the smallest credible next step. It may be a policy clarification, a controlled trial, a template change, or a human-reviewed handoff. The evidence can inform that choice, but it cannot establish automatic execution, savings, or a safe replacement for judgment.
05 / Section
Leave the decision with the accountable person
An operations leader should decide whether the proposed change fits the process, policy, risk tolerance, and customer obligation. The decision should record what evidence was considered, which interpretations were accepted, which assumptions remain open, and what human review is required.
This creates a durable review record without treating captured work as a scorecard. It also keeps automation review grounded: evidence supports a question, comparison clarifies a pattern, assumptions define the proposal, and a person decides whether the next step is justified.