Process audit checklist before automation

Define the process boundary

Describe the process from a concrete trigger to a concrete outcome. “Automate sales” is too broad: it includes advertising, intake, qualification, proposals, payment, and retention. A first audit should choose one route, such as a new request reaching an accountable manager.

A boundary protects the project from endless expansion. Record adjacent needs separately instead of mixing them into the current result. That makes impact, ownership, and estimation much clearer.

Write down the starting event, final state, and stopping conditions. When participants disagree on where the process ends, resolve ownership before writing code.

• What triggers the process: a request, document, payment, or status change?
• Which outcome counts as complete?
• Which adjacent tasks are intentionally outside the first version?
• Who can change the boundary and accept the result?

Walk through real examples

Interviews are useful, but people often describe the intended process rather than actual work. Reconstruct several completed cases from messages, statuses, files, and logs. This reveals real waiting, workarounds, and manual repair.

Include more than a successful case. Review missing data, duplicates, urgent work, owner changes, and an unavailable external system. Automation must handle more than the perfect route, so exceptions need to influence the estimate.

For each step, record the input, action, output, system, and person. When a decision is based on experience, ask for the signals. Some can become rules; others should remain human judgment.

Name the process owner and roles

The process owner is not necessarily a founder or developer. It is the person who can approve rules, set priorities, accept trade-offs, and confirm that the new route works for the business.

List operators, reviewers, and people who only need visibility. Automation may create a task automatically, but someone still needs to accept and complete it.

If two teams interpret one status differently, resolve it before implementation. Code will not remove the disagreement; it will encode one version and make it more expensive to change.

• Who approves rules and acceptance criteria?
• Who receives exceptions and overdue work?
• Who may retry, cancel, or correct an operation?
• Who keeps the process current after launch?

Inspect data and the source of truth

List the fields required for the process to continue. For each one, identify its source, format, valid values, and the system containing the authoritative version. If the same information is edited in several places, define synchronization or choose one source of truth.

Inspect a real sample rather than an empty schema. Look for missing fields, inconsistent date and phone formats, duplicates, old values, and free text where a category is expected. Data quality often affects complexity more than the number of fields.

Do not collect information just in case. Every field needs a purpose, retention decision, and access boundary. A smaller contract is easier to maintain, validate, and explain.

Build an exception catalogue

An exception is a situation where the standard route is unsafe or insufficient. Missing data may trigger an automatic request, while a payment conflict should go to a person. Separate technical retries from business decisions.

For each exception, record frequency, impact, owner, and next safe action. Rare high-impact cases do not always deserve automation. Fast handoff with complete context can be the better design.

Define recovery as well: how to retry without creating a duplicate, reverse an incorrect action, inspect state, and alert an owner. Otherwise the automation works only until its first failure.

• Missing, conflicting, or duplicated data.
• Unavailable CRM, API, email, or messaging service.
• Actions that require human confirmation.
• A retry after a partially completed operation.

Choose a test-rollout metric

The metric should exist before development starts. If the team does not know current cycle time or error rate, proving a result later becomes difficult. A small baseline sample is enough when the method stays consistent.

Choose a measure connected to the problem: cycle time, manual transitions, unanswered requests, entry errors, or document preparation time. The number of automated actions is not a business outcome.

Add guardrail metrics. Faster response with more incorrect routing is not a clear success. Review quality, exception rate, and manual correction alongside the primary measure.

Limit access, risk, and authority

Identify data that cannot enter an external service, operations with a high cost of error, and roles allowed to see each type of information. Integrations should receive the minimum access needed for their task.

For AI, define allowed sources, response format, prohibited claims, and actions that always require confirmation. A model should not have more authority than its narrow scenario needs.

Design manual operation and rollback. The team should know how work continues during an outage, how a function is disabled, and how to return to a verified state without losing data.

• Minimum required access for every integration.
• An audit trail for important actions and state changes.
• Human confirmation for critical operations.
• A manual route, backup, and rollback plan.

What the audit should leave behind

A useful audit ends with working artifacts: a process map, data contract, exception catalogue, integration list, metrics, and the boundary of a test rollout. They should be understandable to the business and precise enough for technical estimation.

Record open questions and assumptions separately. Do not hide uncertainty behind an exact budget or deadline. Explain what the test will verify and which decision follows it.

If the audit cannot name the owner, outcome, main risk, and measurement method, the process is not ready for implementation. Pausing at that point is usually cheaper than automating unclear agreements.