Business Workflow Audit Checklist

Before you start

Pick one workflow. Give it a plain-language name that everyone on the team recognizes ("customer onboarding," "monthly invoice preparation," "field-service dispatch"). If the workflow spans multiple obviously distinct sub-workflows, split them and audit them separately.

Interview the person or people who actually run the workflow. Do not audit from the perspective of the person who designed it or the person who reports on it. Both views are useful later, but the operator's view is where the real steps live.

1. Process owner

• Who is accountable when this workflow fails?
• Who is the working owner day to day?
• If the owner is unavailable, who runs it?
• Is the ownership formal (documented) or informal (understood)?

If there is no clear owner, the workflow is not ready for automation. Fix that first.

2. Trigger

• What starts this workflow? An event, a schedule, a request, a threshold?
• How does the owner know it has started?
• Are there triggers that get missed today?

3. Inputs

• What information is required to run the workflow?
• Where does that information come from?
• Is it complete when it arrives, or does the owner have to gather missing pieces?
• Which inputs are the most common source of delay?

4. Outputs

• What does the workflow produce?
• Who consumes each output?
• What form is the output in — a record, a document, a message, a report?
• Is there a definition of "done" that everyone agrees on?

5. Systems involved

• List every system the workflow touches, in the order it touches them.
• Note whether the workflow reads from the system, writes to it, or both.
• Identify the system of record for each key data point (customer, invoice, ticket, etc.).
• Flag any system that is used because "we've always used it," not because it is the right one. Where integration between systems is the blocker, the systems integration question usually needs its own review.

6. Handoffs

• Where does the work move from one person, team, or system to another?
• How is each handoff communicated (email, chat, ticket, verbal)?
• What is the average and worst-case delay at each handoff?
• Where does work get lost between hands?

7. Exceptions

• What are the common variations from the normal path?
• How often does each variation occur?
• Who decides which path to take, and on what basis?
• Are there exceptions that no one wants to admit exist?

8. Approvals

• Where are approvals required?
• What is the approval based on (a rule, a budget, a judgment call)?
• Who is the approver, and who is the backup?
• How long does a typical approval take?

9. Delays

• Where does the workflow wait?
• Is the wait for a person, a system, an external party, or a schedule?
• Which delays are inherent and which are avoidable?

10. Rework

• Which steps are repeated because an earlier step was wrong or incomplete?
• What is the most common cause of rework?
• Is rework tracked, or does it disappear into the normal workload?

11. Access requirements

• Who has access to each system involved, at what permission level?
• Are there people running the workflow with more access than they need?
• Are there people running the workflow with less access than they need, requiring workarounds?

12. Data sensitivity

• Does the workflow handle personal data, financial data, health-related data, or contractual data?
• What is the retention policy for that data?
• Are there regulatory obligations (privacy law, sector-specific rules) that constrain how the workflow can be changed?

13. Reporting

• What reports depend on this workflow's outputs?
• Who reads those reports?
• Are the reports accurate today, or are they patched with manual adjustments?

14. Audit trail

• Is there a record of who did what, and when, at each step?
• Would the record survive a question three months later?
• Where are the gaps? Northbridge documents its own trust practices for the same reason clients need answerable audit trails.

15. Desired outcome

• If this workflow were working the way it should, what would be different?
• Measured how — faster, fewer errors, less manual entry, better records?
• What is the smallest change that would deliver most of that outcome?

What the checklist does not do

The checklist is designed to structure a conversation and produce a written baseline. It is not a substitute for technical assessment. It does not answer questions such as:

• Which specific tools can actually be integrated with each other?
• Whether a given automation is feasible under the vendor's API terms.
• How much effort a specific change will require.
• Whether the process should be redesigned before being automated.

Those questions require technical assessment. Do not skip them because the checklist felt complete. A well-documented audit combined with a short technical review is far more useful than either one on its own. If a specific workflow surfaces during the audit, the companion article on when to automate a business process covers how to decide whether that workflow is ready.

How to use the output

Once the audit is filled in, three things become easier:

• Decide whether to change anything at all. Some workflows look painful from the inside but audit cleanly. Others look fine from the outside but are held together by a single person's memory.
• Prioritize where to invest. The categories with the most rework, longest delays, or highest error cost are usually the right first targets.
• Brief an outside partner efficiently. A completed audit turns a vague "we want to automate onboarding" into a specific, scoped conversation — whether that leads to Northbridge engineering services or a request a proposal for a broader engagement.

A reasonable next step

If the audit surfaces a workflow that seems like a real automation candidate, Northbridge offers a fixed-scope Workflow Review. It produces a written assessment of one workflow, identifies up to three prioritized automation opportunities, and recommends a concrete next step. The Workflow Review is delivered within three business days after complete intake for $149 USD.