When there's no written process, we treat that as the starting condition, not a problem. We sit with whoever currently does the task, watch a handful of real cases start to finish, and pull actual examples: past emails, spreadsheets, the tickets nobody thinks to save. Screen recordings work well because people forget the small decisions they make, the exceptions they handle without noticing. Out of that we write our own version of the process, in plain steps, and check it against a few more real cases before touching any code.
The hard part usually isn't the main flow, it's the exceptions: what happens when a customer asks something unusual, when a number looks wrong, when two systems disagree. Those decisions often live only in someone's head, and the person doing them may not be able to explain the rule, only recognize the right answer when they see it. We flag those spots directly: some can be turned into a rule once we ask enough questions, others genuinely need a person to keep deciding, at least at first. We would rather tell you a piece stays manual than quietly guess and get it wrong.
Once the process is mapped this way, it becomes the closest thing your business has to documentation, and we hand it back regardless of what we build from it. One thing worth checking before you start: if two people on your team would each describe the same task differently, that disagreement needs settling first. Automating an argument just makes it run faster and louder.