Automation agencies: what a useful audit delivers

When an automation agency proposes an audit, the question is not whether it is enthusiastic, but what you will receive at the end. A useful audit is a measured document: a sample of observed processes, timed durations, an access review, a list of exceptions, a cost estimate and an assessed technical feasibility. It must also tell you, sometimes, that a process does not deserve to be automated. Here is how to judge this deliverable and how to request it.

Why an audit must stay measured and non-commercial

Many automation agencies use the audit as a commercial entry point: three tasks are observed, the conclusion is that everything can be automated, and a package is proposed. This scheme reverses the logic. The audit exists to produce a decision, not to justify a sale. An SME manager should therefore require that the final document contain verifiable figures and the possibility of negative conclusions.

A measured audit is recognized by three signs. First, it distinguishes what was observed from what was estimated. Second, it documents at least one case where automation is not recommended, with the reasons. Finally, it clearly separates implementation costs from operating costs. If the document you are handed contains none of these three components, you have received a brochure, not an audit.

The sample: what is observed and what is not

No one can audit all the processes of an SME in a few days. A serious audit therefore announces a sample: for example, four processes observed, chosen with you according to explicit criteria — frequency, number of people involved, variability of cases. What matters is that the report states the sample size and the selection method, so that you know what remains in the blind spot.

For each process in the sample, the deliverable must describe the trigger, the steps, the tools used, the people involved and the exceptions encountered during the observation period. If you want to go further on this preparatory step, process mapping before any connection naturally complements the audit work. A sample of four processes says nothing about the other twenty: that is normal, provided the report explicitly states it rather than generalizing.

Time tracking: measuring the time actually spent

The core of the audit is the measurement of time spent. It must be done by direct timing or by structured logging, not by self-reported estimation. A person who estimates spending "an hour a day" on a task often actually spends noticeably more or less. The report must present, for each observed process, the median duration and the duration of atypical cases, over a defined period.

Let's take a hypothetical example, purely to illustrate the format: an administrative file tracked over two weeks reveals a median duration of twelve minutes per file, but disputed files that take forty minutes. The average is misleading; it is precisely this type of gap that the audit must highlight, because it determines which parts of the process are worth automating. To go deeper into the measurement method applied to emails, see how to measure the time actually saved on emails. A measured time without the context of exceptions is useless: automating the easy twelve minutes without addressing the difficult forty minutes produces a small gain.

The state of access and permissions

An audit must document which accounts, tools and permissions would be needed for each process under consideration. This is often where surprises hide. A concrete example from the documentation: the Gmail scopes gmail.compose and gmail.modify can also authorize sending messages. Limiting an agent to drafts therefore requires an application-level control, not just a scope choice. Similarly, a Gmail label is not a permission boundary: the fact that a folder is labeled "internal" does not mean an agent cannot read it.

The audit must also distinguish three things that are often confused: the transport connection (can the agent reach the tool), the provider's authorization (is it allowed to act) and the proof of operation (can what was done be traced). A tool-exchange protocol like MCP makes it possible to connect tools and context, but it does not choose the business rules or the permissions for you. If the audit mentions MCP, it must specify which rules remain to be defined on your side. The documentation of Gmail authorization scopes shows how much the actual granularity of permissions deserves careful reading before any integration promise.

Exceptions: where processes break

A process is judged by its edge cases. The audit must list the exceptions observed during the period: incomplete files, duplicates, missing information, unforeseen human interventions. These exceptions determine the real technical feasibility of an automation, far more than the number of steps in the nominal path.

A good deliverable classifies exceptions into three categories: those a system can handle with an explicit rule, those that require human validation, and those that remain out of reach. This classification directly feeds the prioritization matrix presented below. If the audit mentions no exceptions, be wary: either the observation period was too short, or the observer did not look at the difficult cases.

Technical feasibility and risk

Technical feasibility measures the gap between the current state of the tools and what an automation would require. Three questions summarize it: is the data accessible through a stable interface, are the identifiers reliable over time, and are the actions reversible in case of error. On the latter point, the documentation is instructive: the identifier of a Gmail draft is stable, but the identifier of the message it contains changes with each modification — a system that caches identifiers must therefore anticipate this behavior. Similarly, Calendar allows creating events with explicit identifiers, but does not guarantee a global transaction with your own system: if a failure occurs halfway through, the audit must describe the recovery procedure.

Risk, meanwhile, combines three dimensions: the impact of an error (an erroneous draft costs little, an erroneous send costs more), the frequency of ambiguous cases, and the dependency created on a tool or a provider. A high-volume process with a low error impact does not have the same profile as a rare but irreversible process. The audit must position each process on these two axes rather than giving a single score.

The expected cost: implementation and operation

The audit must estimate two distinct costs. The implementation cost: design, development, testing, training. The operating cost: tool subscriptions, API consumption, maintenance, handling of error cases. A hypothetical example to set the scene: a customer follow-up automation could cost, purely illustratively, a few days of implementation and a modest monthly subscription, but add a variable cost per message if it goes through a channel billed by usage. On the WhatsApp Business Platform, Meta's pricing is set per delivered message, depending on the category and the market, and not all messages are chargeable: the 24-hour service window, reopened by a message from the user, changes the picture. A serious audit refers to the official platform pricing rather than putting forward a fixed figure.

