AI automation: start with the process

AI and rules solve different problems

Rule-based automation follows a defined condition and action. AI can help interpret variable input, such as an unstructured enquiry, but its output still needs a clear purpose and a way to check correctness. Do not introduce uncertainty into a step that a reliable rule can handle.

Begin by describing the current process in plain language. Name the event that starts it, the information it needs, and the record that proves it finished.

Think of a simple enquiry form. Checking that an email field contains a plausible address is a rule. Looking up an existing customer ID is a database operation. Interpreting a paragraph about several possible services may be a useful AI task. These steps can sit inside one process without every step becoming an AI decision. Give each step the kind of logic its job actually needs.

For this guide, AI automation means using an AI capability inside a repeatable business process. It might produce a suggested category, extract a requested date, or prepare a draft summary. An agent goes further by choosing which permitted action to take next. That extra freedom changes how you test and supervise the system. Start by naming the specific output, not by choosing the most ambitious label.

Ask the team to mark each part of the current process as a known rule, an interpretation, or a human decision. If most of the work is copying structured information, the useful project may be a straightforward connection between existing systems. If requests vary in wording but have a small set of useful destinations, interpretation deserves a controlled trial.

Choose a task with a checkable result

A useful starting task is repeated, bounded, and owned by a person. Organizing an enquiry into approved categories may be easier to evaluate than allowing a system to make an open-ended business decision.

Collect examples of ordinary work and exceptions. Define what a correct result looks like for each example before choosing a tool. If the team cannot agree on the answer, automating the disagreement will not resolve it.

Write the acceptance criterion as something another person could inspect. "Help with leads" is vague. "Prepare a three-sentence summary containing the requested service, the customer's stated timing, and any unanswered question" gives a reviewer an actual job. It also makes invented details easier to notice. An absent deadline should remain absent, rather than becoming a confident guess about urgency.

Build a small collection of permitted examples before configuration begins. Include a clear request, two services mentioned together, missing information, a customer correction, an unrelated enquiry, and text that asks the system to ignore its instructions. Record the intended result beside each example. Keep a few examples separate until evaluation so you can see how the design handles material it was not adjusted around.

Choose a process owner who can resolve disagreements in those examples. Where two staff members classify a request differently, write the decision rule or keep that case in human review. Repeated uncertainty is useful evidence about the process. It may show that the categories overlap or that the intake form asks the wrong question.

Map the intake before and after

The following workflow is illustrative. It describes a design choice, not a deployed integration or a measured time saving.

Consider an invented business with a shared enquiries inbox. Today, a coordinator reads each message, copies contact details into a customer record, decides who should respond, and forwards the message. The proposed design keeps that coordinator responsible for exceptions while reducing repeated copying. It does not authorize an assistant to set prices, make promises, or decide whether a customer should be accepted.

In the proposed flow, a validated submission first receives a durable intake reference. The system checks whether that reference already has a result. It then copies approved structured fields and asks AI for a category suggestion only when the message needs interpretation. A permitted category can move to the routing rule; an ambiguous or unsupported suggestion moves to the coordinator's review queue. The destination's record ID becomes evidence that the handoff completed.

Compare the manual and proposed paths on the same examples. Observe which fields still need correction, how often the coordinator intervenes, and whether someone can find a failed item without searching several inboxes. This is a specification for a before-and-after review, not a claim that this website has deployed that integration or measured its benefits.

Estimate the full operating cost

Count setup, usage, storage, maintenance, and review time. A low per-request price can be misleading if staff spend substantial time correcting outputs. Use actual provider quotes before treating a budget as approved.

Estimate the expected volume and a higher-volume scenario. Include what happens when a limit is reached so the process does not silently stop.

Separate one-time work from recurring work. One-time work can include documenting the process, cleaning source material, configuring access, and creating test cases. Recurring work can include software subscriptions, model usage, monitoring, source updates, and the time spent handling exceptions. A monthly budget should identify who owns each item so maintenance does not become an invisible favor from the most technical person on the team.

Use the time planner below to compare task effort with review and maintenance. Its starting values are invented examples. Change them to measured values from your process and keep the assumptions with the result. A positive time difference is not a revenue forecast. It may represent available capacity rather than reduced payroll, and it says nothing about whether customers received a better response.

