Before you automate,
watch the work.
A walkthrough can change the problem you thought you were solving.
Ask to see the last example.
Instead of asking a team what AI they want, ask them to show the last request they handled. Follow the actual documents, messages, decisions, and handoffs. The most useful detail is often somewhere the official process diagram leaves out.
Separate the task from the friction.
Writing an email might be quick. Finding the right information to write it might not be. If you automate the visible step without understanding the preparation behind it, you can build a very polished answer to the wrong problem.
Look for the exceptions.
The usual case is the beginning, not the whole brief. Ask what changes for a special customer, an unavailable item, incomplete information, or a request that arrives late. These cases often determine whether the system can be trusted in normal use.
Choose a bounded first change.
The first implementation should be small enough to evaluate and useful enough to matter. That may be one team, one document type, or one internal handoff. A bounded project is not less ambitious; it gives the next decision a better basis.
Keep the people in the picture.
An implementation changes how someone works. Involve that person in the test, show what the system will and will not do, and give them a clear way to correct it. A successful demonstration is only the beginning of a useful tool.
Independent thinking.
Applied intelligence.