What Should an Automation Audit Include? Scope, Deliverables, and Cost

Its cost depends on the agreed investigation: the workflows, people, systems, records, and technical questions involved. Compare actual written scopes and quotes. A short review of one process and a company-wide operating assessment are different purchases, even if both are called an audit.

This article concerns an operational automation audit. It is not a financial audit, security certification, or assurance that your business meets a regulatory standard.

Know which decision the audit should support

Before discussing tools, finish this sentence: “We need enough information to decide whether to…”

You might want to connect incoming requests to a work queue, stop re-entering information, improve estimate follow-up, or understand why an existing workflow needs repeated repairs. Those questions create a useful boundary for the investigation.

“We want to use AI” is less specific. Identify the task and the person who can judge a useful result. AI evaluation may need sample inputs and review criteria beyond the scope of a routine workflow audit.

Agree what the audit covers and what remains outside it. A review of inquiry handling should not quietly grow into replacing accounting, scheduling, and the whole CRM. Record related problems, but keep the immediate decision clear.

Prepare examples of work, not just a software list

An application inventory helps, but it cannot explain what staff actually do. Bring a few ordinary requests and a few awkward ones, with unnecessary personal information removed.

An ordinary example might show a customer form, a CRM entry, and the task assigned afterward. An awkward example might involve a repeated submission, a request for a second location, or a coordinator copying information because the connection does not support a required field.

Include the people doing the work. The owner may see the final report while the coordinator knows about the missing information and repeated phone calls behind it. Both perspectives matter.

Useful input	What it helps establish
A normal completed example	The actual sequence from receipt to completion
An incomplete or corrected example	Exceptions and recovery work
Current tool and account details	Where information lives and which capabilities need checking
Counts over a stated period	How often the work occurs
Timing notes or estimates	Where staff time goes and how certain the baseline is
Named participants	Who performs, approves, receives, and maintains the work
Known constraints	Information, timing, budget, or access limits affecting the options

The provider should explain how evidence will be reviewed. Do not send account passwords in a planning document. Use the access arrangement agreed for the investigation and provide only the information it requires.

Expect a traceable description of the current process

A process map is useful when it reflects real work. It should show what starts the task, which information is needed, what each person or system does, and how the result reaches the next person.

Include the work between the obvious steps. “Create a job” may actually involve checking the customer, finding the right property, asking a question, copying the description, and assigning a field lead. Leaving those steps out can make an easy-looking automation proposal unrealistic.

For each important handoff, identify the record that proves it happened. A notification, a saved record, and a person accepting responsibility are different things. The audit should make those distinctions understandable.

Also note what works. If the existing CRM already supports the required assignment, the sensible recommendation might be to configure it and agree a daily working practice. An audit should allow that outcome.

For a concrete handoff to investigate, the website-form-to-CRM guide separates the received request, customer record, inquiry, and assigned next action.

Separate measurements, estimates, and unknowns

A report might contain counted events, observed task times, staff estimates, and assumptions about a future solution. Label them so you can tell which conclusions are firm and which need a trial.

For example, an inbox count may include duplicate notifications. A coordinator's estimate of five minutes per inquiry may include interruptions on some days and only data entry on others. Neither input is useless, but its meaning matters.

Ask whether the stated baseline includes exception handling and maintenance. A workflow that removes copying but creates a daily repair queue has moved some of the work elsewhere.

For the calculation itself, use our guide to net time savings and setup break-even. Keep available staff capacity separate from cash savings. Saving an hour of a salaried employee's time does not, by itself, reduce the payroll invoice.

A fictional audit finding: configure first, measure the result

Cedar Lane Maintenance is a fictional business. Avery coordinates requests and Jordan leads field visits. Customer Alder Studio, C-014, has two sites: L-01 Main studio and L-02 Workshop. Morgan Hale is its billing contact.

Avery reports spending about three minutes entering each of an estimated 24 weekly requests into the existing system. Multiplying those inputs gives 72 minutes a week. In this example, both inputs are staff estimates; 72 minutes is not a measured saving or a promised result.

The fictional sample contains a request from Morgan about L-02, an older request concerning L-01, and a repeated delivery of the L-02 form. Staff currently look up the customer and choose the site manually. They sometimes treat a matching customer as a duplicate request.

