Choose a process, not a tool
Write down the trigger, inputs, output and person responsible for the next step. Preparing a draft response to a stock enquiry is a bounded task; automating customer service is a broad programme. Start where the team can explain what a good result looks like. If the inputs are unavailable or ownership is unclear, resolve those gaps before building.
Compare value and error cost
Assess repetition, time spent, avoidable waiting and the consequences of a wrong output. A frequent task can still be a poor pilot if mistakes create financial commitments. Keep an approval step for prices, payment changes and customer promises. Stable rules may be better served by ordinary automation; model assistance is useful to evaluate where language or unstructured information is involved.
Build an evaluation set
Collect permitted examples covering normal cases, missing information and exceptions. Define what the output must contain, what it must not invent and when the process should stop. Have the business owner review the results. Test the whole workflow, including access, handoffs and failure handling, rather than judging one attractive model response.
Measure before expanding
Record a baseline for handling time, corrections and completion. During the pilot, include review time and failed cases in the comparison. Agree who monitors problems and how the team returns to a manual path. Expand only after the process meets the agreed acceptance criteria. There is no universal saving or timeline: the business task determines both.