Do a second calculation for a difficult month: more requests, more exceptions, and time spent fixing a changed connection. If that scenario cannot be supported, reduce the initial scope or budget for the required support. Review the actual provider charges separately; this guide does not supply software pricing or a commercial quote.

Design errors and approvals before launch

Decide which failures can be retried and which need a person. Prevent repeated events from creating duplicate records. Preserve enough state to understand what happened without logging unnecessary personal information.

Require approval for actions that exceed the agreed boundary. An assistant suggesting a response is different from a system sending it to a customer.

Make the exception queue part of the design review. A useful item tells its owner what failed, what already succeeded, what decision is needed, and whether repeating the step could create a duplicate. It should not require someone to reconstruct the entire customer conversation before choosing a safe next action. Keep customer information limited to what that recovery task requires.

Put approval at the consequential action. Reviewing a suggested response before it is sent is different from inspecting it after a customer has received it. Similarly, approving a proposed appointment time is not evidence that the calendar reserved it. Define what can happen automatically, what requires review, and what the system must never attempt.

Decide who can pause the workflow and how the team will notice that it is paused. Test the manual fallback while people still remember the old process. A workflow that requires the original builder to rescue every failure is not ready for a small team to operate independently, even if the ordinary cases look polished.

Measure the whole task

Compare the time and effort for the same task before and after a controlled pilot. Include checking, exception handling, and corrections. Record error categories as well as completed items.

Use the result to decide whether to expand, revise, or stop. The goal is a dependable process your team can operate, not the largest possible number of automated steps.

Keep a baseline with a defined start and finish. For intake, the start might be receipt of a complete enquiry and the finish might be assignment to the correct person with an accurate record. Measure elapsed delay separately from staff effort. A process can use fewer staff minutes while still leaving customers waiting in an unmonitored queue.

During a pilot, record the number of unique tasks attempted, completed, corrected, and still unresolved. Distinguish a temporary failure that was recovered from a task that never reached its destination. Review the original inputs for a sample of completed items as well; a successful status message is not enough to establish that the resulting information is correct.

At the review meeting, make one explicit decision: keep the current scope, revise a specific part, extend to one additional task, or return to the manual process. Name the evidence behind that choice. Preserve the test set and the decision so the next person can understand why the workflow exists and what would justify changing it.

Build a one-page automation brief

A useful project brief fits the whole process on one page. Start with the business problem and the person affected by it. Add the trigger, required inputs, permitted output, destination, and process owner. Then list the exceptions that stop automatic progression. This short document gives the business and implementation team a shared way to discuss scope before anyone connects software.

For the illustrative intake project, the trigger is a complete website enquiry. Required inputs are the submitted contact preference and service request. The output is a proposed category and an accurate intake summary. The destination is an approved customer system. The owner is the coordinator. Unclear service requests, destination errors, and conflicting contact information require review. Prices, commitments, and outbound campaigns are outside this initial scope.

Include an acceptance column beside every required behavior. A duplicate submission should resolve to the existing event result. An unsupported category should remain unresolved until reviewed. A failed destination should remain visible. These observable outcomes make the brief a useful reference during testing and later maintenance.

Keep the first rollout small enough to inspect

Choose a pilot boundary that your team can supervise. That might be one form, one enquiry category, or a limited group of internal users. Start with human review of every proposed result where practical. Compare the output with the source before expanding the amount of work allowed through automatically. Do not use a deadline as a substitute for this review.

Prepare the people who receive the output. Show them how a normal record differs from an exception, how to correct a mistake, and how to pause the workflow. Ask them to complete a recovery exercise without the builder taking over. Their questions often reveal missing operating instructions that are hard to see from a diagram.

If the pilot succeeds, extend one dimension at a time. Adding a new service category, a new destination, and automatic message sending together makes it harder to understand a later failure. Each extension needs its own examples and acceptance decision. Keep the working scope narrow enough that someone can explain what it does today.

What to bring to an automation discussion

Bring the current process, a handful of permitted examples, the systems involved, and the person who will own the outcome. Include the awkward cases and the steps your team already distrusts. If you have measured effort, share how it was measured rather than only the final average. If you have no baseline, identify a practical way to collect one.

Use the linked AI automation agency service page to understand a possible implementation scope. The right first engagement depends on the process and available evidence. A discovery discussion should establish whether the work needs AI interpretation, a conventional integration, clearer operating rules, or a combination. The useful deliverable is a dependable next step with a defined owner.