What a one-week workflow study should produce
A workflow study is not a discovery call. It is a working week spent beside the people who do the job, and it should end with artifacts a team can build against.
Observe before building
Process documents are useful, but they rarely contain every handoff, exception, shortcut, or judgment call. We follow real examples with the people doing the job and record what actually happens, including the parts nobody writes down.
What the week produces
- A workflow map: the trigger, the steps, the owners, the systems, and the decisions.
- A baseline: what the current process costs in time, delay, rework, or error.
- A constraint list: access, data quality, policy, and integration limits.
- A risk note, including which parts should stay manual for now.
- A recommended first deployment, narrow enough to build and evaluate.
What to look for while observing
Where information is re-entered, re-derived, or copied between systems.
- Where work waits on a person who is not blocked by anything except attention.
- Which exceptions are rare, and which are quietly the normal path.
- Which judgments the operator would never want a system to make for them.
“If the study cannot produce a baseline, the workflow is not ready to be changed yet. That is a useful outcome too.”
Conclusion
A week is enough to replace assumptions with examples. The output should be specific enough that an engineer can start building on Monday, and honest enough to say which parts of the job should stay with a person.
