How to Audit a Business Process Before Adding AI
A practical method for tracing a business process, finding delays and errors, deciding what to change, and testing where AI fits.
A working method for tracing the work, deciding what should change, and testing where AI fits.
If a company wants AI to handle customer inquiries, the first useful question is what happens to an inquiry today. A customer fills out a form. Someone copies the message into another system, looks for the right account, decides who should respond, checks service information, drafts a reply, waits for approval, sends it, and updates the record. A model that drafts a reply may shorten one step while the approval delay stays in place. The company needs to find out why that delay exists and whether the approval is necessary.
An audit should produce an answer the business can act on: a record of what happens now, evidence of where time and errors enter, a decision about each step, and a testable design for the process that follows. The method below uses a hypothetical service-company inquiry, but the same sequence works for an invoice, a support request, an order, or another process with a clear start and finish.
1. Put a boundary around the process
Choose one process that people can follow from its trigger to a completed result. Name the person accountable for that result and the people who actually do the work. If a customer inquiry is the subject, the process might start when a website form is submitted and end when the customer receives an accurate first response, an owner is assigned, and the customer record is updated. Later sales or service work belongs to a different process unless the audit shows that it affects this first response.
Write the boundary at the top of the audit record. Include the trigger, the finish, the process owner, the systems involved, and the case types that may take a different route. This keeps the work from expanding into a general review of the whole company. It also exposes disagreement early. If the service team thinks the process ends when a reply is drafted, while the account team thinks it ends when the customer record is complete, the owner needs to decide which result the business is measuring.
2. Define an accepted result before measuring speed
Describe what a successful case must contain. In the service-company example, the customer should receive a correct first response within the company's chosen time target. The message should be attached to the right account, urgent requests should reach the person authorized to act, and the record should show the response and the next owner. These conditions are examples for the hypothetical company. A real business should set its own time target and acceptance rules.
Separate the conditions that apply to every case from those that apply only to an exception. A routine scheduling question may need a correct answer and a logged follow-up. A complaint involving a safety issue may need immediate escalation even if nobody can give a complete answer yet. The service owner should write down which errors can be corrected later and which would make the result unacceptable. That distinction will matter when the team tests an AI task.
The output of this step is a short acceptance statement, not a model prompt. It lets the team ask whether the current process produces the intended result and whether a proposed change improves it. Counting drafted replies alone would miss wrong accounts, missed escalations, and work left for the next employee.
3. Gather cases that show the usual path and the exceptions
Pull a set of recently completed cases from the systems the team already uses. Start with consecutive cases from a defined period so the sample shows ordinary volume and outcomes. Then add known exception cases deliberately: an urgent message, an ambiguous request, an account mismatch, a case returned for correction, and a request that arrived with missing information. Keep the selected exceptions marked separately. Otherwise the sample can make rare failures look routine.
Use case records, timestamps, and the people who worked each case. If the records contain private customer information, give reviewers only the access they need and remove identifying details from the working audit. A procedure document can help identify the intended route, but it does not replace the actual case history. The employee who uses a private spreadsheet to resolve account names or catches bad inputs in an inbox may be performing a step the procedure never mentions.
Record the case ID, type, start time, accepted finish time, and any return to an earlier step. Make a note when a timestamp or decision cannot be recovered. The absence of evidence is useful to know; filling the gap from memory would make the baseline look more certain than it is.
4. Trace each case from arrival to accepted finish
Trace every selected case through its handoffs in order. At each point record who or what acted, the system used, the input available, the action or decision, the output passed on, and the next owner. Capture active work time and waiting time separately. Note why a case branched, why it returned, and what information the next person had to reconstruct.
One hypothetical routine inquiry arrives at 9:00 a.m. A coordinator spends three minutes copying it into the customer system. A service employee spends seven minutes finding the account and drafting a response. The draft waits until a manager spends three minutes reviewing it. An employee takes two minutes to send the reply and update the record. The customer receives it at 3:17 p.m. The case contains fifteen minutes of active work and six hours and two minutes of waiting. Those figures are illustrative; a real audit calculates them from observed cases.
That case immediately changes the improvement question. A model that drafts in one minute might save part of the employee's seven minutes. It would not address the long approval wait. The audit should find out why the manager reviews every response. The answer could be a binding policy, inconsistent service information, uncertainty about employee authority, or a small set of risky requests mixed into a routine queue. Each cause suggests a different next step.
Build the current-state map from these traces rather than drawing it from memory. Show the routine path, each meaningful exception route, and the loops that send work backward. Ask the employees who perform the steps to walk through the map with a real case. If two employees handle the same situation differently, record both routes and ask the process owner which one should apply.
5. Find the constraints that actually affect the result
Calculate a baseline for the outcome defined in step two. The inquiry baseline might include time to accept first response, active work time, time in each queue, wrong-account corrections, returned drafts, missed escalation, and cases with an incomplete record. Keep the measure tied to its cause. A single average response time can hide a few severe delays or an urgent case that took the wrong route.
Look at frequency and consequence together. A copy-and-paste step that happens on every inquiry may consume more total staff time than an unusual exception. A rare routing error may deserve attention first if it can harm a customer or breach a contract. The team should also distinguish a bottleneck from a symptom. If employees wait for approval because the policy gives nobody else authority, buying a faster drafting tool leaves that constraint in place.
The audit record should now show where cases spend time, where errors appear, and which finding is supported by which cases. If the sample is too small to estimate a rate, say so. It can still identify a path that needs more observation. This prevents an attractive diagram from standing in for evidence.
6. Decide the fate of each step
Review the current map one step at a time with the process owner and the people responsible for its controls. Ask what the step contributes to the accepted result, what would happen if it disappeared, and whether the same work is done elsewhere. Record the decision beside the step: retain it, remove it, combine it with another step, fix its input, automate it with ordinary software, test AI for it, or keep it with a person. Include the reason and the decision owner.
In the example, copying a form submission into the customer system may be removed through an integration. Account matching may use a stable identifier and an exact lookup. A form that omits information needed for triage may need to change. The manager's approval cannot simply be deleted because it takes time. The policy owner first needs to determine which cases require that control and what evidence a reviewer needs.
Only after these decisions should the team draw a proposed path. It might create the customer record automatically, use rules to check required fields and known urgent conditions, send uncertain account matches to a person, and route only defined categories to a manager. The map should show where each case goes when a system fails or an answer is unclear. If nobody owns the exception route, the proposed process is incomplete.
7. Give each possible AI task a narrow specification
The remaining work may include interpreting a message whose wording varies or drafting a response from approved service information. Write each candidate as a task with an input, an allowed source, an expected output, a check, and a handoff. "Handle customer inquiries" is too broad to test. "Classify the message into the current service categories and cite the part of the message that supports the choice" gives the team something it can evaluate.
In the hypothetical process, a classifier could suggest a category while a fixed rule enforces known emergency conditions. A drafting task could prepare a reply from current service notes while sending remains under the company's approval policy. A summary task should be added only if someone needs that summary to make a decision. Account lookup, record creation, required-field checks, and sending are ordinary software tasks when the rules are exact.
Record the model and provider, instructions, approved information sources, permitted tools, output format, validation, retry behavior, escalation route, and logs for each AI task. The task specification must also state what the model may not do. A draft-response task has no authority to send a message merely because it can compose one. These details make later tests comparable and keep a model change from silently changing the business process.
8. Plan the test before implementation
The audit should define a test of the proposed path using the case types collected earlier. The first run should have no authority to contact a customer or change a live record. Specify how the account match, routing, category, and draft will be compared with decisions the service owner accepts. Include difficult cases as well as routine ones. The test record should distinguish wrong accounts, missed urgency, unsupported claims, outdated sources, invalid output, and drafts that need extensive editing.
Set the pilot's stop conditions before the test. A missed urgent escalation may be unacceptable even if most categories are correct. A slightly awkward draft may be acceptable when a reviewer can correct it quickly. The process owner decides those thresholds with the people accountable for customer service, risk, and operations. The technical team will measure the results against them.
The plan should begin with human review while the team learns what the system does on current work. The reviewer will need the original message, the matched account, the proposed category, the source used for the draft, and any escalation reason. Track time to accepted response, employee correction time, retries, model cost, and cases that return to a queue. Cost per model call tells only part of the story; cost per accepted case shows whether the whole process improved.
The outcome may be an integration without AI, a limited drafting pilot, a policy change, or a decision to repair source information first. Each is a useful result when the evidence supports it. The audit succeeds when the business can explain its decision and name the next owner.
Keep the audit record short enough to use
The finished record should contain the process boundary and owner, acceptance rules, case sample, current-state map, baseline, step decisions, proposed path, and pilot criteria. Each recommendation should point back to a case or a business rule. The process owner should be able to tell a reviewer why a step was removed, why a control stayed, and what would cause the pilot to stop.
After the audit: optimization and automation
The audit produces the map, baseline, step decisions, proposed path, and test criteria. Process optimization comes next: remove or combine unnecessary steps, improve forms and information sources, clarify handoffs and approval rules, and choose tools that fit the revised process. Once that process is agreed, the team can connect systems, add rules for exact decisions, and build narrowly defined AI tasks. The team then tests those changes with appropriate review before allowing them to handle live work.
Implementation depends on the company's actual systems, data, permissions, policies, exception cases, and people who will operate the result. The audit record gives the team a starting point and a way to judge whether the changes helped.
Scale Logic's Technology Readiness Assessment can place that process-level work in the context of the company's systems, integration needs, automation opportunities, AI readiness, and operational constraints. If your company is considering AI for an existing workflow, choose one process and follow real cases before selecting a model. Scale Logic can help turn what the audit finds into a prioritized technology plan.