{"course":{"slug":"agents-and-automation","title":"Agents and Automation","url":"https://addaly.com/learn/agents-and-automation","level":"intermediate","track":"build"},"lesson":{"slug":"mapping-the-process-first","title":"Watch the process before you automate it","url":"https://addaly.com/learn/agents-and-automation/mapping-the-process-first","position":3,"of":72,"minutes":9,"answer":"The process on paper is not the one that runs, and the ceiling on any automation is the share of elapsed time held by the steps it actually replaces.","keyIdea":"The process on paper is not the one that runs, and the ceiling on any automation is the share of elapsed time held by the steps it actually replaces."},"body":{"format":"markdown","text":"## Two versions of every process\n\nThere is the process as written down and the process as performed, and they are never the same document. A thirty-person firm in Coimbatore had a written invoice procedure with six steps. Sitting beside the person who ran it for one morning produced nineteen distinct actions, including a WhatsApp thread to ask which cost centre a delivery belonged to, and a spreadsheet that appeared in no procedure and no system diagram but decided which invoices were paid that week.\n\nThis is not dishonesty. When you ask somebody to describe their work, they narrate the version they were trained on. The exceptions are handled by habit, and habit is not available to recall the way a rule is: you cannot describe a decision you no longer notice making. People also compress: \"then I check it\" hides four separate checks against three systems, and it is the third check that fails twice a month.\n\nSo the first hour of any automation project is spent watching, not designing.\n\n## Shadow one real run\n\nSit with the person and do not interview them. Watch, and write timestamps. If they are remote, ask them to record their screen: OBS Studio is free on every platform and does this without an account. Interview afterwards, with the recording open, and ask about the moments where they paused.\n\nRecord six things for each step:\n\n1. What arrives, and from where.\n2. What decision is made, and on what evidence.\n3. What leaves, and to which system.\n4. How long it takes.\n5. How often it happens.\n6. What happens when it goes wrong, and who notices.\n\nCount the exceptions separately from the normal cases. This is the number most projects never collect and the one that decides whether the project is worth doing.\n\n## The exception rate decides everything\n\nSuppose 200 invoices a week, four minutes each: 800 minutes of work. You automate the clean path. If 30 per cent of invoices need a phone call (a missing PO number, a supplier who changed bank details, a delivery that arrived short) then the person is still present, still context-switching, and now picking up cases that are half-finished by a machine, which is harder than picking up cases nobody has touched.\n\nDo the arithmetic before you build. One hundred and forty clean invoices at two and a half minutes of automatable work is 350 minutes. Add fifteen minutes a day of reviewing what the automation did, which is 75 minutes a week. The honest saving is around 275 minutes, not 800. That is still a good result. It is a third of what the project will be sold as.\n\n## The ceiling is the share of time you replace\n\nElapsed time in real office processes is mostly waiting. Waiting for an approval to be read, waiting for someone's inbox, waiting for the overnight batch, waiting for the person who knows the answer to come back from lunch. If the step you are automating holds 15 per cent of the total time, then 15 per cent is the best result available to you, and the model's cleverness cannot change that arithmetic.\n\nThis is worth saying out loud in the first meeting, because it usually redirects the project. Removing a queue is often worth more than adding a model. Letting two approvers instead of one sign off under a threshold, or moving the trigger from a nightly batch to the moment the file lands, can beat any amount of language modelling and takes an afternoon.\n\n## What the map should contain\n\nOne page. The trigger. The steps, with who does each. The decision points and what they depend on. The systems touched, with the account used. The exception paths, and how often each one fires. The volume. The current cost in hours. And the name of the person who currently notices when the whole thing has stopped.\n\nThe last line matters most. If nobody currently notices, your automation will fail silently too, and you have just learned the most important requirement.\n\n## Where people get stuck\n\nThey map the ideal process. The fix is to map a specific week that has already happened, using real cases pulled from the system, including the two that went wrong, not a hypothetical case built from the procedure.\n\nThey also map their own job. Frequently the value is one step upstream: half the exceptions come from a form that lets people type a date in free text. Fixing the form removes the work rather than automating it, which is cheaper and permanent.\n\n## The limitation\n\nA map is a snapshot. Processes drift (a supplier changes their invoice layout, a team reorganises, a system is replaced) and a diagram of boxes is stale within months. That is why the map should carry numbers you can re-measure: volume, exception rate, minutes per case. Boxes rot quietly. Numbers can be taken again in six months and compared, and the comparison tells you whether the thing you built is still pointed at the work that exists."},"check":{"question":"A finance team spends about 800 minutes a week on invoice processing. Watching them shows that 60 per cent of the elapsed time is waiting for a manager to approve by email, and the data-entry step they want automated holds about 15 per cent. What does that tell you before any tool is chosen?","options":[{"text":"The automation has a ceiling of roughly 15 per cent, so the approval queue is the larger target and may not need a model at all.","correct":true},{"text":"A faster model will shorten the waiting too, because the whole process moves through more quickly.","correct":false,"tempting":"Assumes the queue is limited by upstream throughput, when the delay is a person’s attention and unchanged by anything arriving sooner."},{"text":"The 60 per cent is idle time, so the real saving is the 15 per cent plus most of the wait that disappears with it.","correct":false,"tempting":"Counts waiting as work being replaced; the manager still has to read and decide, so that time does not vanish when the typing does."},{"text":"Data entry is the only mechanical step, so it is the correct place to start whatever share of time it holds.","correct":false,"tempting":"Chooses the step that is easiest to automate rather than the one that holds the time, which is how projects deliver a tenth of what was promised."}]},"prev":{"slug":"automation-before-agents","title":"The boring stack that already does this","url":"https://addaly.com/learn/agents-and-automation/automation-before-agents"},"next":{"slug":"what-work-is-automatable","title":"Which work is worth automating","url":"https://addaly.com/learn/agents-and-automation/what-work-is-automatable"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Watch the process before you automate it', in Agents and Automation. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/agents-and-automation/mapping-the-process-first (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Watch the process before you automate it","courseTitle":"Agents and Automation","module":{"index":1,"slug":"deciding-what-to-build","title":"Before you build: script, workflow, or agent"},"answer":null,"keyIdea":"The process on paper is not the one that runs, and the ceiling on any automation is the share of elapsed time held by the steps it actually replaces.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"two-versions-of-every-process","runs":[{"text":"Two versions of every process"}]},{"t":"p","runs":[{"text":"There is the process as written down and the process as performed, and they are never the same document. A thirty-person firm in Coimbatore had a written invoice procedure with six steps. Sitting beside the person who ran it for one morning produced nineteen distinct actions, including a WhatsApp thread to ask which cost centre a delivery belonged to, and a spreadsheet that appeared in no procedure and no system diagram but decided which invoices were paid that week."}]},{"t":"p","runs":[{"text":"This is not dishonesty. When you ask somebody to describe their work, they narrate the version they were trained on. The exceptions are handled by habit, and habit is not available to recall the way a rule is: you cannot describe a decision you no longer notice making. People also compress: “then I check it” hides four separate checks against three systems, and it is the third check that fails twice a month."}]},{"t":"p","runs":[{"text":"So the first hour of any automation project is spent watching, not designing."}]},{"t":"h2","id":"shadow-one-real-run","runs":[{"text":"Shadow one real run"}]},{"t":"p","runs":[{"text":"Sit with the person and do not interview them. Watch, and write timestamps. If they are remote, ask them to record their screen: OBS Studio is free on every platform and does this without an account. Interview afterwards, with the recording open, and ask about the moments where they paused."}]},{"t":"p","runs":[{"text":"Record six things for each step:"}]},{"t":"ol","start":1,"items":[[{"text":"What arrives, and from where."}],[{"text":"What decision is made, and on what evidence."}],[{"text":"What leaves, and to which system."}],[{"text":"How long it takes."}],[{"text":"How often it happens."}],[{"text":"What happens when it goes wrong, and who notices."}]]},{"t":"p","runs":[{"text":"Count the exceptions separately from the normal cases. This is the number most projects never collect and the one that decides whether the project is worth doing."}]},{"t":"h2","id":"the-exception-rate-decides-everything","runs":[{"text":"The exception rate decides everything"}]},{"t":"p","runs":[{"text":"Suppose 200 invoices a week, four minutes each: 800 minutes of work. You automate the clean path. If 30 per cent of invoices need a phone call (a missing PO number, a supplier who changed bank details, a delivery that arrived short) then the person is still present, still context-switching, and now picking up cases that are half-finished by a machine, which is harder than picking up cases nobody has touched."}]},{"t":"p","runs":[{"text":"Do the arithmetic before you build. One hundred and forty clean invoices at two and a half minutes of automatable work is 350 minutes. Add fifteen minutes a day of reviewing what the automation did, which is 75 minutes a week. The honest saving is around 275 minutes, not 800. That is still a good result. It is a third of what the project will be sold as."}]},{"t":"h2","id":"the-ceiling-is-the-share-of-time-you-replace","runs":[{"text":"The ceiling is the share of time you replace"}]},{"t":"p","runs":[{"text":"Elapsed time in real office processes is mostly waiting. Waiting for an approval to be read, waiting for someone’s inbox, waiting for the overnight batch, waiting for the person who knows the answer to come back from lunch. If the step you are automating holds 15 per cent of the total time, then 15 per cent is the best result available to you, and the model’s cleverness cannot change that arithmetic."}]},{"t":"p","runs":[{"text":"This is worth saying out loud in the first meeting, because it usually redirects the project. Removing a queue is often worth more than adding a model. Letting two approvers instead of one sign off under a threshold, or moving the trigger from a nightly batch to the moment the file lands, can beat any amount of language modelling and takes an afternoon."}]},{"t":"h2","id":"what-the-map-should-contain","runs":[{"text":"What the map should contain"}]},{"t":"p","runs":[{"text":"One page. The trigger. The steps, with who does each. The decision points and what they depend on. The systems touched, with the account used. The exception paths, and how often each one fires. The volume. The current cost in hours. And the name of the person who currently notices when the whole thing has stopped."}]},{"t":"p","runs":[{"text":"The last line matters most. If nobody currently notices, your automation will fail silently too, and you have just learned the most important requirement."}]},{"t":"h2","id":"where-people-get-stuck","runs":[{"text":"Where people get stuck"}]},{"t":"p","runs":[{"text":"They map the ideal process. The fix is to map a specific week that has already happened, using real cases pulled from the system, including the two that went wrong, not a hypothetical case built from the procedure."}]},{"t":"p","runs":[{"text":"They also map their own job. Frequently the value is one step upstream: half the exceptions come from a form that lets people type a date in free text. Fixing the form removes the work rather than automating it, which is cheaper and permanent."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"A map is a snapshot. Processes drift (a supplier changes their invoice layout, a team reorganises, a system is replaced) and a diagram of boxes is stale within months. That is why the map should carry numbers you can re-measure: volume, exception rate, minutes per case. Boxes rot quietly. Numbers can be taken again in six months and compared, and the comparison tells you whether the thing you built is still pointed at the work that exists."}]}],"check":{"question":[{"text":"A finance team spends about 800 minutes a week on invoice processing. Watching them shows that 60 per cent of the elapsed time is waiting for a manager to approve by email, and the data-entry step they want automated holds about 15 per cent. What does that tell you before any tool is chosen?"}],"options":[{"text":[{"text":"The automation has a ceiling of roughly 15 per cent, so the approval queue is the larger target and may not need a model at all."}],"correct":true,"tempting":null},{"text":[{"text":"A faster model will shorten the waiting too, because the whole process moves through more quickly."}],"correct":false,"tempting":[{"text":"Assumes the queue is limited by upstream throughput, when the delay is a person’s attention and unchanged by anything arriving sooner."}]},{"text":[{"text":"The 60 per cent is idle time, so the real saving is the 15 per cent plus most of the wait that disappears with it."}],"correct":false,"tempting":[{"text":"Counts waiting as work being replaced; the manager still has to read and decide, so that time does not vanish when the typing does."}]},{"text":[{"text":"Data entry is the only mechanical step, so it is the correct place to start whatever share of time it holds."}],"correct":false,"tempting":[{"text":"Chooses the step that is easiest to automate rather than the one that holds the time, which is how projects deliver a tenth of what was promised."}]}],"order":[3,1,0,2],"why":null},"prev":{"slug":"automation-before-agents","title":"The boring stack that already does this","minutes":8},"next":{"slug":"what-work-is-automatable","title":"Which work is worth automating","minutes":8}}}