At Wildchild, we propose beginning with six questions.
1. What is one unit of work?
“Improve customer service” is a business ambition. “Resolve a delivery-status enquiry” is a workflow candidate.
Name the trigger, the case and the finish line. For an order-intake workflow, the trigger might be a purchase order arriving in an inbox. Completion might require an authorized order in the ERP with a confirmed reference.
This definition determines what you can measure. If a draft response counts as success in one report and a resolved request counts as success in another, the team cannot make a useful comparison.
2. Who owns the result?
A workflow needs someone who can explain the process, judge the outcome and decide what to do with an exception. It also needs access to the people who perform the work.
Identify the process owner before treating the idea as a deployment candidate. A senior sponsor can support the project, but everyday decisions still need a responsible role.
3. What happens today?
Walk through ordinary cases and the ones that take too long. Record the information people gather, the decisions they make and the systems they change.
Separate handling time from elapsed time. A case may need a few minutes of work and wait several days for an answer. Those are different problems and may require different changes.
Capture quality, rework and unresolved work alongside volume. If the baseline is an estimate, label it. Plan how to replace it with observed evidence.
4. Can the workflow get the information and authority it needs?
List the sources and their owners. Check whether the records are sufficiently current, whether different sources disagree and whether the intended users may access them.
Then list the actions. Reading a record, proposing an update and committing that update are separate permissions. Define the review required for each consequential action.
An attractive business case cannot remove an unresolved access or authority dependency.
5. What should happen when the usual route fails?
Choose a typical exception early. An ambiguous product code is a useful example: the workflow needs to know when to stop guessing, what evidence to show and who can decide.
Also consider an unavailable system and an action whose outcome is uncertain. The route back to a reliable state belongs in the scope.
6. Is the complete effort worth it?
Compare the expected benefit with implementation, review, rework, maintenance and usage costs. Include the effort that moves to new roles.
A smaller process change or existing tool may solve the problem well. The recommendation should follow the workflow's needs and economics.
A practical selection example
In our fictional distributor diagnostic, three ideas enter the shortlist: order intake, order-status enquiries and invoice discrepancies.
Order intake has a known owner and a visible finish line, but requires product-reference rules and an ERP interface check. Status enquiries depend on a fragmented delivery-status source. Invoice discrepancies require additional finance authority and evidence.
The recommendation is to investigate a bounded order-intake scope first. It is conditional on those dependencies, rather than a declaration that the highest-volume task must win.
Your first-workflow brief
Write down the recurring task, trigger, accepted outcome, owner, volume and period, observed effort, sources, permitted actions, typical exception and intended improvement. Mark every unknown.
The next step should follow the most important unresolved question: measure the work, confirm access, identify the owner or discuss a bounded scope.
Use the workflow worksheet
See the completed diagnostic
Discuss your first workflow