A process automation consultant should help you decide what to automate, what to leave with people, and what evidence a later build must satisfy. The useful output is not a software demo or a company-wide maturity score. It is a decision-ready pack for one workflow: current-state map, baseline, owners, system and access boundaries, acceptance method, exception path, and a recommendation to build, buy, redesign, or stop.
This guide is for Australian operations leaders assessing business workflow automation. It does not cover industrial control systems, and it is not legal, privacy, cyber security, or procurement advice.
What the role should do
The role sits between operations analysis and implementation design. A consultant observes how one job moves, checks the records that prove its current state, identifies where people use judgment, and specifies the boundaries a tool or build would need.
That work is different from choosing a platform first. A platform specialist may be the right person once the workflow and constraints point to that platform. Before then, a tool-neutral consultant should be able to recommend a simpler product, a process change, a controlled build, or no automation at all.
The broader AI automation agency guide covers how to assess a delivery firm. This page stays with the consultant’s pre-build artefacts and decision.
The Process Automation Consultant Evidence Pack
Use this as a review sequence, not a weighted score. Each item either has inspectable evidence or it does not. A polished slide cannot compensate for a missing workflow owner, access boundary, or acceptance method.
1. One bounded workflow
Evidence to expect: a start event, finish event, system of record, normal path, exception paths, excluded cases, and the roles involved. The map should describe how the work runs now, including workarounds, rather than copying an ideal procedure.
Hold or stop when: the scope is a department, a broad objective such as “automate operations”, or a list of tools with no named job. Process mapping should be the first artefact because the later access, test, and recovery decisions depend on the actual handoffs.
2. A reproducible current-state baseline
Evidence to expect: a named measure, source fields, period or sample, exclusions, assumptions, and the person who accepts the method. Useful measures might cover elapsed time, human touch time, rework, exceptions, or queue volume, but the choice depends on the workflow.
Hold or stop when: the baseline is a round estimate from a meeting, a percentage with no source, or a modelled saving presented as an observed result. Unknown is a valid finding. It tells the buyer what must be measured before a benefit claim can be tested.
The AI readiness assessment uses the same principle: a missing gate is a reason to hold, not a score to average away.
3. Named owners and decision rights
Evidence to expect: the business owner, system owner, operators, exception reviewers, access approver, and the person who may pause the workflow. Record what each role can approve, not just a list of meeting attendees.
The National AI Centre’s implementation guidance asks organisations to document accountability across the AI supply chain and to define oversight for testing and operation. A consultant can use those prompts without claiming that one template fits every organisation.
Hold or stop when: ownership belongs to a committee with no operator who can accept exceptions, grant access, or order a pause.
4. An identity and integration contract
Evidence to expect: every source and destination system, the application owner, approved environment, authentication method, permission scope, event or polling trigger, fields read and written, retry rule, duplicate-prevention method, timeout, and revocation path.
This is where a vague proposal becomes buildable. “Connect the CRM” is not a contract. “Read these fields after this event, create a draft through this application identity, and route failed or duplicate writes here” is closer to one.
For OAuth integrations, the IETF’s current OAuth 2.0 security recommendations include restricted token privileges and stronger protections for authorization flows. The consultant does not need to redesign the standard, but should identify which system owner will approve the flow and how it will be tested.
Hold or stop when: the proposed automation shares a human login, requires broader access than the job, or leaves application registration and test access as an unnamed future task.
5. A data and source register
Evidence to expect: the records the workflow may use, the purpose of each field, the authoritative source, the destination, test-data method, retention boundary, and any material classification or contractual restriction that needs specialist review.
Hold or stop when: the team cannot trace a field from source to action and log, or when a demo depends on copying sensitive production material into an unapproved account.
The consultant should identify the decision and the accountable reviewer. They should not invent a privacy, security, or legal approval that belongs to a qualified owner.
6. Acceptance cases and human stops
Evidence to expect: representative normal cases, missing or conflicting records, prohibited actions, unavailable-system cases, expected outputs, reviewer, version, and a stop rule for each material exception. For AI-assisted steps, include the sources the system should use and behaviour that must never pass.
NIST’s Generative AI Profile recommends testing and evaluation across generative AI data and content flows. The National AI Centre guidance likewise calls for defined acceptance criteria and pre-deployment testing. These sources support a test discipline; they do not establish that a model will be correct.
Hold or stop when: acceptance means a handful of favourable demos, or an uncertain case can continue without an accountable person. The later AI agent implementation checklist expands these production gates after a workflow has been accepted for build.
7. An operating, handover, and rollback boundary
Evidence to expect: logs an operator can read, alert ownership, failure and partial-write recovery, support boundary, change approval, tests that rerun after a change, runbook, access-removal procedure, and rollback evidence. Build completion, user acceptance, production deployment, and stable operation are separate states.
The Australian Signals Directorate’s agentic AI guidance recommends fine-grained identity and privileges, human control points, monitoring, auditing, and reversibility. Apply the relevant controls to the workflow and its risk rather than treating the list as a generic certification.
Hold or stop when: the proposal ends at go-live, nobody owns failed work, or access and behaviour cannot be reduced without rebuilding the system.
Turn the pack into a decision
Use three states:
- Proceed to a bounded implementation. The pack identifies one stable workflow, accepted baseline, owners, access and data boundaries, representative cases, human stops, and an operating path. The implementation still needs its own acceptance evidence.
- Hold and close a named gap. The workflow may be suitable, but an owner, source, access path, sample, acceptance case, or recovery method is missing. Name the artefact and decision-maker required before reconsidering it.
- Stop, redesign, or buy something simpler. The work has low repeat volume, unstable rules, no accountable owner, no lawful or controllable data path, or a suitable product already covers the requirement with less operational burden.
Do not total the seven items into a readiness percentage. A missing revocation path is not cancelled out by a strong process map.
Questions to ask before hiring the consultant
- Which single workflow will your engagement decide, and what is explicitly outside it?
- How will you reproduce the current-state baseline from our records?
- What will the final pack let another qualified delivery team do without you?
- Who must own application registration, permissions, test access, exceptions, and a production pause?
- Which cases will you use to test the normal path, the exception path, and prohibited actions?
- What finding would make you recommend a product, a process change, or no automation?
- How will you separate a completed build from accepted behaviour and stable production operation?
A consultant does not need to promise the answer on the first call. They should be able to explain the evidence required to reach it.
When Workflow Scoping is the next step
If you can name one repeated workflow but do not yet have this evidence pack, Workflow Scoping is Svolta’s sole commercial path for producing the current-state map, baseline, ownership and risk boundaries, and decision-ready scope. The service page remains the source for current deliverables, terms, and pricing.
The useful outcome may still be a hold or stop. That is part of the consultant’s job: make the decision inspectable before a build turns assumptions into production dependencies.