Most people picture automation needing spotless data: no typos, no gaps anywhere. That's rarely the real requirement. What actually matters is whether the process has a definable shape and the inputs have some consistent structure, meaning the same rough fields show up in the same rough place each time, even if the values inside are messy. A system reading a spreadsheet with three different date formats, or a lead form with an occasional missing phone number, can absorb that. Normalizing formats, flagging outliers, and asking a person to fill in a gap the system genuinely cannot fill is part of what gets built, not a precondition for building it.
What actually stops a workflow from being automated is different. If the process lives only in someone's head and has never been written down step by step, that has to get mapped before software can run it. If the data doesn't exist at all, say nobody has ever logged a number anywhere, no system can invent it. If two of your own tools disagree on the same fact, like two calendars showing different availability, that's not something an agent should quietly resolve on its own. Someone on your side has to decide which source wins, and the system gets built to defer to it and flag the conflict instead of guessing.
How much structure you need also depends on what's being built. A marketing engine that drafts and publishes content can work from a rough brief and existing brand material. An operations system that reports or routes leads needs its inputs to hold a stable shape over time, since a script can adapt to messy values but not to a field that moves or disappears without warning. A full production app with a real database and multiple tenants needs that structure decided up front, because the schema has to hold for years. This is why we map the manual work first and say plainly what a system can and cannot own before we build anything, rather than asking you to clean house beforehand.