AI in Operations

Most automation projects do not fail because of technology. They fail because the process was not ready, and nobody checked first.

A process is ready to automate when it has a defined start and finish, follows a repeatable standard path, moves between people or systems, and has an owner who can set the rules. The team should also have enough volume or manual effort to justify configuration and ongoing maintenance.

Six signals indicate that automation may pay off. Three conditions indicate that the team should wait. A process does not need all six signals, but two or three strong signals with none of the disqualifiers provide a practical starting point.

Start with the process, not the tool

Choose one process with a start and finish that people can name. Do not evaluate “operations” or “quoting” as broad categories.

Examples include:

• A purchase order arrives by email and ends with a record in the ERP.

• A service call arrives and ends with a technician dispatched and a work order opened.

• An RFQ arrives and ends with a priced quote delivered to the customer.

If the team cannot draw a line around the process, it cannot evaluate or configure it. Define the process before selecting an automation approach.

A short definition of readiness

Process-automation readiness is the combination of repeatable work, measurable effort, accessible data, clear ownership, and a defined path for exceptions.

That definition applies whether the process uses AI, workflow rules, an integration, or a combination of tools.

Six signals that a process is worth automating

Each signal below includes a diagnostic question, evidence to collect, and the action that follows.

1. The work crosses more than one person

Diagnostic: Who touches the work between arrival and completion, and how does each person know it is their turn?

• Ready: The work moves from sales to pricing, then to engineering, then back to sales and on to the warehouse. Each handoff creates a place where work can wait.

• Not ready: One person handles the entire task at one desk. There may be a better individual productivity opportunity, but there is little coordination to automate.

• Evidence to collect: The people involved, each handoff, average wait time between handoffs, and the communication method used.

• Next step: Map the standard path and identify where ownership changes. Automation can route work, send reminders, and show who owns the next action.

A handoff occurs when responsibility for the next action moves from one person, team, or system to another. Handoffs affect readiness because status can become unclear and work can sit without an explicit owner.

2. The work ends in a system of record

Diagnostic: When the work is complete, where must the data live?

• Ready: The answer names a system such as an ERP, CRM, dealer portal, or warranty system. Someone retypes information from one screen into another, and that data entry takes a meaningful part of the process.

• Not ready: The output is only a document or decision, and no downstream work depends on a recorded transaction.

• Evidence to collect: The destination system, required fields, duplicate-entry points, validation rules, and the person responsible for the final update.

• Next step: Confirm that the system can be reached through an API, supported integration, browser interface, or another approved method.

A system of record is the system that holds the authoritative version of a customer, order, quote, service, or financial record. Automation should update that system carefully because errors there can affect downstream teams.

3. The process includes an approval

Diagnostic: Where must someone say yes before the work can continue?

Common approval gates include:

• Credit holds

• Margin thresholds

• Specification changes

• Pricing exceptions

• Contract terms

• Decisions involving financial or operational liability

• Ready: The approval follows a defined condition, such as a margin below an agreed threshold or a credit hold on an account.

• Not ready: There is no meaningful gate, risk, or consequence if the work moves forward incorrectly.

• Evidence to collect: The approval owner, trigger condition, required information, average approval wait time, and rejected or returned cases.

• Next step: Put the approval in the workflow. Keep a person responsible for the decision when the outcome involves risk, exceptions, or judgment.

An approval that exists only in someone’s memory is difficult to measure and easy to miss. An approval attached to a clear rule can be routed, tracked, and reviewed.

4. Most steps follow rules rather than judgment

Diagnostic: Which steps apply a known rule, and which steps require interpretation?

• Ready: The process routes work by branch, applies a standard markup, escalates after an agreed time, validates required fields, or flags records above a threshold.

• Not ready: Every case is different, and the reasoning changes each time. The process depends on expertise that has not been documented.

• Evidence to collect: Decision criteria, examples of standard cases, examples of exceptions, and the percentage of cases that follow the standard path.

• Next step: Use deterministic rules for known conditions. Use AI to interpret documents or messages when needed, then send uncertain cases to a person.

A repeatable rule produces the same action when the same condition occurs. For example, a complete purchase order from an approved account can follow a defined intake path. Human judgment is more appropriate when the information is incomplete, the situation is novel, or the decision carries pricing, specification, legal, or customer risk.

5. Nobody can tell where work stands

Diagnostic: How many cases are in flight, and how long has the oldest case been waiting?

• Ready: The status requires a meeting, a manually maintained spreadsheet, a search through email, or a walk to someone’s desk.