Suppose the account review establishes that the existing tool can associate an inquiry with a customer and site, and can assign a task to Avery. That capability is an assumption of this fictional example, not a claim about a particular product.

The recommendation is to configure those existing features, preserve each request's identifier, and try the process with a small set of examples. Replacing the CRM is deferred because no demonstrated requirement yet justifies it.

Finding component	Completed fictional example
Problem	New work for an existing customer can be confused with a repeated submission
Evidence	Two distinct site requests and one repeated delivery in the sample
Baseline	Estimated 24 requests × 3 minutes = 72 minutes weekly; timing unverified
First change	Configure customer/site association and coordinator assignment in the existing tool
Acceptance test	A new L-02 inquiry stays distinct from L-01; repeating its event does not create another task
Business owner	Avery confirms the intake result; Jordan checks whether the eventual field handoff is usable
Open question	How often manual clarification is still required
Next review	Compare recorded handling time and incomplete requests over the agreed trial period

The finding produces a decision and a way to examine it. It does not turn a rough time estimate into a financial return or require a custom build to make the audit worthwhile.

What should determine the audit's cost?

Ask the provider to explain the work behind the quote. The number of connected systems can matter, but it is not the only driver. One poorly understood handoff may require more investigation than several straightforward ones.

Scope question	Why it affects the engagement
How many workflows are included?	Each needs a defined beginning, end, and set of exceptions
Who needs to participate?	Interviews and conflicting accounts require time to resolve
What evidence is available?	Missing records or inconsistent counts may need additional investigation
Which technical questions must be answered?	Connector availability, data relationships, or existing configuration may require targeted checks
What output is promised?	A recommendation, a detailed build specification, and a working pilot are different deliverables
What happens after delivery?	Clarifications, implementation, and ongoing monitoring should have explicit boundaries

Compare quotes on those terms before comparing totals. Ask what would trigger additional work and how that change would be agreed. A proposal should also make subscriptions, usage charges, and implementation costs visible where they are relevant.

For Wallace Shift's current engagement and price, use the automation pricing page. Its audit traces repeated work, calculates its cost, identifies failure points, and returns a prioritized plan. A workflow build and ongoing managed automation have their own scopes.

If the recommendation leads to a CRM project, use the CRM implementation budget to estimate that separate work, including migration, connections, and ongoing operation.

Use this audit acceptance worksheet

Use the 07 Automation audit sheet in the business systems worksheets (XLSX) for a working copy. The workbook contains fictional examples and space for your own inputs.

Copy the table and fill it in for each important finding. It can help you evaluate a proposal before the audit and review the result afterward.

Question	Your evidence or answer
Which decision does this finding support?
What real examples were examined?
What happens today, including exceptions?
Which counts and times are measured, estimated, or unknown?
What is the recommended first change?
Could configuration, a manual improvement, or deferral be preferable?
What would demonstrate that the change works?
Who owns the decision and the resulting process?
What implementation or ongoing costs remain to be quoted?
What important question is still unresolved?

A finding can be valuable while leaving an uncertainty open. It should explain what evidence would resolve that uncertainty and whether it affects the next decision. A confident answer with no supporting record is less useful than an honest, bounded recommendation.

Frequently asked questions

Is an automation audit the same as a sales consultation?

A consultation may establish whether the problem fits a provider's services. A paid audit should have an agreed investigation and deliverables. Ask what you receive, what participation is required, and whether implementation is a separate decision.

Should an audit always recommend automation?

No. Clearer ownership, better forms, or configuration of an existing product may solve the problem. An audit can also show that a low-volume task does not justify the work of automating and maintaining it.

Does the audit include a finished integration?

Only if that is expressly included. Mapping a connection, checking its feasibility, and implementing a production workflow are different activities. Read the stated deliverables rather than inferring a build from the word “automation.”

How is this different from planning a custom CRM or an AI project?

A CRM definition may examine broader records, permissions, and workflows. An AI task needs sample inputs and a way to judge its output. Wallace Shift scopes those needs explicitly; a standard automation audit should not be assumed to include an entire system design or complex AI implementation.

Bring one repeated process to the conversation

Choose the work you want to understand, collect a normal example and an awkward one, and note who handles them. Wallace Shift's paid automation audit provides a starting point for deciding what to configure, connect, improve, or leave alone.