Most of what a veteran employee knows never made it into a manual. It is pattern recognition: which invoice looks off before the numbers say why, which customer complaint means call me now versus handle it later, which supplier always needs a follow-up email even when they said yes. You do not get that by asking someone to write a process document. You get it by watching them do the real work, case by case, and asking why at the point they make each call, especially the calls that break the standard rule.
We start by mapping the process as it is actually done, not as the org chart says it should be done. That usually means sitting with the person through a run of live cases, or reading the trail they already leave (emails, call notes, the spreadsheet only they update) and asking them to narrate the gaps. The goal is to separate what is really judgment from what is just habit nobody ever questioned. Habit gets written into rules the system can follow. Judgment gets a place in the workflow where the system stops and asks a person, at least at first.
Some of it will not transfer cleanly. Relationship knowledge, like which vendor will bend or which client's threat to leave is real, often lives in years of context that a rule set cannot hold, and that piece may need a person for longer than the rest of the process does. The practical fix is timing: start this months before the person leaves, not the final week, and let them correct the system's output while they are still around so the corrections get built in instead of lost. If there is no time for that overlap, be honest that the automation will launch weaker than the person it replaced, and plan for closer review after they are gone.