Process design · honest scoping
The useful answer is usually which steps not to automate.
Describe something your business does by hand every week. You get back the steps as they actually happen, each one marked automate, assist or keep human — with the reason, and with what breaks when it breaks.
If you tell it how often the process runs and how long it takes, it works out the hours. That arithmetic happens in code, not in the model — it is the one number anybody checks, so it is a function with tests rather than a sentence an AI produced. Give it no volume figures and it gives you no estimate at all.
The steps, as they happen
Keep these human
What could go wrong
Needed before any of this can be built
What your description did not say
If only one thing gets done
What this is. A scoping document produced from a paragraph, in about a minute. It is a starting point for a conversation, not a quote and not a build plan — it has never seen your systems, your data or your team. What it is good for is arriving at that conversation with the process already written down.
Why it hedges
The sums are code
The model reads your process and classifies the steps. The multiplication happens in a tested function, because a model doing it silently is wrong occasionally and confidently.
No figures, no estimate
Without a frequency and a duration there is nothing to compute, so nothing is shown. Not a range, not an illustration.
Every step has a failure mode
A plan that only describes the happy path is a sales document. What happens when it breaks on a Friday night is the question worth answering.
Conservative on purpose
Automated steps are credited with removing 90% of their time, not 100%. Something still has to notice when it stops working.
The tools this connects already exist and can be tried: document extraction for the retyping steps, the support agent for the answering ones, the site check for the monitoring ones. Tell me which process is costing you most and I will say honestly whether it is worth building.