Setup starts with mapping the work itself: someone who actually does the task walks us through it, step by step, so we can say honestly what a system can own and what still needs a person. That has to come from whoever knows the process, not someone summarizing it secondhand, and it takes real time from your side. We also need access to the tools the work runs through: the logins and permissions it depends on, because the system has to act inside the same tools your team already uses, not a copy of them.
Once the process is mapped, the actual building is mostly ours. Your team's role narrows to answering questions when something is ambiguous and reviewing the system's first real runs against what a person would have done. This is where mismatches show up: an edge case nobody mentioned in the walkthrough, a judgment call the process assumes without saying so out loud. Catching those early matters, because they are what the system will keep getting wrong if nobody flags them.
After launch, the system runs on its own and only interrupts someone when a decision genuinely needs a person, like a reply that needs judgment or a result that falls outside what it was built to handle. That queue is the ongoing time cost, and it should shrink as the system proves itself and the escalation rules get tightened. The clearest sign this is worth doing: the work follows a pattern that could be written down, even if nobody has written it down yet. If every instance of the task depends on a fresh judgment call, mapping it will take longer than the task is worth.