Beware of invisible costs: every automation adds a surface to monitor. If a process touches personal data, the audit must recall the main principles of data protection to integrate from the design stage — minimization, retention period, security. These reminders are design recommendations, not proof of compliance: the responsibility remains yours. To place these amounts in a broader reflection, the full cost of an AI agent details the items that are often forgotten.

A prioritization matrix on four fictional processes

The central deliverable of an audit is a matrix that ranks the audited processes. Here is an entirely fictional example, with illustrative values, to show the expected format. Four processes, rated from 1 (low) to 5 (high) on each criterion: annual recoverable time, technical feasibility, error risk, frequency of exceptions.

Fictional process	Recoverable time	Technical feasibility	Error risk	Exceptions	Reading
Preparing follow-up drafts	5	4	2 (drafts reviewed)	2	Priority
Entering quotes into the invoicing tool	4	3	3	4	To be scoped first
Scheduling field interventions	3	2	4	5	Not automatable as is
Archiving supporting documents	2	4	1	2	Gain too small

This matrix illustrates three lessons. The first: preparing drafts combines a high time saving with contained risk, because a human reviews before sending — this is the ideal profile. The second: field scheduling has a decent recoverable time but frequent exceptions and a high risk; full automation would fail, even if partial rescheduling assistance could be considered later. The third: archiving is technically easy but the annual gain does not justify the maintenance.

The limits of the scores must be explicit in the audit. A technical feasibility score depends on the current tools and your actual access, not on a general truth. A risk score reflects the exceptions observed in the sample, not all possible exceptions. And the weightings — should time be prioritized or risk minimized? — are a management choice, not a calculation. Require that the report document the chosen weightings and what would change with others.

The expected deliverables, piece by piece

A complete audit should contain, at minimum:

• A description of the sample and the selection method.
• For each process: the time tracking, the steps, the tools, the classified exceptions.
• The state of the access and permissions required, with the limits of each tool.
• The prioritization matrix, with its weightings and its limits.
• A cost estimate in two parts: implementation and operation.
• An explicit list of non-recommended processes, with the reasons.

This last point deserves to be negotiated upfront. Some agencies hesitate to deliver a negative conclusion, for fear of reducing the next engagement. Yet knowing that a process should not be automated is information that saves you months. If you are comparing several providers, the decisive criterion is not the volume of the report but its ability to say no — a point developed in comparing AI agent agency proposals. Choosing an agency and conducting an audit are two distinct decisions: the audit can, moreover, be carried out by a neutral third party if you want to avoid any conflict of interest.

The decision not to automate

Declining to automate is a management decision like any other, and the audit must facilitate it. Three typical situations, drawn from the logic of the matrix: the hourly gain is too small relative to the maintenance cost; the exceptions are too frequent for a reliable system to exist; the process is changing for business reasons, and automating it now would freeze a transitional organization.

In these cases, the audit must propose a measured alternative: simplify the process manually, train the people involved, or revisit the question in six months with a quantified review criterion. For example, on a hypothetical end-to-end file-tracking process, the audit may conclude that only two of the seven steps are worth tooling, the rest being a matter of human judgment that is too variable. This partial conclusion is more useful than a global project destined to be abandoned. Reading the complete journey of an automated case file shows, moreover, how many intermediate steps resist tooling.

A procedure for exploiting the audit you receive

Once the report is in your hands, here is a five-step approach to turn it into a decision:

1. Check the sample: ask why these four processes were chosen and what makes the non-audited processes different.
2. Recalculate a figure at random: take a timed duration, multiply it by the stated frequency, and compare with the estimated gain. An inconsistency here often hides others.
3. Test an access claim: for a tool you know, check what the stated permissions actually allow.
4. Challenge the matrix weightings: change one and see whether the ranking holds. If it collapses, the prioritization was fragile.
5. Isolate the decision not to automate: validate it first, because it is the one that costs the least to confirm and protects your budget the most.

This procedure takes half a day and turns a passive document into a decision-making instrument. If the agency refuses to justify a figure or a weighting, that is information about the rest of the relationship, not just about the audit.

If you would like to define an audit engagement with explicit deliverables, present your context and the processes you are considering tooling.

Frequently asked questions

How many processes should an audit cover?

There is no universal number, but the report must state the sample size and the selection method. Four to six processes observed seriously are worth more than fifteen skimmed over. What matters is that you know precisely what was examined and what remains to be explored.

Can an audit conclude that no automation is profitable?

Yes, and that is a perfectly valid conclusion. If the measured times are low, the exceptions frequent and the operating costs high, the audit must say so clearly. You will then have paid to avoid a mistake, which is often the best expense of the year.

Should the audit be carried out by the agency that will then automate?

It is possible, but it creates a conflict of interest: the auditor is judging a project they would be tasked with selling. If you go through the agency, require documented negative conclusions and verifiable figures. A neutral third party remains the safest option for a first audit.

What should I do if the audit mentions no exceptions?

Ask how atypical cases were handled during the observation. A process without exceptions is either very simple or poorly observed. Without this list, the prioritization matrix rests on the nominal path only and overestimates the real technical feasibility.

Are the audit's cost estimates reliable?

They are estimates, not commitments. A serious audit presents ranges, distinguishes implementation from operation, and refers to the official pricing of the tools concerned for the variable part. Treat them as orders of magnitude to be refined during detailed design, never as a firm price.