How to define a unit of work before you price the automation.
Teams get stuck when they try to price a workflow around tool access, seats, or vague 'automation coverage.' The cleaner model is a completed unit of work with an explicit exception boundary.
A usable unit of work is the smallest completed business outcome that leadership, operators, and finance all agree counts as done and can measure the same way every month.
Start with the finished business outcome
Do not start with the tool action. Start with the business record or workflow state that matters after the work is complete.
For AP, that might be an invoice posted with approvals and evidence attached. For onboarding, it might be an account fully activated and handed off to the owner.
- •Name the record or status that marks completion.
- •Define which system is the source of truth for that completion state.
- •Avoid units like 'automation run' or 'agent task' that finance teams cannot tie to business value.
Draw the exception boundary early
A unit of work is only useful if everyone knows what is included and what stays human.
If new vendors, policy exceptions, or ambiguous records require review, say that up front and keep them outside the completed unit until the workflow handles them cleanly.
- •List the triggers that block auto-completion.
- •Define who owns each exception class.
- •Make sure the workflow logs why the item left the straight-through path.
Tie the unit to a measurable financial model
Once the outcome and exception line are clear, pricing and ROI get much simpler. You can measure baseline cost per unit, cycle time, and error rate against the automated version.
That is what keeps pricing tied to delivered throughput instead of headcount or platform usage.
- •Measure current cost per unit before anything changes.
- •Track exception share separately from straight-through completion.
- •Keep the first pilot narrow enough that the unit stays stable during rollout.
Clarify the operating model before the rollout starts.
It can, but most early pilots move faster when there is one primary completed outcome and a separate tracked exception pool.
If operators, leadership, and finance would each answer 'what counts as done' differently, the unit is not ready yet.
Yes, but it should change only when scope changes materially. Otherwise you lose comparability and pricing trust.
Keep the content path commercial and concrete.
Want the workflow map behind the content?
We can map the real process in your stack, show where the exceptions live, and scope the first workflow without starting with a platform rollout.