The task people complain about most is not always the strongest first automation project. A time-consuming process may still have unclear rules, inconsistent inputs or an output nobody can reliably evaluate. A useful AI automation candidate has a defined boundary, a reviewable result and a way to recover when it goes wrong. Begin with the work your business performs, then decide where AI could make a practical contribution.

Map the input and output behind the task name

Break a broad activity such as proposal preparation into stages: reading the enquiry, identifying missing information, matching the scope, calculating costs and obtaining approval. Those stages do not necessarily belong in one AI system. Some involve interpreting language; others require exact calculations or a responsible person's decision.

For every candidate, record the trigger, information source, required output and person who uses the result. Distinguish frequent routine work from rare but consequential decisions. If different people perform the same task inconsistently, the next step may be agreeing on a process rather than automating it.

Shortlist opportunities with four operational questions

Do not rank candidates only by an estimated saving in minutes. Consider whether the result can be checked and how work will continue if the system fails. An unanswered question below identifies preparation work that should happen before implementation.

  • Can the workflow access a suitable and dependable input source?
  • Can the team provide examples of acceptable and unacceptable results?
  • What happens to customers or operations when the result is wrong?
  • Who can stop the workflow and complete the task manually?

Separate decision support from permission to act

A workflow may summarise enquiries, retrieve relevant information or prepare draft tasks without independently changing a price or making a customer commitment. Define how the output may be used. That boundary makes both implementation and evaluation more concrete.

In a hypothetical maintenance company, the first project could classify incoming emails by service type. Staff review the classification while appointment and pricing decisions remain with their existing owners. This narrow starting point lets the team evaluate a useful step without attempting to automate the entire customer relationship.

Test exceptions as well as clean examples

Include short and long messages, incomplete information, multiple requests and enquiries outside the company's scope. A demonstration using only tidy examples will miss the work that creates difficulty in practice. Give error types different significance: misrouting an urgent request may matter more than an imprecise general label.

Evaluate processing time, correction effort and unresolved records together. An automation may reduce work for one person while creating a review queue for another. Make that trade-off visible. Expansion should depend on whether the overall process works better, rather than how impressive an isolated output appears.