The 90-minute process audit we run before we touch anything

You can audit any process inside your company in ninety minutes.

The audit does not start with a tool. It does not start with a vendor demo or a list of features. It starts with a sheet of paper and a question that makes half the room uncomfortable.

I mean the question that comes before any talk of automation, before any cost estimate, before anyone opens a laptop. You ask it about one process at a time, and the answer tells you whether you should automate the thing or leave it alone.

I will walk you through the whole audit here. You can run it this week. You need nothing but a quiet room, the person who does the work, and someone who understands what the business actually needs.

What the audit replaces

Most companies skip straight to the tool.

The marketing director reads about AI agents and decides the customer onboarding emails need automating. The ops lead buys a RPA license and points it at the invoice queue. A consultant is brought in to "identify automation opportunities" and returns with a heatmap of tasks ranked by hours spent.

Each of these paths begins with a solution and looks for a problem to attach it to.

This is why so much process automation fails quietly. The bot gets built, the team stops using it after three weeks, and nobody measures the outcome because measuring would mean admitting the whole project was a guess.

The ninety minute audit inverts that order. It starts with how the work actually moves, not with what the software can do.

The room and the people

You need two voices in the room. Three, if you count the one taking notes.

The first voice is the operator. The person who does the process every day, or did until last month. Not their manager. The individual contributor who knows the keyboard shortcuts, the names of the awkward clients, the one field in the CRM that always gets filled in wrong.

The second voice is the process owner. This is the person responsible for the outcome the process is meant to produce. Usually a department head or a team lead. Someone who can say "that step exists because compliance requires it" or "we do that because Sarah in finance asked for it three years ago."

The combination matters. The operator knows the work. The owner knows the reason. Without both, you map what happens without learning why, or you map the ideal without seeing the reality.

Step one: name the trigger

Every process starts somewhere.

A form is submitted. An email arrives. A Slack message appears in a channel. A spreadsheet hits a deadline. A phone rings.

The first thing I ask: "What event makes you start doing this thing?"

Do not accept a vague answer. "When a customer signs up" is not precise enough. Push until you get the specific artefact. "When the welcome email is automatically sent by the website." "When the contract PDF lands in the shared drive." "When the ticket is assigned to our queue."

Write that trigger at the top of the page. If the process has multiple triggers, write all of them. A process with five entry points is five intertwined processes wearing one name. You will treat each one separately later.

This step takes three minutes. Do not skip it. If you cannot name the trigger, you are not auditing a process. You are auditing a vibe.

Step two: map the inputs

Now ask: "What information do you need before you can take the first action?"

List every piece of data the operator looks up, waits for, copies from somewhere else, or guesses because it is never supplied.

Be specific. Not "customer details" but "customer name, email, account number, product purchased, date of purchase." Not "approval" but "finance director's email confirming the budget code."

Put each input on a sticky note or a row in your notes. Note where it comes from: another system, another person, the customer themselves, a document sitting in a folder.

One input always shows up that the operator says they "just know." A pricing rule. A priority level. A judgement call about who to escalate to. Mark these with a star. They are not inputs. They are embedded decisions, and you will return to them.

Step three: trace the flow

Now you follow the work from trigger to end state.

Ask the operator to talk through every step in order. Not the ideal version. The version from last Tuesday.

You write each step as a verb plus an object. "Open the attachment." "Check the client's industry in the CRM." "Copy the account number into the invoice template." "Forward the thread to legal."

Do not editorialise yet. Do not say "that step is stupid" or "we could automate that." Just capture the actual sequence.

When you hit a step that begins with "sometimes" or "it depends," circle it. These are decision points. You will handle them separately.

When the work passes from one person to another, draw a line between the steps and write the hand-off method. "Slack message." "Ticket reassigned in Jira." "Email with the subject line containing 'URGENT'." "Printed sheet left on the desk." (That last one still happens.)

Keep going until you reach the state where nothing more needs to happen. The customer is onboarded. The invoice is sent. The report is filed. The record is closed.

This tracing step usually takes forty minutes. It is where the audit earns its value. The operator is speaking, the owner is hearing things they did not know were part of the job, and patterns are already surfacing.

Step four: isolate the decisions

Go back to every circled step and every starred input.

For each one, ask: "At this moment, do you make a choice, or do you follow a rule?"

