Choose the right task to automate

A job is a bundle of responsibilities. A support specialist reads messages, finds records, interprets intent, applies policy, comforts frustrated customers, updates systems, and notices unusual patterns. Those parts do not have equal automation potential.

Break work into verbs with inputs and outputs:

• extract an order number from a message;
• look up the matching order;
• label the request type;
• draft a reply from approved facts;
• approve a refund;
• send the reply;
• escalate a suspected fraud pattern.

“Automate customer support” is too broad to design or test. “Given a new support message, extract an order identifier or return not_found” is bounded. You can collect examples, define acceptable output, and decide what happens when the identifier is missing.

This decomposition also protects meaningful human work. Automation may remove copying and searching while leaving negotiation, empathy, and exception handling with people. The goal is not maximum machine involvement. The goal is a better process.

Use five practical dimensions before building anything.

Frequency asks how often the task occurs. Saving thirty seconds once a quarter is rarely worth integration and maintenance. A modest improvement repeated thousands of times can be valuable.

Clarity asks whether people agree on the desired output. If experienced employees produce incompatible answers because policy is unclear, automation will encode confusion. Clarify the process first.

Input readiness asks whether the required information is available, permitted, and machine-readable. A workflow cannot reliably classify urgency if the relevant account status lives only in someone’s memory.

Consequence asks what a wrong result can do. Mislabeling an internal, reversible note differs from sending a legal commitment or moving money. High-consequence actions need stronger controls and may not belong in the first release.

Exception rate asks how often normal rules fail. A task with many rare formats, undocumented workarounds, and changing dependencies may look repetitive while actually requiring constant judgment.

Score each dimension with evidence, not enthusiasm. Observe real cases for a week. Count volume, variants, corrections, handoffs, and time. Ask workers what makes a case easy or difficult. Their “small” exceptions often contain the most important requirements.

A strong first slice usually has:

1. a clear trigger;
2. a small set of available inputs;
3. an output that can be checked;
4. limited permissions;
5. a safe fallback;
6. inexpensive reversal.

For example, do not begin by letting AI run the entire vendor-onboarding process. Begin by extracting fields from submitted forms into a draft record. Require schema validation, show the source beside extracted values, and let an employee confirm before the record is created. This slice produces useful evidence without granting the system authority to approve vendors or send credentials.

Reversibility matters because early assumptions will be wrong. A draft label can be changed. An external message may already influence a customer. A deleted account can affect access and billing. Start where errors are visible and containable.

Some warning signs should slow you down:

• the goal is stated as “use AI” rather than improve a measured process;
• the task happens rarely or changes every time;
• success depends on tacit knowledge no one can explain;
• there is no owner for incorrect outcomes;
• required data is unavailable, sensitive, or unreliable;
• one error can create serious harm at scale;
• the workflow has no manual fallback;
• automation would accelerate a broken policy.

This does not mean a difficult task can never use AI. It means the team should narrow the scope, improve data, add review, or solve the underlying process problem first.

Turn a candidate into a one-page task card:

• Task: the exact verb and object.
• Trigger: the event that starts work.
• Inputs: required facts and their sources.
• Output: format and destination.
• Success: observable acceptance criteria.
• Exceptions: known reasons normal handling fails.
• Consequence: impact of false positives, false negatives, and delay.
• Fallback: who handles uncertainty and how work reaches them.
• Baseline: current volume, time, quality, and cost.

Consider “route incoming facilities requests.” The trigger is a message arriving in a dedicated inbox. Inputs include subject, body, sender, building, and attachment metadata. Output is a category and queue. Success might mean 95% correct routing for common categories, no automatic handling of safety incidents, and every uncertain case reaching the general queue within one minute. That is much more actionable than “build an AI inbox.”