Start with a problem someone already complains about
A first workflow should be a process that a named person already wants fixed. Not the most technically interesting one, and not the one with the cleanest data. If nobody is currently frustrated by the process, nobody will adopt the replacement.
Consider a fictional example: a finance team of four receives roughly 600 supplier invoices a month. Two of them spend part of every day matching invoices to purchase orders and receipts, and chasing the differences by email. The team can describe the problem in one sentence, which is a good sign that it is well bounded.
Confirm ownership before design
Every workflow needs an owner who can approve a change to how the work is done. If the process crosses three departments and no one can decide, the project will stall at exactly the point where the design becomes real.
Ownership also determines review. In the invoice example, the controller owns the exception threshold and the delegated approval limits. Those are business decisions, and the architecture simply enforces them.
Measure the baseline before you change anything
You cannot claim an improvement without a before. Spend a short period recording what actually happens: how many invoices match on the first pass, how long an exception waits, how often an item is re-keyed, how much of the month-end delay comes from this queue.
A baseline is also a feasibility test. If the numbers are hard to collect, the underlying systems may not expose enough information for a workflow to run against them either.
Test feasibility against the sources, not the demo
Feasibility lives in the sources. Does the accounting system expose the purchase order through an approved interface, or only through a nightly export? Does the receipt exist in a system at all, or in a photograph attached to an email? Update frequency follows what a source actually provides.
This is also where build-versus-buy is decided. If the existing platform already performs three-way matching and simply is not configured, the correct recommendation is configuration, not construction.
Define review before you define automation
Decide what the system may do on its own and what it must hand to a person. In the invoice example, a clean three-way match within tolerance can be routed for approval automatically. A price variance above the threshold cannot. Payment is never released autonomously.
Review paths should be written down as part of the acceptance criteria, alongside the abstention behaviour: what the system does when it is not confident enough to answer.
Set the expansion gate in advance
Before the first workflow goes live, agree what result would justify expanding it, what would justify changing it, and what would justify retiring it. Writing this down in advance prevents a familiar outcome, where a pilot is judged a success because it was expensive.
One workflow, one owner, one baseline, one gate. That sequence is unglamorous, and it is the difference between a system that becomes part of the operation and one that becomes a demonstration nobody opens.