When a team says “we need to automate this,” the word “this” often hides several different problems. One person wants fewer spreadsheets, another wants faster approvals, and a manager wants a report that can be trusted. Building immediately can produce a technically successful tool that solves only one interpretation of the request.
Process discovery makes the intended change concrete. It connects the customer's outcome to the work, decisions and information needed to achieve it, so an automation project begins with a shared problem rather than a favourite feature.
Choose a transaction you can follow
Start with a specific journey, such as an enquiry becoming a quotation or an accepted order becoming a completed delivery. Define where it begins and ends. “Improve operations” is too broad to observe, while “reduce the waiting between an accepted quote and a scheduled job” provides a clear route through the business.
Select several examples, including a normal case and a difficult one. Remove sensitive details before sharing them beyond the people who need access. Follow the actual records, messages and decisions. A procedure document is useful background, but it may describe the intended process rather than what happens when the team is under pressure.
Observe work where it happens
Ask people to show how they complete the task, including the notes, reminders and informal checks that make it possible. Avoid treating workarounds as evidence of poor performance. They often reveal missing information or a system that does not support a legitimate business need.
For an illustrative supplier, an employee might maintain a private list of orders that need special packaging. The important question is why that information does not travel with the order. Removing the list without replacing its function would make the process look cleaner while increasing delivery errors. Discovery should expose the value hidden in the workaround before changing it.
Separate activities, decisions and waiting
Draw the steps in ordinary language and mark who owns each one. Distinguish doing work from deciding whether work can proceed. Approving a discount is different from sending an approval notification; the second can be automated without resolving the first.
Record where cases wait and why. A task may take minutes but depend on a decision that arrives days later. Note whether the delay comes from missing information, availability, unclear authority or an external dependency. These differences matter when choosing a solution and estimating the improvement it could realistically produce.
Establish where important facts come from
For each decision, identify the information used and its authoritative source. If staff compare two spreadsheets before confirming availability, ask which one should be trusted and why they disagree. The automation needs a rule for conflicting data, not merely faster access to both versions.
Microsoft's process-focused implementation guidance and automation planning material provide useful structures for this analysis. The practical output should remain understandable to business participants: a map of the journey, the facts used at each decision and the unresolved questions that could change the design. A diagram full of technical components is not a substitute for those agreements.
Include exceptions before choosing the first scope
List common variations such as missing information, cancellation, a changed quantity and an absent approver. Estimate their frequency from records where possible, rather than relying only on memorable incidents. A rare but consequential exception may still deserve explicit handling even if it is not fully automated in the first release.
Decide which cases the first version will handle automatically and which will remain a visible manual route. Give that route an owner and preserve the context needed to act. “Handle manually” is an incomplete design if nobody knows where those cases appear or how they return to the normal process.
Turn findings into a testable improvement
Write a short statement of the current problem, the proposed behaviour and the evidence that would demonstrate improvement. For example: accepted jobs currently wait because site information is incomplete; the new process checks required information before handover and routes omissions to the right person.
Agree the baseline, the pilot group and the conditions that would require a change of plan. Keep solution options open until the important constraints are understood. Configuration, an integration, a small application or a broader ERP change may each be appropriate depending on what discovery reveals.
Keep discovery useful and proportionate
Discovery does not need to become an endless programme of meetings. Time-box an initial investigation around one journey, collect real examples and return with decisions the business can review. If uncertainty remains, state what must be learned next and how that knowledge affects the proposed scope.
Worktechlabs can help turn operational frustrations into a concrete automation or integration project. Share a process that repeatedly causes delays or duplicate work. We can map it with the people involved and identify a first change whose value can be assessed through actual customer and team outcomes.
Official sources and further reading
