Ask a team what it wants automated and you may get a long list. That is useful. Choosing the first build is a separate decision: which task is repeated enough to matter and clear enough to improve safely?
A small process with a dependable result can be a better starting point than an ambitious system touching every department. Use the following checks to compare real work, not just ideas that sound impressive.
Can you describe a complete run?
Name the trigger, the information used and the finished output. Ask the person doing the task to show one normal example and one difficult example. If nobody can explain what correct looks like, understanding the process is the first piece of work.
Record frequency and hands-on time separately. A five-minute job repeated many times can deserve attention; a long annual task may be less urgent. Include the checking and correcting people already do, not just the obvious typing.
Are the rules stable and the inputs accessible?
Look for repeatable decisions and information the business is permitted to access. A missing identifier or inconsistent source may need fixing before it supports a dependable automation. Avoid assuming that a person making a judgement is following a rule that has simply not been written down.
Ask what changes from one run to the next. If the process is being redesigned next month, automating today's version may create avoidable maintenance. If only a few exceptions vary, a routine path with a clear review queue may still be useful.
Can the result be reviewed before it causes harm?
An assembled report or prepared draft is often easier to check than an automatic payment, deleted record or customer email. Consider the consequence of a wrong result and whether the first version should stop for approval.
Define what happens when an input is missing, a system is unavailable or the result looks unusual. Give the fallback to a named role. An automation is not ready simply because the happy-path demonstration worked once.
Is there an owner and a useful success measure?
Choose someone who can supply examples, answer questions and review the preview. Agree a practical measure such as preparation time, corrections needed or work completed on time. Include the effort of supervising the new process when comparing before and after.
WeekFound's completed reporting and quote projects are useful examples of specific tasks with visible outputs. Their results can help you think about your own work, but they should not be pasted into a forecast as guaranteed savings.
Bring the repeated task, not a finished technical brief
For your shortlist, write one sentence about the work, how often it happens, where the information lives and who uses the result. Add an example that went wrong. That gives a builder enough context to ask sensible questions and assess the next step.
If reporting is the first candidate, WeekFound's reporting readiness checklist gives you a more detailed way to prepare. Otherwise, tell us what keeps taking your team's time. The aim is one dependable improvement you can evaluate before widening the scope.