What stalls an automation conversation most often is not the tool but the process being unwritten. The work runs, yet how it runs sits on nobody paper. This lesson covers writing the task you chose down end to end, and testing what you wrote.
In the first lesson you picked the task to start with. This lesson deals with writing that task down. The process map is the draft of the automation and the record of how the work runs today; it is also the document you hand over when you sit down to a build conversation.
Writing it down does not look hard, yet most businesses get stuck here. The reason is not writing skill: the process lives in someone head, and while the steps are being described the sentence it depends turns up and everything stops there. This lesson also covers how to open that sentence.
Prerequisite: the task inventory and the pilot task from lesson one. If you do not have them, do that lesson first; this one is built on its output.
An unwritten process is not absent, it is only invisible. The work runs, because the person running it knows what to do. The trouble shows when that person takes leave, moves on, or the work gets split between two people.
The second cost of an invisible process turns up during automation. When the process described to the builder differs from the one actually running, the system that gets built automates the described work rather than the real work. The gap shows at the first exception.
A map is made of six headings. You met five of them in the first lesson; one more joins here: role and timing. Once the six are filled, the process counts as written.
Where the work starts and where it ends. Without a starting event and a finishing measure the scope of the map stays vague and the conversation keeps widening.
The work done in order. Each step has a subject, an action and an output. A step with no output is usually not a step but a habit.
Where the road forks. At each fork you write which measure is looked at and where each way leads. Without the measure the decision stays with the person.
Which information comes from where and gets written where. This heading is the input of the third lesson, so write field names as plainly as you can.
What happens when the expected way does not run. Where the record waits, who takes over, how the work closes. An unwritten exception stops the automation quietly.
Who does it, when, and how long it can wait. If two people do the same step, both get written; the order and the waiting limit are part of the map too.
Start the map from the boundary rather than from the steps. When where the work starts and ends goes unwritten, the conversation keeps widening: a quote process turns into collection, then into accounting, and the map does not finish.
The boundary is drawn in two sentences. The start is an event, not an intention: it starts when the customer submits the form, not when we feel like looking after the customer. The finish is a measure: it ends when the quote went out and got written into the record, not when the customer is happy.
Keep the boundary narrow. A wide map stays unwritten; a narrow map gets written, gets built and then widens. The pilot measure from the first lesson holds here too.
While writing the steps, hold to one pattern: who, what they do, what comes out. This pattern makes both the missing subject and the output free step visible. In the sentence the record gets checked, who checks it and what comes out of the check stay unclear; that is not a step but a wish.
Rather than taking notes while the steps are described, have the person do the work once end to end and watch. The gap between the described process and the performed one usually becomes visible right here.
Each step opens with who it is: the sales advisor, accounting, the system. Without a subject the step is left ownerless during a handover.
One step holds one action. Opens the record and calls the customer is two steps; unsplit, when the first happens and the second is forgotten, nobody notices.
What came into being at the end of the step gets written: an opened record, a sent message, an updated field. The output is the input of the next step.
Number the steps and leave the numbers alone afterwards. When a step gets inserted during a conversation, give it an in between number; that way everyone on the team talks about the same step.
A decision point is where the road forks, and it is the most skipped part of a map. When the steps get written as a flat sequence the process looks like it works on paper; in real life it branches at the first different case.
At each decision point three things get written: what is being looked at, by which measure it splits, and where each way goes. With all three written the decision stays in the process; with one missing the decision returns to the person and the automation hesitates at that point.
The field or the information the decision rests on. Amount, district, customer type, whether a document is there. If what is looked at is a field, write its name as well.
The rule of the split. A large customer is not a measure; a customer with an annual contract is. Once the measure is written the decision becomes repeatable.
Each option ties to a step. An option that ties to nothing falls to the exception; that gets written too. A way left open means a record dropping quietly in the system.
Exceptions do not come out by themselves during a conversation; they come out when asked. The person doing the work describes the normal flow, because for them the exceptions have become ordinary.
The most practical way to catch them is repeating one question at the end of every step: what could go wrong here? Asked at each step, the exceptions come out one by one and the map moves closer to reality.
Write exceptions beside the step they belong to rather than in a separate list. Exceptions kept in a separate list get missed during the build, because the person building the flow moves step by step.
Every step on the map works with some information. In this step you mark that information: which field comes from where, gets written where, gets read at which step. This marking becomes the direct input of the third lesson.
Write field names as they are, not as you interpret them. If the form says contact, the map says contact; if you write phone instead, a matching gap opens between two names during the build.
The last item matters. When what the flow should do with an empty mandatory field goes unwritten, the system usually skips the step quietly. That is the source of the silent fault you meet in a later lesson.
A map stays half done without who and when. Without a step owner the work is left ownerless at handover; without a waiting limit a late piece of work goes unnoticed, because no measure says what counts as late.
Write timing as a waiting limit rather than a promise of speed: if no reply comes, a reminder goes out. That wording says the same thing to the team and to the system that will be built.
A map does not get used before it is tested. The method is simple and it is called the handover test: give the map to someone who does not know the process and ask them to do the work end to end. Every question they ask points at a gap in the map.
During the test do not answer, take notes. When you answer, the gap looks closed but the map stays incomplete. Once the questions run out, the map has reached the maturity where it can carry the work when someone steps into your place.
A map that passes the test can enter a build conversation. One that does not points at a process needing tidying rather than automating.
This sentence is where a map gets stuck most often, and it is usually not a gap in knowledge but a gap in naming. The person doing the work recognises the cases but has not named them, which is why they cannot describe them.
The way to open the sentence is asking for concrete examples rather than asking in the abstract. The question in which cases does it change usually gets no answer; the question what did you do on the last three jobs brings the cases out one by one.
Let us work the method through a single process from end to end. The example runs on the quote process of a service business; the steps work independently of the sector.
Boundary: the process starts when the customer sends the quote form from the site. It ends when the quote reaches the customer and is written into the record. Collection sits outside this map.
Steps: the advisor opens the record, the output is an opened request record. The advisor reads the request and sets the scope, the output is a scope note. The advisor calculates the amount from the price table, the output is a quote amount. The advisor prepares and sends the quote, the output is a sent quote. The advisor updates the record, the output is a written record.
Decision points: while the scope is set, whether the request fits the standard service is looked at. The measure is whether it has a match in the service list. If it fits, the amount comes from the price table; if not, the technical team is asked and the process carries on from there.
Exceptions: if the form arrives incomplete, the advisor sends a missing information message and the record waits. If the technical team does not reply, the record falls to the manager pool. If a second form arrives from the same customer, the first record gets updated and no new record opens.
Data: the fields from the form are name, phone, district, service heading and description. Phone is mandatory and the flow stops when it arrives empty. The quote amount is produced by calculation and written into the record.
Role and timing: the owner of every step is the advisor of the relevant district, with the office supervisor as backup. A request is read the day it arrives; if no reply goes out, a reminder follows the next day.
Handover test: the map goes to an employee from accounting. They ask three questions: where the price table is, how the technical team is asked, and which record gets updated when a second form arrives. All three go into the map and the test is repeated.
The return of this lesson comes from drawing the map of the pilot task you chose in the first lesson. One sitting and one handover test are enough.
The map that comes out becomes the input of the third lesson. The field dictionary there is built from the fields you marked on this map.
A map written before the boundary is drawn keeps growing without reaching an end. The conversation slides into neighbouring processes and no usable document is left in hand.
Sentences with no subject and no output, such as the record gets checked, are not steps. During the build those lines turn into questions and the process gets discussed again.
A process written as a flat sequence works on paper and branches in the field. A branch left unwritten comes back as an exception after the build.
Gathering all exceptions at the very end leads to them being missed during the build. An exception belongs beside the step it comes from.
When you write a field in your own words on the map, a matching gap opens during the build. Whatever the name in the system is, that is what gets written.
An untested map describes the process inside the head of whoever wrote it. The gaps become visible only through the questions of someone who does not know the process.
Before the map enters a build conversation, you want to be able to say yes to every item below. Where an item is missing, the map is not ready yet.
The terms that come up in map conversations. Once the team shares this language, process arguments get shorter.
In this lesson you drew the map of your pilot task and tested it with a handover test. The fields you marked on the map become the direct input of the next lesson: which fields customer data gets collected with, how they get written and where they live.
If you want to go back to the first lesson, task selection and the three criteria are there; which task this map was drawn for is decided in that lesson.
Which field to collect, how to define it, where it lives. The field marks from this lesson go in there.
Task selection, the three criteria and the pilot. Which task this map was drawn for is set there.
The whole training section and the lessons added since.
If you would like to draw your process together, write to us and we can fill the map in with you.
Get a Quote on WhatsApp