Business process audits: what to examine before you automate

Business process audits help established organisations understand why work is slow, expensive or difficult to control before investing in automation. The useful outcome is a prioritised plan grounded in how the business actually operates, including its people, systems, exceptions and constraints.

Picture an order that arrives promptly, sits in an inbox for two days, gets entered into three systems and finally reaches the delivery team with a missing reference. The person typing the details may look like the bottleneck. The larger problem could be an unclear approval rule, inconsistent customer information or a handoff nobody owns. Automating the typing would leave most of that problem intact.

An operational audit should make those distinctions visible. It should also give management enough information to decide what to improve, what to leave alone and where further investigation would be more valuable than a quick technical fix. This guide explains how to scope that work and judge the quality of what you receive.

Start with an operating question

“We need AI” is an ambition, not an audit question. “Why does an accepted quotation take so long to become a confirmed job?” gives the investigation a starting point and an observable endpoint. “Why do our branches disagree about available stock?” identifies a different problem, with different evidence and people to involve.

Write the question in terms a process owner can recognise. Name the work, the people affected and the consequence of the current situation. Avoid deciding on the solution inside the question. Asking which AI tool should replace a spreadsheet assumes replacement is the right answer before anyone has examined what the spreadsheet does.

A useful initial scope also states what the audit excludes. An enquiry-to-booking review might include customer records, quotations, approval and scheduling, while excluding payroll and procurement. Boundaries keep the exercise manageable and prevent a small diagnostic from turning into a vague review of the entire organisation.

Follow a real case from beginning to end

Process documents describe the intended operation. Interviews describe how people understand it. A real case shows what happened on a particular occasion. A strong audit uses these forms of evidence together instead of treating any one of them as complete.

Choose representative examples with the team: an ordinary request, a more complex request and an exception that required intervention. Trace the information through each stage. Record when it arrived, when someone acted, what they needed and where the next person found it. Distinguish observations from recollections so uncertainty remains visible.

Observation should be agreed and proportionate. Explain its purpose to staff, avoid unnecessary personal information and focus on the work rather than covertly judging individuals. The GOV.UK service manual describes contextual research and observation as a way to understand people in the setting where activities happen. That principle is useful in a commercial operation too, although the scope must fit the organisation.

Separate work time from waiting time

A task can involve six minutes of active work and spend three days in a queue. Those are different problems. Improving the six minutes may be worthwhile, but it will barely change the customer experience if nobody addresses the queue.

Record active handling, elapsed time, waiting and rework separately. Ask whether a request is waiting for a decision, missing information, a scheduled batch or someone who is unavailable. Check whether the delay occurs consistently or mainly around particular shifts, reporting dates or absence periods.

You do not need a sophisticated time study for every initial assessment. A small, clearly described sample can expose useful patterns. It cannot establish a universal average for the business. Keep the sample period, selection method and limitations attached to the figures rather than allowing an approximate observation to become an unquestioned performance target.

Examine the handoffs between teams

Many operational problems live between departments. Sales may consider an order complete when the customer says yes; finance may require a validated account; delivery may need a site reference that nobody requested. Each team can be following its own instructions while the overall process performs poorly.

For every handoff, identify the sender, recipient, required information and acceptance condition. Ask how the recipient knows work is ready, how incomplete work is returned and who follows up when nothing happens. A shared inbox is a location, not an accountable owner.

Look for informal coordination that keeps the business running: a colleague who checks every request, a private spreadsheet or a messaging group used to repair missing context. These workarounds contain valuable operational knowledge. Removing them without understanding their function can make a technically cleaner system less reliable in practice.

Map systems and record ownership

List the tools involved in the selected process, including spreadsheets, email, messaging and paper records. A system inventory should explain the role of each tool, the information it holds and the people authorised to change it. Product names alone tell you very little.

Then identify the authoritative source for important records. Where does the correct customer address live? Which system determines whether an invoice is paid? What identifies the same job across departments? Conflicting ownership creates reconciliation work that automation can easily multiply.

Check integration possibilities with appropriate evidence. A supplier advertising an API does not establish that your subscription includes the required access, that the necessary fields are available or that the integration can meet the operating volume. Mark untested assumptions explicitly and assign someone to validate them before a build is commissioned.

Make exceptions part of the main investigation

The ordinary path is usually easier to automate than the cases requiring judgement. Refunds, cancelled jobs, duplicate customers, missing documents, partial deliveries and changed instructions can consume a disproportionate amount of attention. An audit that ignores them can produce an attractive but incomplete business case.

Create an exception register. For each case, record how it is detected, who can decide what happens and which information the decision requires. Ask whether the exception is genuinely unusual or simply a regular part of the operating model that the formal process does not acknowledge.

Do not assume every exception needs a new automated rule. Some are better routed to a person with the right context. The important design question is whether the system can recognise the boundary, preserve the record and give that person a clear next action. Human review is useful only when someone has the time, authority and information to perform it.

Include the people who do the work

Managers can explain commercial priorities and formal responsibilities. Frontline staff can explain what breaks on a busy Tuesday, which fields are routinely wrong and why a shortcut exists. Both perspectives are necessary, and neither should be treated as a substitute for the other.

Invite staff to correct the process map before it becomes an approved finding. Ask what has been missed, which situations differ and whether the proposed improvement would create work elsewhere. This is particularly important when one department's efficiency depends on another department doing additional administration.

