Stress-test a process before I automate it

I'm about to automate this: [THE PROCESS, STEP BY STEP AS IT CURRENTLY RUNS]

Who does it now: [PERSON OR ROLE]
How often: [FREQUENCY AND VOLUME]
What happens downstream: [WHO OR WHAT DEPENDS ON THE OUTPUT]

Before I build anything, find what breaks.

1. THE HUMAN JUDGEMENT I HAVEN'T NOTICED. Go through my steps and find where the person is quietly deciding something rather than following a rule. Exceptions they handle without mentioning, things they check because experience taught them to. This is where automations fail, and it never appears in the description of the process.

2. THE INPUTS THAT AREN'T AS CLEAN AS I THINK. For each input, what does the messy real version look like? Missing fields, inconsistent formats, someone typing a note in a number field.

3. WHAT HAPPENS WHEN IT FAILS AT STEP N. Walk each step and tell me what state things are left in if it dies there. Half-done is usually worse than not-done, and that asymmetry decides where the checkpoints go.

4. THE SILENT FAILURE. The way this breaks without anyone noticing — right shape, wrong content. Empty results, stale data, a default value passing as real. Then tell me what to monitor to catch it.

5. THE VOLUME QUESTION. At my stated frequency, is this worth automating at all? Compute a rough time saved against build-and-maintain cost. If the answer is no, say no — that's a valid and useful outcome.

6. WHAT TO AUTOMATE FIRST. If I only automated one step, which gives the most benefit for the least risk?

Assume I am overestimating how standardised this process is. I almost certainly am.