.png){kind=avatar}
A workflow is ready to automate when it has a clear owner and outcome, stable boundaries and rules, usable data, named exception paths, measurable volume, controlled access, and a safe fallback. Technology cannot resolve missing authority or an undefined process.
Use these 12 questions before configuring software. Each answer should include evidence, not just a yes or no.
Source review: August 28, 2026. This assessment supports operational planning and does not replace legal, security, compliance, or procurement review.
1. Who owns the outcome?
Name one accountable business owner who can define success, settle process questions, approve policy changes, and accept the operating result. A project sponsor who cannot change the work is not enough.
Evidence: owner, decision rights, process operators, system owner, and escalation contact.
2. What outcome should improve?
Describe the result for the business and the people doing the work. “Automate approvals” is an activity. “Reduce incomplete vendor requests while preserving required reviews” is an outcome.
Evidence: outcome statement, current baseline, target measure, and constraints that must not worsen.
3. Where does the workflow start and end?
Define the trigger, first valid input, completion state, cancellation state, and handoff to another system or team. Unclear boundaries create duplicate records and invisible work.
Evidence: start event, end states, upstream and downstream owners, and out-of-scope cases.
4. Can the team state the rules?
Write routing, authority, validation, deadline, and escalation rules in business language. Separate policy from habit. If two qualified people interpret the same case differently, resolve the authority before automating it.
Evidence: approved policy clauses, decision table, authority matrix, and effective version.
5. Are the required inputs available and usable?
List each field, document, source system, data owner, format, validation rule, sensitivity, and retention requirement. Do not treat an attachment as structured evidence if the process depends on values buried inside it.
Evidence: data dictionary, sample records, quality findings, and source-of-truth decision.
6. Can every important state be named?
Draft, submitted, under review, returned, approved, rejected, cancelled, and failed are different states. A status should describe the current condition, not a vague team label such as “in progress.”
Evidence: state diagram, allowed transitions, transition authority, and terminal states.
7. Do exceptions have owners and paths?
Collect real exceptions: missing evidence, no available approver, disputed ownership, integration failure, duplicate request, urgent override, policy conflict, or changed facts. Decide whether each case stops, returns, escalates, or continues under a named authority.
Evidence: exception register, frequency, owner, decision, and service target.
8. Is there enough volume or consequence to justify change?
A low-volume process can still deserve investment if errors are costly, delays block important work, or evidence is hard to reconstruct. Record both frequency and consequence.
Evidence: request volume, handling time, wait time, rework, error rate, exception load, and impact of failure.
9. Is the current baseline credible?
You need a comparison point to know whether the new system helps. Sample actual cases rather than relying only on recollection. Separate active work from queue time and clean cases from exceptions.
Evidence: measurement period, sample size, definitions, missing data, and known limitations.
10. Are permissions and evidence requirements defined?
For each role, specify who can submit, view, edit, assign, approve, export, configure, and inspect records. Identify sensitive fields and required decision evidence. “The operations team has access” is too broad.
Evidence: role-permission matrix, data classification, decision record, and access-review owner.
11. Are integrations necessary for the first release?
Separate essential connections from convenient ones. For each required integration, name the data exchanged, system of record, trigger, authentication owner, failure state, retry policy, and reconciliation method.
Evidence: interface contract, test environment, failure owner, and manual continuity path.
12. Can the process continue safely when automation fails?
Define how operators identify a failure, stop repeated actions, continue urgent work, reconcile later, and communicate the incident. A spreadsheet export is not a fallback unless people know when and how to use it.
Evidence: stop trigger, manual procedure, recovery owner, reconciliation test, and communication plan.
Turn the assessment into one of four decisions
Redesign
Choose redesign when the outcome, boundary, ownership, or authority is unresolved. The GAO Business Process Reengineering Assessment Guide recommends understanding mission, performance problems, customer needs, and process constraints before selecting a solution.
Document
Choose documentation when the process works but rules, states, exceptions, or operating responsibilities live in people's memory. Build the runbook and collect a baseline before automation.
Pilot
Choose a limited pilot when the core process is understood but data, exception handling, adoption, or integration behavior needs evidence. Set an entry condition, scope, measurement window, and exit decision.
Automate
Choose automation when the answers are sufficiently clear, risks have owners, and the team can test and operate the result. Readiness does not mean zero uncertainty. It means uncertainty is visible and bounded.
Run the readiness review in Formaloo
Create a structured readiness form with one section per question. Require an owner, evidence link, confidence rating, issue, and next action for every answer. Use a table or Kanban Data Block to review gaps by workflow and owner.
When rules are drafted, use Formaloo's Logic map to inspect field conditions and paths. Use Advanced logic only after the business rule and exception path are approved. The map helps inspect configuration; it does not replace the policy, data dictionary, permission matrix, or runbook.
For approval processes, the approval policy template shows how to map authority clauses to fields, rules, states, evidence, and tests.
Review readiness as a group
Bring the business owner, frontline operator, platform owner, data or integration owner, and relevant security or risk partner into one review. Resolve contradictions in the evidence. Assign every open question. Record the decision and a reassessment date.
That meeting should end with a scoped next step, not a generic “automation opportunity.” A workflow that fails readiness has still produced value: the team now knows what must become clear before it builds.
Turn a ready workflow into a working system
If you want to assess a workflow and translate the result into a governed operational system, book a Formaloo demo.