Be careful with language. “Staff are resistant” can hide unclear benefits, inadequate training or a genuine operational concern. Ask what would make the new process usable, what people would need to stop doing and how responsibilities would change. An implementation plan should fund that transition rather than assuming adoption will happen automatically.

Compare more than one improvement option

An independent audit should leave room for several answers. Sometimes the right move is a clearer decision rule, a better form or an existing feature in software the organisation already pays for. Sometimes integration or custom development is justified. Sometimes the evidence does not yet support a purchase.

Compare options against the same requirements: expected benefit, implementation effort, recurring cost, risk, maintenance and reversibility. Explain what each option would solve and what would remain. Avoid comparing a fully costed conventional solution with an AI demonstration that excludes review, monitoring and support.

Sequence the recommendations. Agreeing record ownership may be a prerequisite for integration; improving source data may be a prerequisite for trustworthy reporting. A roadmap should expose those dependencies so management can avoid funding an apparently attractive project that cannot work until less glamorous foundations are repaired.

Understand what a sensible scope costs

A narrow diagnostic and an organisation-wide operational assessment are different services. Price depends on the processes, sites, systems, interviews, observation and analysis involved. A small headcount does not automatically mean a simple operation, particularly when the business handles complex transactions or regulated work.

Separate consultant effort, on-site days and elapsed delivery time. Preparation, evidence gathering, analysis, report writing and the findings discussion all require time. A project may span several weeks even when consultant effort is lower, because staff availability or a relevant reporting cycle affects the schedule.

At 114 Labs, a focused UK diagnostic starts from £750, subject to an agreed narrow scope. That is not a promise to audit an entire organisation in one day. Wider assessments and international on-site work require a specific proposal, including any agreed travel arrangements. Ask what is included before comparing headline prices.

Build an improvement backlog management can use

A recommendation such as “improve data quality” is too broad to assign. A useful backlog item identifies the problem, affected workflow, supporting evidence, owner, proposed action and acceptance measure. It should also record dependencies and any unresolved questions.

Priority should reflect business consequences as well as convenience. A frequent administrative annoyance may offer a quick improvement; an infrequent failure that loses important customer records may deserve attention first. Use a transparent prioritisation method, then discuss its assumptions rather than allowing a numerical score to make the decision alone.

Include actions that do not require external implementation. A useful assessment should give the organisation something it can progress internally. If every recommendation leads to one supplier's product or a single large build, ask whether alternatives were genuinely considered and how the conclusion was reached.

A worked example: delayed quotation approvals

Consider an illustrative distributor whose sales team repeatedly chases quotation approval. This is a fictional example, not a 114 Labs client result. The first explanation is that managers need a faster approval screen. The investigation follows ordinary, discounted and unusual orders across sales, purchasing and management.

The map shows that managers often wait for a supplier cost that purchasing has already received but recorded elsewhere. Some quotations also arrive without an explanation of the requested discount. The approval screen is inconvenient, but missing context and disconnected information create much of the delay.

A proportionate roadmap could first define the required quotation information and a clear approval owner. It could then connect validated supplier costs to the quotation record, followed by a controlled approval workflow. The pilot would measure elapsed approval time, incomplete requests and exceptions, while checking that margin controls still operate as intended.

Ask for evidence you can challenge

Before accepting the findings, ask the consultant to distinguish confirmed observations, staff-reported issues and hypotheses. Review the sample behind any timings or cost estimates. Ask which departments validated the map and whether important disagreements remain unresolved.

The final discussion should allow management and staff to challenge the interpretation. A useful consultant can explain why a recommendation follows from the evidence and what would change the recommendation. Certainty about everything is less valuable than a clear account of what is known and what needs testing.

Request editable working outputs where appropriate: maps, a prioritised backlog, assumptions and an implementation brief. Agree confidentiality and ownership in the engagement terms. A beautifully presented report is helpful, but the practical test is whether the organisation can use it to make and carry out a decision.

Turn the audit into a controlled next step

Choose one improvement with a clear owner, bounded scope and measurable outcome. Establish the baseline before changing the process. Define how the team will recognise success, what could go wrong and how the old or manual process remains available during the transition.

Review the result with the people affected, including anyone whose workload moved rather than disappeared. Decide whether to expand, revise or stop. The audit has done its job when it supports that decision, even if the answer is a modest process change rather than a major technology programme.

If your organisation needs a clearer starting point, explore the 114 Labs business process audit. We can scope a focused diagnostic or a broader assessment around a specific operating problem, with practical deliverables and the option to commission implementation separately.

Questions to take into your first conversation

Bring one process you want to understand, the business consequence of its current performance and the names of the teams involved. You do not need to send confidential datasets or choose a technology in advance. A few representative, appropriately redacted examples can be discussed once suitable arrangements are in place.

Ask who will conduct the work, how staff will be involved, what the assessment excludes and how recommendations will be validated. Confirm the expected outputs, timing and commercial terms. Those questions make the engagement easier to compare and create a more useful foundation for everything that follows.

It is also worth agreeing how the findings will be kept current. A process map can become outdated when a supplier changes, a new branch opens or responsibilities move between teams. Give the document an owner and a review trigger. Record later changes against the original assumptions so the organisation can see whether a recommendation still applies. This turns the audit into a working reference for future decisions, rather than a document that describes one moment and is never opened again.