Ask a business process automation consultant for the rejected list. Not the roadmap. The rejected list shows whether discovery found the work that should stay manual, or merely produced a sales queue for the platform the consultant already wanted to install.
A useful rejection names the evidence: unstable policy, missing data, unresolved authority, dominant exceptions, weak volume, or a write that is hard to reverse. That record is the start of the purchase. It tells you whether the consultant can separate an automation opportunity from an attractive demo.
We’re gmware, a custom software development firm headquartered in Austin, Texas, with engineering centers in Bangalore and Mohali, India. We build automation around the systems clients already operate. We think an honest no-build memo tells you more than a backlog of imaginary savings.
Ask for the no-build memo
Each candidate should have a short disposition. Accept for design. Hold until the process owner settles a rule. Repair the source data, then reassess. Buy the native connector. Keep manual because the exception and reversal risk outweigh the volume.
Keep those decisions. They stop the same poor candidate returning next quarter with a new vendor logo. They also create a useful repair queue. Once an owner fixes the policy or data problem, the process can be measured again.
Here’s an opinion we’ll defend: exception rate matters more than task count. A thousand clean cases may be easy. Fifty cases with thirty undocumented judgment calls are not an automation win.
Observe before ranking
The procedure manual shows the intended route. The work queue shows what people actually do. Sample completed, returned, abandoned, urgent, and disputed cases. Watch handoffs. Count the reasons people leave the primary system for email or a spreadsheet.
Microsoft documents process mining as analysis based on event logs from systems of record and task mining as analysis of recorded desktop actions. That is one vendor’s implementation, not a requirement to use its platform. The useful principle is independent of product: current-state evidence should come from real cases, not workshop memory alone.
If the organization wants a formal process notation, the Object Management Group publishes BPMN 2.0.2 as a formal specification. A BPMN diagram can clarify events, gateways, and lanes. It still needs plain-language state definitions, data contracts, and exception ownership for the people who will run the workflow.
The ranking method should expose its inputs. Volume. Manual time. Wait time. Rework. Exception mix. Data readiness. Authority. Failure cost. Reversal path. A sponsor should be able to change one assumption and see why the order moved.
Turn the evidence into a purchase
“Find automation opportunities” is too loose for a statement of work. It permits weeks of interviews followed by a color-coded backlog you still have to build. That may be useful if you want strategy only. If you expect implementation, contract for implementation artifacts.
Name the process family and organizational boundary. State which systems can be observed, what data may be handled, and who approves access. Set the expected number of processes to assess, not the number to automate. Discovery may prove that every candidate should wait.
The engagement should distinguish recommendation, prototype, pilot, and production. A prototype that moves sample data is not a production workflow with scoped identity, retries, monitoring, support, and an owner.
Our AI workflow automation cost guide breaks the bill into discovery, integration, exception handling, and operations. The same split belongs in the SOW.
Put acceptance nouns in the SOW
“Included” is not an acceptance test. Name the artifact, evidence, and person who can accept or reject it.
| Deliverable | Minimum evidence | Acceptance question |
|---|---|---|
| Current-state record | Observed steps, cases, volume, wait, rework, exceptions, systems, owners | Can an operator point out where the record differs from reality? |
| Candidate dispositions | Scoring method, accepted and rejected candidates, risks, prerequisites, owner | Can the sponsor explain why process A advances and process B does not? |
| Boundary model | Start and end event, authority, data, credential, exception, prohibited action | Does the flow stop rather than invent policy? |
| Target design | State model, source and target contracts, identity, retries, readback, correction | Can engineering test each transition without a slide deck? |
| Working release | Deployed bounded flow, configuration, code or export, environment record | Does it run against approved production conditions? |
| Test packet | Happy path, missing data, duplicate, timeout, stale version, unauthorized action | Can a failed test block acceptance? |
| Operations package | Logs, alerts, dashboard, runbook, incident route, owner, service expectations | Who gets paged, and what can that person safely do? |
| Handoff record | Repository, accounts, credentials custody, documentation, training, backlog | Can your team operate and change it without the consultant? |
A vendor can propose a different artifact set. Fine. The problem is ambiguity, not naming. You need a checkable answer to what exists at the end.
Contract the operating tail
An automation becomes software the moment someone depends on it. The consulting engagement needs production duties: credential rotation, connector changes, failed-run handling, alert ownership, data retention, incident response, and change approval.
NIST’s Secure Software Development Framework is a set of high-level practices that can be integrated into a software development life cycle, and NIST says purchasers can use its common vocabulary in supplier communications. A workflow project is not certified by citing SSDF. The practical procurement question is which secure-development evidence the consultant will provide.
Ask where code and configuration live. Ask who owns vendor accounts. Ask whether your team receives exports, deployment instructions, dependency records, and test fixtures. Ask how secrets move at handoff. If the answer is “our platform handles that,” ask again with nouns.
Acceptance should include failure
Happy-path demos are table stakes. Acceptance testing should force a duplicate event, missing field, stale object version, denied permission, target timeout, partial downstream success, absent approver, and correction after an incorrect write.
For each test, define the allowed state, owner, caller message, retry behavior, evidence, and recovery step. A workflow that reports success before reading the target state has not completed the business action. It has completed an HTTP request.
Run a limited release with a named operator. Review exceptions frequently enough to learn. Expand only when the team can explain failures, recover them, and change the rules through an approved path.
The n8n build-or-buy guide is useful when the implementation choice narrows to a workflow platform and ongoing operator. The consulting SOW comes first because it defines the work the tool must support.
What gmware hands over
AutoPilot Workflow Automation is gmware’s bespoke automation offer across a customer’s existing tools. We scope the process, build the approved path, document it, and hand it over. That positioning does not guarantee unattended operation, fixed savings, universal connector support, or a fit for every process.
Bring one real process and five recent cases, including an ugly one. We’ll map the state, exception, owner, and system boundary before recommending a tool. Reach out and we’ll give you a direct scope, cost, and timeline answer within 48 hours.