If the operator follows a rule, write the rule. "If the order value is under five thousand, skip the credit check. If it is over, send to finance." "If the customer is in healthcare, use the compliance version of the contract. Otherwise use the standard one."

If the operator makes a choice, ask what they consider to make it. Usually it is a combination of experience, context about the client, and an unwritten understanding of risk.

Do not try to turn every choice into a rule yet. Just separate the two categories. Rule based steps sit on one side of your notes. Judgement based steps sit on the other.

This distinction is the skeleton of any sensible automation plan. Automating a rule based step is straightforward. Automating a judgement based step requires a completely different approach, and sometimes the right call is to leave the judgement with the human and automate everything around it.

Step five: name the exceptions

Every process has exceptions. The operator handles them constantly but rarely labels them as such.

Ask: "What is the last thing that went through this process that did not follow the normal path?"

You will hear things like:

• The customer sent the wrong form, but we processed it anyway because they were a renewal.
• The VP asked for a special report format, so we built it in Excel instead of using the dashboard.
• The payment was in a different currency, so we manually calculated the exchange rate.
• The attached file was corrupted, so we called the client.

List every exception from the past two weeks. Do not judge them. Do not say "that should not happen." The fact is it does happen, and any automation that ignores these exceptions will break on week one.

For each exception, ask how often it occurs. The operator will usually say "not often" and then, after a pause, remember three more instances.

Frequency matters more than severity at this stage. An exception that happens once a quarter can be handled manually. An exception that happens three times a week cannot. It is part of the real process, and you must treat it as a branch, not an anomaly.

Step six: surface the hidden work

Ask the operator: "What do you do that is not in the official process but that makes the process actually work?"

This question produces the most useful information of the audit.

You get answers like:

• "I check the client's LinkedIn before I call them so I know what tone to use."
• "I keep a personal spreadsheet of which approvers are fast and which ones sit on things."
• "I re-read the last three emails in the thread because the ticket description is always wrong."
• "I send a WhatsApp message to Dave in logistics because the system update takes four hours."

None of this appears in the onboarding documentation. None of it is in the SOP. All of it is load bearing.

Map this hidden work alongside the visible steps. It is as real as the button clicks. An automation that replaces the visible steps but removes the operator's ability to do the hidden work will create a process that runs perfectly on paper and fails in practice.

The one question you were waiting for

By now you have spent about eighty minutes on the audit. You have a map that shows the trigger, the inputs, the sequence, the decisions, the hand-offs, the exceptions, and the hidden work.

Now you ask the question that determines whether any of this should be automated at all.

You ask the process owner, not the operator:

"If this process produced exactly the right outcome every single time, with zero errors and zero delay, would that outcome measurably improve the business?"

The words "measurably improve" are the test. Do not accept "it would make people less frustrated" or "it would free up Sarah's time." Those are real benefits, but they are not business outcomes.

Ask for the number. Revenue saved or gained. Customers retained. Compliance risk reduced to a specific level. Time to close shortened by an amount that increases capacity for revenue generating work.

If the owner cannot name a measurable improvement, the process does not need automating. It may need improving, simplifying, or deleting. But spending money and time to automate a process whose perfect execution does not move the business forward is a hobby, not an investment.

If the owner can name the improvement, write it at the bottom of the page. That sentence becomes the specification for everything you build. Not "automate onboarding" but "shorten the time from signed contract to active account from four days to one, reducing the window in which new customers churn."

After the audit

You now have a one page map and a clear test result.

If the answer to the final question is yes, you have exactly what you need to brief a builder. You can hand them the trigger, the inputs, the rule based decisions, the hand-offs, and the exceptions with frequencies. You can tell them which hidden work must be preserved, either by building it into the automation or by leaving a deliberate human touchpoint.

If the answer is no, you have still gained something. You have a documented process that can be simplified. You have a list of exceptions that might indicate a deeper structural problem. You have the operator's trust because someone finally asked them how the work actually happens.

Both outcomes are worth ninety minutes.

This audit is the first thing we run whenever we take on a client's process at Nexibeo. It does not require a vendor, a platform, or a technical background. It requires the willingness to sit with the people who do the work and listen before you build.

You can run it this week for any process that takes more than two hours a week of someone's time. Pick the one that irritates you most. Find the operator. Find the owner. Book ninety minutes. Start with the trigger.