Ask a staff member how they handle an order and they will describe it in four steps. Watch them do it and you will count eleven, including two phone calls, a glance at a notebook in the drawer and a decision they make based on who the customer is. The four-step version is what gets automated. The eleven-step version is what actually keeps the business running.
That gap is why so many automation projects disappoint. The software does exactly what it was told, and what it was told was incomplete. Writing the process down properly, before anyone builds anything, is the cheapest way to close the gap.
Watch the work, do not just ask about it
Sit with the person who does the job for a full session. Do not interrupt at first. Write down every action, including the ones that seem too small to matter:
- Where the work arrives from (a WhatsApp message, an email, a phone call, a paper form).
- Every screen, file or notebook they open.
- Every piece of information they copy from one place to another.
- Every time they stop to check something, and what they check.
- Every time they ask someone else a question.
- Where the finished work goes.
Afterwards, go through your notes with them and ask “why” at each step. Often the answer reveals a rule nobody has written down. “I check the customer’s area because the courier does not deliver cash on delivery to some places.” That rule needs to be in the process, or an agent will happily confirm orders that cannot be delivered.
If more than one person does the same job, watch at least two. You will usually find they do it differently. Decide which way is correct before you automate either.
Write it as numbered steps with inputs and outputs
Turn your notes into a simple numbered list. For each step, write three things: what comes in, what the person does, and what comes out. Keep the language plain. For example:
- In: a WhatsApp order message. Do: check the item name and size against the stock sheet. Out: item confirmed in stock, or a reply saying it is not.
- In: a confirmed item. Do: check the delivery address is in an area the courier covers for cash on delivery. Out: address accepted, or a message asking for advance payment.
- In: an accepted order. Do: enter it in the order sheet with the customer’s phone number. Out: an order row.
This format matters because agents work on inputs and outputs. If a step has no clear output, it is hard to automate and hard to check.
Hunt for the exceptions
The normal case is easy. The exceptions are where automation breaks. For each step, ask the person: “What happens when this goes wrong?” and “What is the strangest case you have had this month?”
Write every exception down with how it is handled today. Common ones include:
- The customer sends a voice note instead of text.
- The customer writes in Sinhala or Tamil using English letters, or mixes all three.
- The customer asks for a discount because they are a regular.
- The item is out of stock but a similar one is available.
- The same customer orders twice by mistake.
Then mark each exception with one of three labels: the agent can handle this, the agent should pass this to a person, or we need to decide a rule first. The third group is important. If staff currently handle a case by instinct, someone senior needs to turn that instinct into a rule before any software can follow it.
Mark the decisions that need a person
Go through the list one more time and highlight every step that moves money, sends something to a customer that cannot be taken back, or changes a record permanently. These are the steps where a person should approve the agent’s work, at least in the first version. Writing them down now saves an argument later.
Count the volume and the time
For each step, note roughly how often it happens and how long it takes. You do not need precision. “About forty orders a day, around three minutes each for steps one to three” is enough. This tells you where the time actually goes, which is often not where people assume.
A worked example: if forty orders a day each take three minutes, that is two hours a day, or around forty to fifty hours a month. If exceptions take ten minutes each and happen five times a day, they add another eighteen or so hours. Automating only the normal case would save most of the time, while still leaving a person to handle exceptions.
What this exercise will not do
Writing a process down does not make it a good process. Sometimes you will discover that a step exists only because of an old problem that no longer applies. Remove it before automating, not after.
It also takes time, usually a few days for a single process, and staff may feel watched. Explain that you are recording the job, not judging the person, and involve them in checking the final document. They know the work better than anyone.
Once you have a clear written process, a builder can tell you quickly what is possible and what it will cost. If you want a structured way to turn your notes into a design, try the agent blueprint tool. Start by booking one hour next week to sit beside the person who does the job, with a notebook and no laptop.
