Most writing about automation assumes you are starting from an organized place. Clean processes, documented workflows, structured data. The advice is about choosing the right tool, integrating systems that already exist, or optimizing a flow that already works.
That is not where most companies are when they actually have this conversation.
When I joined a company where I ended up building most of the internal automation, the starting point looked different. Information lived in inboxes. Supplier data was spread across files that were not updated consistently and did not talk to each other. Purchase orders were created manually, logged manually, and filed in a shared drive where the naming conventions were whatever felt right to whoever uploaded them that day. When a long-term employee left, the operational knowledge they carried with them was often the only reason the process had functioned at all.
Before you can automate anything in that environment, you need to understand what is actually happening, not what the process documentation says is happening, but what the work looks like in practice. Those two things are usually not the same.
The real invoice process at that company: someone received a PDF by email, opened it, typed the relevant data into a spreadsheet by hand, saved the PDF somewhere in a shared folder, and hoped the file name was descriptive enough that someone could find it later. No naming standard. No audit trail. No way to systematically check for duplicates. That was the actual process. Understanding it clearly was the starting point for building something better.
Once you can describe what is actually happening, the business case writes itself more easily than most people expect.
The structure that works is straightforward. What does this task cost right now, in hours per week, multiplied by the cost of the person doing it? How many errors does the current process produce, and what does each one cost to fix downstream? What happens if the one person who understands the process leaves? That third question is usually the most persuasive argument in any room. Single points of operational knowledge are a continuity risk, and companies running on spreadsheets and informal processes have them in more places than they realize.
The practical trap is the circular dependency: you need to fix the data before you can automate, fixing the data requires a project, the project requires budget, the budget requires demonstrated ROI, and demonstrating ROI requires the automation you do not have yet. This loop can run indefinitely.
The way through it is to pick one process, not the most important one or the most complex one, but the one with the most consistent inputs and the most visible pain, and build something for that specific problem. Not a platform. Not a solution to every related problem. A tool for that task.
The first tool I built at that company was the PO Automator. Supplier offers were inconsistent in layout but predictable enough in content: a PDF with a set of fields that appeared in roughly the same places. The AI read the offer, extracted the data, and pre-filled a structured form. The first version was not perfect. It got better quickly because the people using it could see where it was going wrong and say so. Within a few months, PO creation went from 15 minutes to 3 minutes. That result was visible, measurable, and convincing to anyone who had been doing the work before.
The business case after that point was not a document. It was a comparison between what people remembered doing and what they were doing now.
The later challenge is the one most automation advice spends too little time on: getting tools that work individually to create something coherent. Supplier data that is consistent across the PO tool, the invoice tool, and reporting. Document naming that is systematic rather than dependent on which tool created the file. A view of operations that reflects the whole rather than several separate snapshots. That work took longer than building the tools themselves.
There is no clean version of this. You build the foundation while running the tools, not before. It is messier than the alternative. It is also the version that is actually possible.