◇ Could this help me?
Yes. Steps two and three are the valuable part and the part most automation projects skip: mapping the workflow as it is actually performed, and asking why each step exists before removing it, is what prevents automating away a check or a judgment call that was quietly doing real work. Verifying against the existing software stack before committing is likewise a sensible feasibility gate rather than a formality. General practice, with one caution: the video ends by offering a catalogue of pre-analyzed use cases as a way to skip the employee interviews, and that trade defeats the point, since the interviews are where the undocumented reasons for each step surface.
Act as a solution architect for a specific workflow I am considering automating. First, interview me to reconstruct the workflow exactly as it is performed today, step by step, including the informal steps that are not written down anywhere. For each step, ask me why it exists and what value it delivers to the customer, to the business, and to the person doing it. Then tell me which steps are genuine agent candidates, which must stay human and why, and what would be lost if each one were removed. Finally, list the software each step depends on and flag anything that would block automation with the current stack.