Start with the friction, not the model
A useful first project begins with a process someone can describe. What arrives? Who handles it? What gets copied, checked, or delayed? What should happen next? A model choice comes after those questions.
Write down a recent example of the task, including the tools involved and the exceptions. If the team cannot agree on the process today, automation may simply make an unclear process run faster. Clarify ownership first.
Look for repeatable work with clear inputs
Good starting points often include routing inquiries, preparing a draft from approved material, normalizing records, or notifying a colleague after a confirmed status change. The input should be reasonably consistent and the output should be easy to inspect.
Distinguish routine rules from interpretation. If a customer selects a service category and the owner is defined by a lookup table, ordinary workflow automation may be enough. If a long message needs a summary or intent classification, an AI step might help, but it should have a fallback.
Evaluate four things before building
Frequency: does the task occur often enough to justify implementation and maintenance? Clarity: can you define a correct result? Risk: what happens if the step fails or produces a wrong answer? Observability: can a person see what happened and correct it?
Record a baseline using actual examples: time spent, rework, missed handoffs, or repeated searches. Do not turn a rough estimate into a promised return. The baseline is a way to evaluate a pilot, not a marketing statistic.
Keep consequential actions behind review
Begin with draft generation, routing suggestions, or read-only retrieval. A person should review actions such as deleting records, sending sensitive communications, or changing permissions. Explicitly define what the system cannot do.
Plan failure behavior before the happy path. A source might be outdated, an integration unavailable, or a request ambiguous. The workflow needs a visible failure state and a named human owner rather than silently skipping the task.
Use a small acceptance set
Collect authorized examples covering normal requests, missing details, unusual wording, and cases that should be escalated. Agree on the expected result for each. Test the same examples before and after changes so a working path does not hide a broken exception.
A useful pilot delivers evidence and a maintainable handoff. If a rule-based workflow solves the problem, keep it. If AI improves a specific step, give that step narrow permissions and a clear review path. Expand only when the observed benefit supports the added complexity.