How to run a one-week workflow audit yourself

Why a week, and why you

Every owner has a workflow they complain about. Invoices go out late. Quotes sit. Job tickets arrive days after the work. The complaint gets repeated in meetings for years, and nobody ever looks closely at how the work actually moves, because everyone is busy doing it.

You do not need a consultant to take that close look. You need a week, a notebook and permission to ask dumb questions. What follows is the method we use at the start of our own work, stripped down so a company can run it without us.

One rule before you start. Audit one workflow, not the business. Pick the one that costs you the most or annoys you the most, and write down where it starts and where it ends. For example: from the moment a job is marked done in the field to the moment the invoice is sent. A clear start and end keep the week from sprawling.

The second rule: do not fix anything during the week. You will see things that are obviously broken. Write them down and leave them. The moment you start fixing, you stop seeing.

The week, day by day

• Monday: walk one job. Pick a real job that is starting today and follow it. Ride along, stand in the shop, sit with the dispatcher, sit at the desk where the paperwork lands. Write down every step, who does it, what they use (a phone, a form, a whiteboard, a text, a spreadsheet, a memory), and where the information goes next. Do not rely on what people say the process is. Watch it. If the job does not finish today, keep following it tomorrow in the gaps.
• Tuesday: time each handoff. Go back over your notes and mark every place the work passes from one person or system to another. Now take ten recent jobs from your records and, for each handoff, find out when the work arrived and when the next person picked it up. You are not timing how long people work. You are timing how long work waits between people. The waits are almost always longer than the work.
• Wednesday: count the retyping. For each piece of information in the workflow, such as the customer, the site, the hours, the parts, the photos, the notes, count how many times someone types it by hand. A technician writes the hours on a ticket. The office types them into the schedule. Someone types them again into payroll. That is three entries for one fact. Put the counts in a simple table. Every entry after the first is the re-entry trap.
• Thursday: list the exceptions. Ask everyone in the workflow the same question: what happens when a job does not go the normal way? The second trip. The customer who changes the order on site. The job that needs a part nobody has. The approval that waits because the approver is on a job. Write each one down with how it is handled today. Then go back to your ten jobs and mark which ones were exceptions. You may find the exceptions are not exceptions at all.
• Friday: find the oldest waiting item. Look at everything in the workflow that is currently waiting on someone. Open quotes. Unbilled jobs. Tickets not entered. Change orders not signed. Find the oldest one and trace why it is still there. Nobody decided to let it sit. Something in the workflow let it become invisible. Then write a single page: the steps from Monday, the waits from Tuesday, the retyping from Wednesday, the exceptions from Thursday and the oldest item from Friday.

What to watch for each day

On Monday, the thing to watch for is the difference between the official process and the real one. If your office manager says tickets come in at the end of the day and you watch them come in as texted photos at nine at night, write down the photos. The real process is the one you are auditing.

On Tuesday, the long waits usually sit at a handoff gap: the moment where one person believes the work is done and the next person does not yet know it has arrived. Pay attention to how the next person finds out. If the answer is that they check a pile, a tray or an inbox when they get a chance, you have found your biggest wait.

On Wednesday, pay attention to who does the retyping. It is often one person, usually in the office, who has quietly become the cable between two systems. Ask them how long it takes and what happens when they are out. Their answer tells you a lot about how fragile the workflow is.

On Thursday, watch for exceptions that get handled on paper or by phone because the normal system cannot hold them. Those are where information disappears. When the crew falls back to a notepad for anything unusual, the system of record is only a record of the easy jobs.

On Friday, the oldest waiting item is rarely the result of someone being lazy. It is almost always in an invisible queue: a list of waiting work that nobody can see all at once, so nobody knows it is growing. Ask where you would have to look to see every item that is waiting. If the answer is several places, or someone's head, that is the finding.

What you will have at the end

By Friday afternoon you should have one page that a stranger could read and understand how the workflow really runs. It should show where the work waits, where it gets typed twice, where it breaks when a job is unusual, and what has been sitting the longest.

That page is worth something on its own. It turns a vague complaint into a specific one. "Invoicing is slow" becomes "invoices wait for a ticket that sits in a truck until the weekly office visit, then get retyped twice." A specific problem can be argued about, sized and fixed. A vague one just gets repeated.

Keep your raw notes with the page. The ten jobs from Tuesday, the retyping table from Wednesday and the exception list from Thursday are a baseline. If you change anything later, whether a new rule, a new tool or a new person in the role, you can run the same counts again on the same kind of jobs and see whether the workflow actually moved. Without the first count, you will only have opinions about whether it helped.

Where to stop

Stop at the page. Do not design the fix yet.

The temptation will be strong, because by Friday some answers will look obvious. Resist it for a week. The first fix people reach for is usually a bigger system, and the audit often shows the problem is smaller and more specific than that. Share the page with the people in the workflow and ask them what you got wrong. Their corrections are part of the audit.

When the page is right, then decide what to do. Some findings you can fix with a change in who approves what, or a rule about when tickets come in. Others need a tool. That decision is easier to make well when the picture is honest.

What to do next

If your audit shows tickets reaching the office late, the guide on job tickets reaching the office late picks up where this note stops. The full set of problem guides covers other common findings. If you want a second, deeper version of this week with a measured baseline and a fixed proposal at the end, that is what our Workflow Spec does, described on How we work.