• Not ready: The team already has accurate status data, and the process is meeting its targets. A process with a larger visibility problem may deserve attention first.

• Evidence to collect: Open cases, owner, current stage, age, target completion time, and reason for delay.

• Next step: Create a visible queue with an owner, status, next action, and age for every case.

Visibility is often a readiness signal because the team cannot improve a process it cannot see. It also creates the baseline needed to measure an automation pilot.

6. The process lives in one person’s head

Diagnostic: If the process owner left next quarter, how long would it take another person to perform the work accurately?

• Ready: The answer is months, and everyone knows which person holds the process knowledge.

• Not ready: Several people perform the work interchangeably, and the written procedure matches what they do.

• Evidence to collect: The owner, undocumented decisions, training time, workarounds, and the parts of the process that require escalation.

• Next step: Document the standard path and name a process owner before configuration begins.

Key-person risk can make a process a good automation candidate, but the team still needs to capture the owner’s decisions. Automating undocumented knowledge without validating it can make errors happen faster.

A practical readiness scorecard

Use the scorecard for one process. Record evidence rather than relying on general impressions.

Two or three strong signals can justify a pilot. A higher score suggests greater coordination value, but the score does not override the disqualifiers below.

Three conditions that mean the team should wait

These conditions can stop a project even when a process has several positive signals.

The process does not exist in a consistent form

If three people perform the work three different ways and nobody can say which way is correct, there is no stable process to configure.

Document the standard path first. Have the team agree on the intended method, run it manually long enough to expose exceptions, and then automate the parts that remain consistent. The process does not need to be perfect. It needs a documented path that most cases follow.

The volume or effort does not support the investment

Low volume alone does not make automation a poor choice. A small number of cases may still justify automation when each case takes substantial time, creates expensive errors, or blocks downstream work.

Use the effort and ROI worksheet below instead of relying on a universal volume threshold. The same steps should repeat often enough, or consume enough time, to support configuration, monitoring, and maintenance.

Nobody owns the decision

Someone must be able to define the approval rule, set the threshold, resolve disagreements, and make the decision stick.

The process owner should be able to answer:

• What is the standard path?

• Which conditions create an exception?

• Who approves an exception?

• What data must reach the system of record?

• Who changes the rules after launch?

If every rule requires a committee and no person has authority to decide, configuration will stall. The owner does not need to perform every step, but the owner must control the process definition and approval rules.

Measure the opportunity before automating

A short worksheet makes the decision more concrete. Collect the following for a representative period:

• Process volume per week or month

• Minutes of manual handling per case

• Number of handoffs

• Number of re-keying points

• Exception rate

• Average approval wait time

• Age of the oldest open case

• Error or rework rate

• System of record

• Current staffing or hourly cost for the work

A simple ROI calculation

Estimate the current monthly manual cost:

Current monthly cost = monthly volume × manual minutes per case ÷ 60 × hourly cost

Then estimate the recoverable value:

Recoverable monthly value = current monthly cost × percentage of work the pilot can remove or reduce

Finally, compare that value with the project cost:

Estimated payback period = implementation and expected maintenance cost ÷ recoverable monthly value

The percentage should be an estimate tied to specific steps, such as data entry, routing, reminders, or status updates. It should not include judgment work that will remain with a person.

For example, a purchase-order pilot may reduce time spent reading an email, entering fields, checking completeness, routing the order, and updating the ERP. It should not count time spent resolving an unusual specification or approving a margin exception unless the pilot truly changes that work.

Readiness checks beyond AI

Several practical conditions affect whether automation can work.

Data access

Check whether the ERP, CRM, or other destination system has:

• An API

• A supported integration

• A web interface that an authorized person can use

• Required credentials and permissions

• A test or controlled environment for the pilot

An older system may still be workable through a browser interface, although that approach can require more monitoring than a direct integration. Access and security should be resolved before configuration begins.

Input quality

Review the actual inputs, not an idealized sample. Inputs may arrive through email, a CRM, a web form, scanned documents, attachments, or handwritten material.

Poor input quality does not always stop automation. It changes the expected accuracy, review process, and exception design. Define what happens when a required field is missing or a document cannot be read.

Exception rate

An exception is a case that cannot follow the standard path because information is missing, a rule does not apply, or a person must make a judgment.

A high exception rate means the team may be automating only a short preamble. Measure:

• How often cases leave the standard path

• The reason for each exception

• The person who resolves it

• The time required to resolve it

