01 / Section
Start with the outcome, not the number of repetitions
A sequence that appears several times is not automatically a meaningful pattern. First identify the business outcome each attempt was trying to produce: resolving a customer issue, preparing a review, updating a record, or handing work to another team.
Then check whether the attempts were comparable. Similar clicks or pages can support different outcomes, while different routes can produce the same outcome. The useful pattern is the recurring relationship between intent, steps, and result—not repetition alone.
- Name the intended outcome for each attempt.
- Record whether the outcome was completed, abandoned, or unclear.
- Do not combine attempts merely because they use the same applications or sites.
02 / Section
Compare distinct attempts side by side
A pattern should survive comparison across separate attempts, not just within one captured batch. Review each attempt as its own piece of evidence and note which steps recur, which vary, and where the work branches.
Look for stable parts of the workflow and legitimate variation. A repeated review step may be a dependable practice. A repeated detour may instead reflect an exception, a missing input, or a temporary constraint.
- Separate attempts by task, date, or business case when that distinction is available.
- Mark recurring steps, optional steps, and one-off steps.
- Treat variation as information rather than noise.
03 / Section
Keep discovery signals separate from recorded evidence
App and site sequences can help reveal where to investigate. They are discovery signals, not proof of what someone intended or what a step accomplished. A visit to a system may indicate that a task was being explored, but it does not establish the business result.
Recorded evidence should remain distinct from interpretation. A citation shows where an observation came from; it does not make the observation complete, correct, or certain. State what was captured, then state what it may suggest.
- Label app or site sequences as signals for further review.
- Link claims to the relevant captured evidence without overstating the citation.
- Use cautious language such as “recurs in the reviewed attempts” or “may indicate,” where appropriate.
04 / Section
Check the context before generalizing
Repeated work may reflect a specific customer type, approval rule, region, system state, or reporting period. Without that context, a local habit can be mistaken for a team-wide workflow.
Ask what conditions were present in every attempt and which were different. This helps distinguish a broadly recurring pattern from a response to one temporary situation.
- Note the case, customer, system, and policy conditions that shaped each attempt.
- Check whether the sample includes different people, teams, or operating contexts when that is relevant and available.
- Avoid extending a finding beyond the attempts and context actually reviewed.
05 / Section
Turn a verified pattern into a testable plan
Once a pattern has been verified, describe it plainly and define what should be examined next. The next step might be confirming the workflow with practitioners, checking whether a rule still applies, or testing a small process change.
Keep planning assumptions visibly separate from evidence. A proposed simplification is not proof that work can be removed, and a possible improvement is not a measured saving. Treat the plan as a question to validate.
- Write the pattern as an evidence-linked observation.
- List the assumptions that would need confirmation before changing the workflow.
- Choose a review or experiment that could support, refine, or reject the interpretation.