When someone asks for a manual process to be automated, the process is usually slow for a reason that software will not fix. The work waits for a decision nobody owns, for a document nobody can find, or for a person who is never told it has arrived. Digitise that and you get the same wait, delivered faster and now harder to see.
This guide shows how to observe one real transaction before you commission anything. The example is fictional.
Follow one request from arrival to completion
Pick a single request that has already finished and trace it. Do not interview managers about the process yet. Ask the people who touched the request to show you what they did, in order, with the actual messages, forms and files.
Our fictional business is Nile Crest Transport, a company running a small fleet. A driver reports a brake fault. The request must reach the workshop, a garage quote must be approved, and finance must pay the garage. The traced request took nine working days. Record every person who touched it:
| Step | Who | What they did | Evidence they used |
|---|---|---|---|
| 1 | Driver | Phoned the fleet clerk about the fault | Phone call, no record |
| 2 | Fleet clerk | Wrote it in a notebook, then messaged the workshop | Notebook, group chat |
| 3 | Workshop lead | Asked a garage for a quote | WhatsApp photo of the quote |
| 4 | Fleet manager | Approved the quote by voice note | Voice note |
| 5 | Finance clerk | Asked for the approval in writing | Email thread |
| 6 | Fleet clerk | Re-typed the quote into an email | |
| 7 | Finance | Paid the garage | Payment reference |
Seven people, five channels, two re-typings. No single record shows the whole request.
Separate working time from waiting time
For each step, note the clock time the request arrived and the time work started and finished. The gap between arrival and start is wait. The gap between start and finish is work.
In the Nile Crest trace, the actual work added up to under two hours. The other days were waits: two days for the garage quote, one day for the manager to hear a voice note, three days for finance because the approval was not in writing, three days for payment processing. Most of the nine days belonged to handovers, not tasks.
This changes what you buy. A system that speeds up typing saves minutes. A system that fixes the handover between manager and finance saves days.
Ask why each workaround exists
Every notebook, voice note and photo is evidence of a need the official process does not meet. Ask the person who made it: what would go wrong if you did not do this?
At Nile Crest the fleet clerk’s notebook existed because the phone call left no trace and the clerk had been blamed once for a lost request. The voice note existed because the manager approved from a workshop floor with no laptop. Remove either before understanding it and you remove the only thing making the process work. Keep the need; replace the method.
Define each handover
For every point where work moves from one person to another, write three things:
- Entry condition. What must be true for the work to arrive? (A fault described with a vehicle number and a photo.)
- Completion condition. What must be true for the sender to stop worrying? (The recipient has acknowledged the request.)
- Owner. One role who must act, and who answers if the work stalls.
Nile Crest’s worst handover was manager to finance. Entry condition: a quote with the vehicle number and an approved amount. Owner: the finance clerk. Completion: payment reference recorded against the request. Written this way, the missing written approval stops being a surprise: it is an entry condition the handover failed.
Remove a step before you digitise it
Look at the trace for steps that add no value: re-typing a quote into an email, asking the same question twice, collecting a signature that nobody checks. Remove those where you have the authority. If you do not, take the finding to the person who does.
Then describe the smaller process in plain words: the driver logs the fault with a photo; the workshop attaches the quote; the manager approves in the request; finance pays against the approved request. That is what you hand to a developer or a vendor. It is also the thing you could run on a shared spreadsheet for a month to test the design before paying for software.
Illustrative image, licensed from Magnific. The image does not show a Nile Crest process or any Chwezi system.
Measure before and after with one definition
Decide in writing what counts as complete (for example, the garage is paid and the payment reference is on the request) and what counts as rework (any request sent back to an earlier step). Measure both on the old process, make the change, then measure again with the same rule. If you change the definition halfway, the comparison is worthless.
The process observation sheet
Copy this table and fill one row for each handover you trace.
| Request | Actor | Evidence needed | Time arrived | Time started | Wait reason | Exception seen | Completion rule |
|---|---|---|---|---|---|---|---|
| Brake fault, vehicle 14 | Fleet manager | Quote with vehicle number and amount | Day 3, 09:10 | Day 4, 11:00 | Approval sent as a voice note, finance wanted writing | Approver away from desk | Approved amount recorded on the request |
Give the sheet to the people doing the work, not only to those supervising it. They know where the work waits.
What changes by market
The method needs no particular country or software. What varies is which records the law or your auditor requires for approvals and payments, and which channels your staff and suppliers can use reliably. Confirm these locally rather than assuming that any single channel, such as WhatsApp or email, will be accepted as an approval record. Where connectivity is uneven, ask what happens to a request when the person with the next step is offline.
Sources and scope
- Chwezi Core Systems, Software development and systems implementation. Public offer description, not independent evidence of capability or results.
- Nile Crest Transport is fictional. Its trace, timings and findings are invented to demonstrate the method and do not describe a Chwezi client.
Common questions
- Should we map the whole process first?
- No. Follow one real transaction end to end, then a second that went wrong. A single traced request shows where the work waits. A wall-sized diagram of the intended process usually shows what people say should happen.
- Why do staff keep a paper or spreadsheet workaround?
- Usually because the official process lacks something they need, such as a missing approval path, an unclear owner or an information gap. Ask what the workaround does before you remove it, or the need will resurface in the new system.
- How do I measure whether digitising helped?
- Define completion and rework once, in writing, and measure both before and after the change using the same rule. Without a fixed definition, the before and after numbers describe different things.
- Who should own a handover?
- One named role, not a team. The owner is the person who must act when the work arrives and who answers if it stalls.