We don’t quote from a form.

These are the questions we would ask on a call, published so you can answer them before there is a call.

Workflow complexity.

How many paths the work can take, and how strange the strange ones get. A process with a clean path and rare exceptions is a different engagement from a process where the exceptions are the job.

System access.

Whether the systems the workflow runs in can be reached, and how. A documented interface with a sandbox behaves nothing like a screen somebody has to read inside an application nobody holds credentials for.

Data boundaries.

Where the records in this workflow are allowed to go, and whether anyone has already answered that. Constraints that are written down and owned move quickly. Constraints that have to be discovered, argued, and approved mid-engagement are the ones that stretch it.

Decision authority.

Who can approve a change to the process, and whether that person is in the room. Authority spread across departments is not the same work as authority held by the person who owns the queue.

Acceptance criteria.

How sharply “working” can be defined before work starts. A workflow with a clear pass or fail is cheap to accept. A workflow where correctness is a judgment call needs that judgment written down first — and writing it down is part of the engagement.

Operating support.

What has to happen after it runs. A workflow somebody watches every morning and a workflow that files itself away are different commitments, and the difference shows up in scope long before it shows up in operation.

These are not line items that stack. Tight data boundaries alongside clear decision authority is a manageable engagement. Tight data boundaries alongside authority spread across departments is a different engagement entirely — every constraint has to be re-approved by somebody new, and the approvals become the critical path.

It works in your favor too. Sharp acceptance criteria make complexity cheaper to carry, because everybody can tell when the work is finished.

It starts in writing. You name the workflow and describe where it breaks; we read that before anyone spends time on a call. The point is that the call is about your process rather than about qualifying you.

From there, the conversation goes after the exceptions first — the clean path is rarely where the scope lives. We ask who can say yes to a change, which is not always who runs the process. We ask what “working” means to you, and we write the answer down. Then we tell you what we would need from your side: access, records, and time from your people.

We also tell you when it isn’t a fit. A workflow that isn’t ready to be mapped is a much cheaper thing to hear about now.

You can make this cheaper. Bring the exceptions rather than the process document. Bring the person who can authorize a change. And bring a version of “done” you would be willing to sign.