Work Understanding: Automation opportunities
Objective. Open the automation-opportunities view, read a candidate as an estimated opportunity with assumptions, and avoid presenting it as booked savings.
This screen ranks steps that look automatable by their estimated time or cost opportunity. It answers 'where might automation pay off first?' - a hypothesis to validate, not a savings figure to bank.
See it in the demo
What this screen answers
The customer question is: of all the repetitive, rule-like work we observed, which steps are the strongest candidates to automate first, and roughly how much time might that free? Sales and CSM people open it when a prospect wants to point automation budget at the right target instead of the most visible one.
The value is prioritisation. It replaces 'automate what someone complained about' with a ranked list of candidates grounded in observed step time and repetition. Lead with that framing, because the next sentence has to be the honest one about what the numbers are.
The task
- Open the automation-opportunities screen from the overview.
- Scope to one process and period so candidates are comparable.
- Open one candidate and read its evidence: what step, how repetitive, how much observed time it consumes, and why it looks automatable.
- State the integrity line: 'this is an estimated opportunity under stated assumptions - a candidate to validate with a scoped test, not savings we have booked.'
Describe the opportunity at the level the data supports. Do not invent automation-rate percentages, payback figures or control labels you have not been given.
How to read it
An opportunity figure is an estimate built on assumptions - typically observed time on the step, how often it recurs, and an assumed share that automation could remove. The classic misread is treating that number as money already saved. It is not; it is a modelled upper-ish bound before feasibility, exceptions, build cost and change management.
Two more traps: automatable in principle is not automatable cheaply, and overlapping candidates cannot be summed - two steps may share the same waiting time, so fixing one absorbs part of the other. Read each candidate as 'worth scoping', then rank by evidence strength, not by headline size alone.
Honest limits
This screen does not prove that automation is feasible, cost-effective, or that the modelled time will be realised. It does not account for build and maintenance cost, exception handling, or the fact that removing active-step time may not move cycle time if the real delay is waiting.
Confirm with product how candidates are scored and what assumptions sit behind the estimate. Realised benefit comes only from a scoped before/after in the improvement workspace against the customer's own baseline - never report a modelled opportunity as achieved savings.
Interpretation check
An automation opportunity is an estimate under stated assumptions, not booked savings. Candidates must be validated with a scoped before/after, and overlapping candidates cannot be added together.
In the field
In RCM, an automation list often highlights data entry; the honest move is to check whether days-in-AR actually sit there or in waiting for payer response, so budget targets the step that moves the outcome.
Practical task
On the demo automation-opportunities screen, pick the top-ranked candidate for one process, write down the assumptions its estimate appears to rest on, and draft the one-line validation test you would run before quoting any savings figure.
Self-check
The screen shows a candidate worth '200 hours a month'. A prospect asks if that is guaranteed savings. What do you say?
No. It is an estimate built on observed time, recurrence and an assumed automatable share - before feasibility, build cost and exceptions. Realised savings come only from a measured before/after against their baseline.
Three candidates each estimate 2 hours. Can you promise 6 hours?
No. Candidates can overlap on the same time, and fixing one may absorb another. Estimates are not additive; de-duplicate and validate before claiming a combined number.
Why might automating a high-ranked step not move cycle time?
If the real delay is waiting between steps rather than the active step, removing active-step time barely changes total cycle time. Check whether the candidate sits on the actual constraint.
What converts an opportunity into a defensible claim?
A scoped experiment in the improvement workspace: baseline, the single change, re-measure against the customer's own baseline. Opportunity is the hypothesis; released time is the result.
Verified vs demo. Screen is live in the demo at /#/automation; exact controls, scoring logic and figures are SME-validation-pending, and the estimate's assumptions must be confirmed with product and tested against the customer's baseline.