Before you add AI, fix the workflow

Choose a workflow you can measure

Pick one recurring task with identifiable inputs, an output somebody uses, and an accountable owner. 'Improve customer support' is too broad. 'Prepare a draft response for delivery-status requests using the order record' is testable. Map the path from intake to completion, including missing information, handoffs, approvals and rework.

Observe the current process before changing it. Record hands-on time separately from waiting time, how many cases need correction, and which exceptions consume effort. Agree on the quality floor with the people doing the work. A faster draft is not a useful improvement if reviewers spend longer finding unsupported statements.

• Name the workflow owner and the person who approves its output.
• Define completion, the allowed inputs and the exception path.
• Capture a baseline for active work, elapsed time and correction rate.

Use rules where rules are enough

Many workflow problems need better forms, validation, search or integration rather than AI. If a decision follows explicit conditions, implement those conditions directly. Required-field checks, approval thresholds and routing by account region should be predictable and auditable. A model adds variability without improving a well-defined rule.

AI may help when the input varies in ways that are difficult to enumerate: summarising a long thread, interpreting a free-text request, or drafting an explanation from approved records. Keep deterministic checks around that step. In the delivery example, software retrieves the order status; AI drafts the wording; a rule prevents sending a message without a valid order reference.

Compare the assisted approach with a simpler alternative such as a template or better search. If it does not improve the whole task, stop. 'No model needed' is a valid engineering decision, not a failed AI initiative.

Make human review a real control

For an initial pilot, let the system propose rather than commit. Show the reviewer the original request, the records used, the draft and any missing information together. Review must happen before a consequential action, not after an email, payment or permission change has already occurred. Provide edit, reject and manual-completion paths.

Do not treat a model's confidence statement as evidence of correctness. Require verifiable support for factual claims and route ambiguous cases to a person. Assign reviewers enough time and authority to disagree. A busy user clicking 'approve' without the underlying evidence is not a meaningful safeguard.

Limit data access and tool permissions to the workflow's needs. Treat instructions inside uploaded documents or customer messages as untrusted content, not authority to execute actions. Check provider retention terms, minimise sensitive data, and retain an access-controlled audit trail without indiscriminately logging private inputs.

Write acceptance tests before the pilot

Build a representative evaluation set from authorised, appropriately sanitised examples. Include ordinary work, rare but important exceptions, malformed inputs and requests the system must refuse. Keep a separate held-out set so repeated prompt tuning does not merely fit the examples everybody has seen. State the expected behaviour for each case.

For the illustrative support workflow, test that the draft never invents a delivery date, does not reveal another customer's order, requests missing identifiers, and leaves refunds to the authorised process. Also test timeouts, unavailable records, duplicate requests and malicious instructions embedded in a message. Some requirements can be checked automatically; tone and usefulness may need a reviewer rubric.

Set launch and stop criteria before seeing the results. Separate unacceptable failures from tolerable imperfections instead of hiding both in one average score. Version the model, prompts and retrieval configuration, and rerun the evaluation when any of them changes. Keep a manual fallback and a way to disable the assisted step.

Count the cost of the whole operation

A model's usage bill is only one cost. Count integration, data preparation, reviewer time, correction, monitoring, support, vendor charges and ongoing evaluation. Compare these with the baseline using similar cases and volumes. A shorter generation time is not the same as lower operating cost.

Illustratively, if a manual task takes 12 minutes and the assisted version needs 2 minutes of preparation, 5 of review and 2 of correction, the net saving is 3 minutes, not 10. Convert that time into money only using a defensible labour-cost assumption. Released capacity is not automatically a cash saving; explain how the team would actually use it.