• Whether the same exception repeats often enough to become a new rule

The standard path should remain the common path for a first pilot. Exceptions should enter a visible queue instead of disappearing into email.

Ownership after launch

Rules, systems, documents, and customer requirements change. Assign someone to own the workflow after launch, just as someone owns the ERP or CRM.

The process owner should review:

• Exception trends

• Approval delays

• Error and rework rates

• Rule changes

• Access and integration issues

• Whether the workflow still matches the documented process

Automate first, keep judgment human-led

A useful division of work separates repeatable coordination from decisions that need context.

Good first candidates for automation

• Reading structured information from emails, forms, and attachments

• Creating or updating records

• Enriching customer or order information

• Checking required fields

• Asking for missing information

• Routing work to the next owner

• Sending reminders and escalations

• Updating the system of record

• Showing open work and aging

• Applying deterministic thresholds

Keep these steps human-reviewed

• Unusual specifications

• Novel customer requests

• Pricing or margin risk

• Contract or liability decisions

• Ambiguous documents

• Exceptions without a documented rule

• Final approvals that commit financial or operational records

AI can help interpret messages and documents. Plain workflow rules should handle known conditions. A person should review uncertain interpretations and decisions with material risk.

What ready workflows look like

The following examples show how a ready process can change without removing human control.

A ready workflow does not attempt to resolve every unusual case automatically. It creates the record, collects the available information, routes the work, pauses for missing answers, and gives a person a clear exception or approval task.

Build a controlled pilot

A narrow pilot provides a better test than automating an entire department.

1. Select one process. Define the start event, end event, standard path, and exception types.

2. Name the owner. Give one person authority over the rules, approval gates, and post-launch changes.

3. Record the baseline. Measure volume, cycle time, manual minutes, approval wait time, exception rate, error rate, and cases past target.

4. Automate the standard path. Start with intake, validation, enrichment, routing, reminders, and system updates.

5. Keep approval gates. Require human review before a record commits to the system of record when risk warrants it.

6. Create an exception queue. Capture the reason, owner, age, and resolution for every case that leaves the standard path.

7. Set a review date. Compare the pilot with the baseline and decide whether to adjust, expand, or stop.

The first useful measurements are:

• End-to-end cycle time

• Number of cases past their target

• Exception rate

• Hours spent on manual entry

• Error and rework rate

• Approval wait time

These measurements show whether the workflow improves speed, visibility, data quality, or capacity. They also show where the process still needs a clearer rule.

Common questions

How much volume is enough to justify automation?

There is no universal threshold. Automation becomes easier to justify when the same steps repeat often, consume meaningful staff time, create delays, or produce costly rework.

Calculate monthly manual cost from volume, handling time, and hourly cost. Then estimate which part of that time the pilot can reduce. A low-volume process may still qualify when each case carries high financial or operational impact.

Should a messy process be cleaned up before automation?

Yes. Clean it up to the point where the team agrees on one standard path and a clear exception method.

The team does not need to resolve every unusual case before starting. It does need to document the common path, define required information, assign an owner, and decide who handles exceptions.

What if the ERP is old and has no API?

An older ERP may still work through a supported integration or a browser interface. Confirm that authorized users can access the necessary screens, required fields, and records.

A browser-driven process may require more monitoring than a direct integration. The team should test it with a controlled pilot and define how it handles timeouts, access changes, and failed updates.

Should the whole process be automated?

Start with part of the process. Intake and data entry often provide a clear starting point because they involve reading information, checking completeness, creating records, and routing work.

Keep approvals, unusual specifications, pricing risk, and novel judgment with people until the team has evidence that a more advanced rule is safe.

How should the team know whether the pilot worked?

Choose the measurements before configuration begins. Compare the pilot with the baseline for cycle time, cases past target, exception rate, approval wait time, manual hours, and error or rework rate.

A pilot worked when it improves the selected measures without creating unacceptable errors or removing a necessary approval. The result may be a decision to expand, adjust the rules, or stop the workflow.

Where this goes next

Order intake often makes a practical first pilot for dealers, distributors, and manufacturers because it:

• Moves between sales, operations, engineering, pricing, and fulfillment

• Ends in an ERP or another system of record

• Requires complete and accurate information

• Includes approvals and exceptions

• Creates delays when status lives across email and individual spreadsheets

Vsimple coordinates these steps through intake, record creation, data enrichment, missing-information requests, routing, approvals, exception handling, and system handoff. A team can start with one defined workflow, measure the baseline, and expand after the standard path proves reliable.