How to map a process before you automate it

Direct answer

Before automating anything, write down how the process actually works today: the trigger, the steps in order, who does each, the decisions and the rules behind them, what goes wrong and what data moves where. Automation makes a process faster and more consistent; it does not make an undecided process decided. If two people do the same task in two different ways, the first job is to agree one way.

This page gives a method you can complete with a pen or a spreadsheet, no special software. It makes no promise about what any automation will achieve; that depends on the process, the systems involved and how they connect. Where systems need to be connected, that is scoped per project and depends on what each system exposes.

Choose one process

Map one process, not the whole business. A good first candidate is repetitive, follows rules most of the time, touches more than one system or person, and has an owner who can decide how it should work. Poor candidates are processes that change weekly, depend entirely on individual judgement or have no owner.

Write the process name and a single sentence for its start and end: from what event to what result. If you cannot state those two, the boundaries are not yet clear enough to map. The free automation opportunity finder can help you compare candidates before you commit.

Steps: write what happens, not what should happen

Ask the people who do the work to walk you through a real recent case, and follow the actual trail: emails, files, systems, messages. Write each step as a short action with a verb: receive the request, check the customer record, enter the order, send the confirmation. Include the waits, such as waiting for an approval or waiting for a file, because delays are often where the cost sits.

• Start from the trigger: what event starts the process and where it first appears
• Number steps in the order they truly happen, including the workarounds
• Mark each step as manual, done in a system, or automatic already
• Note where a step is repeated, redone or sent back
• Stop when the defined end result exists

Owners

For each step, write who does it, by role rather than by name if the person changes. Then name one owner of the whole process: the person who can decide to change a rule and who is accountable when it fails. Automation without an owner drifts. Nobody notices when a rule becomes wrong, and nobody is told when it fails.

Decisions and rules

Decisions are where most automation projects meet reality. For each point where the process branches, write the question, the possible answers and the rule that picks one. Be specific: not urgent customers get priority, but which customers, by what field.

• Rules that can be written as if-then statements are candidates for automation
• Judgement calls that a person makes on feel should stay with a person, at least at first
• Where the rule is unknown, mark it as a question to settle before building, not a detail to guess
• Where a rule has an owner's approval limit, write the limit and who approves above it

Exceptions

List what goes wrong: missing information, duplicates, a customer not found, an approval that never comes, a system that is unavailable. For each, write what a person does today and who they tell. Exceptions are not an afterthought. A builder who does not know them will build only the smooth path, and the first real failure will land on someone with no instructions. For the design side of this, see workflow exception and escalation design.

Data

For each step, note what information it reads and what it writes, and where each item lives: a form, an inbox, a spreadsheet, a named system. Mark which fields are mandatory, which are often wrong or missing and which system is the master when two disagree. Write down how you can get access to each system, and whether it offers an API or an export. Whether an integration is possible is settled per project by looking at what each system actually offers, and it should be checked early because it decides the shape of the build.

Measures

Before changing anything, record how the process performs now, in your own terms: how often it runs, how long a case takes from trigger to end, how many need rework and how many exceptions occur. Use a small sample of real cases if you have no records. These become your baseline. Without one, nobody can say afterwards whether the automation helped. No outcome is promised on this page; the baseline is how you check for yourself. A related exercise is manual reporting automation, where the baseline is the time spent building reports.

Handing the map to a builder

Package the map as a short brief: the process name and boundaries, the numbered steps with owners, the decision rules, the exception list, the data and systems with access notes, the baseline measures and two or three real example cases, including one messy one. Mark clearly what is decided and what is still open. A builder can quote and design against that far more accurately than against a description like automate our onboarding.

If you want an outside view, workflow automation and systems integration describes how LATYNEX scopes this kind of work. Sometimes mapping shows the process should be simplified rather than automated, and we would say so.