01 / 03

Watch a real example

Ask someone to show you the last time they completed the task. Keep the actual files and messages open. A description of the official process often misses the small steps that make it work.

Notice where they pause. Maybe a supplier code needs translating, a cost needs checking or an approval lives in a message thread. Those details belong in the design.

Ask which parts they would remove if they could. A report nobody reads does not become more useful when it runs automatically.

02 / 03

Separate ordinary work from exceptions

Write down the conditions for a straightforward case. What information must be present? What needs to agree? What is the system allowed to change?

Then list the reasons to stop and ask a person. Missing stock, an unexpected price or conflicting dates should arrive with enough context for someone to decide. A queue full of vague warnings simply moves the manual work to another screen.

Make repeated runs safe. If an order has already been processed, running the job again should not create another one. Keep a record of what happened, and make it possible to retry a failed item without repeating everything else.

03 / 03

Run alongside the team first

For a short period, let the system produce a proposed result while the existing process remains in place. Compare the two. Keep a list of the differences and settle why each happened.

Once the ordinary cases are dependable, allow a limited set to run automatically. Give the team a clear stop switch and someone to contact when the work behaves differently from what was agreed.

The handover matters as much as the first successful run. Leave the rules, the checks and the ownership in a form the team can use. A useful automation should survive the person who built it taking a holiday.