How to identify where AI makes sense in your operation

When you sit down with a list of operational flows and need to decide which ones qualify for an automation initiative, starting with model capabilities is the wrong entry point. You need a triage procedure that qualifies or disqualifies candidates before you commit engineering hours and budget.

The protocol has five stages, and each one has explicit pass and fail conditions. To show how it works, we will use a hypothetical but realistic scenario: checking supplier invoices against purchase orders in an ERP before payment release.

Gate 1: Volume and repetition

The test: Does this task run on a predictable schedule with enough volume that manual execution creates an operational bottleneck?

PASS condition: The process runs daily or weekly, touches dozens or hundreds of items, and ties up predictable operational hours.

FAIL condition: The task is sporadic, seasonal, or runs only a few times a month with varied rules each time.

Action on fail: Prefer other candidates. Automating low-volume flows usually generates integration maintenance without measurable operational gain, unless the cost or the risk of each occurrence justifies the project.

Testing our invoice candidate: In the example scenario, the accounts payable team receives around 120 invoices every business day, and two analysts spend four hours each morning matching lines to purchase orders. Verdict: PASS.

Gate 2: Explicit rules vs tribal knowledge

The test: Can a domain expert write down every condition that determines whether an item is approved, flagged, or rejected?

PASS condition: Tolerances, price thresholds, tax code lookups, and routing tables exist in written standard operating procedures or system validation tables.

FAIL condition: Analysts resolve cases using unwritten intuition, such as "we usually let small differences slide if it is supplier X, but not if Bob processed the order."

Action on fail: Document the rules and exceptions before evaluating automation. Rules that live only in one person's memory cannot support an automated flow.

Testing our invoice candidate: Item codes, quantity variances up to 2 percent, and payment term matching are documented in company policies, but the freight tolerance was negotiated verbally by one buyer. Verdict: FAIL FOR NOW. The gate is only cleared once the freight tolerance is written down.

Gate 3: Data accessibility and format

The test: Are input documents and reference tables programmatically accessible, or do they depend on manual logins and loose spreadsheets?

PASS condition: Input files land in a monitored folder, object store, or mail hook. Reference data can be queried via database replica, read API, or scheduled export.

FAIL condition: Key reference information is trapped in paper files, personal desktop spreadsheets, or an external portal that requires manual login with a captcha.

Action on fail: Treat this as a data infrastructure ticket, not an AI project. Build the ingestion pipeline first.

Testing our invoice candidate: Invoices arrive as PDF and XML in a dedicated accounts-payable mailbox, and purchase orders live in a relational database with read access. For the checking task, reading is enough: payment release still happens in the ERP, with the permissions and approvals defined in the project. Verdict: PASS.

Gate 4: Deterministic verification criterion

The test: Can you define an objective test that determines whether an output is correct or contains a validation error?

PASS condition: An explicit definition of success exists: extracted values match the purchase orders within stated tolerances, and every discrepancy triggers an exception queue.

FAIL condition: Quality is judged subjectively, such as "the summary feels thorough". Without objective criteria, the team cannot assess discrepancies consistently or track the accuracy of the flow over time.

Action on fail: Halt until the business defines exact acceptance criteria.

Testing our invoice candidate: A match is correct when line items, quantities, unit prices, and supplier tax IDs match the PO within the documented tolerances. Discrepancies route to human review. Verdict: PASS.

Gate 5: Operational ownership and exception handling

The test: Is there a named operational supervisor who reviews flagged exceptions, updates business rules, and signs off on accuracy?

PASS condition: A designated backoffice lead owns the exception queue and reviews edge cases as part of daily duties.

FAIL condition: The project is sponsored solely by an innovation committee with no operational line manager accountable for day-to-day accuracy.

Action on fail: Do not proceed. Workflows without an operational owner tend to fall into disuse after delivery.

Testing our invoice candidate: The accounts payable lead assumes responsibility for the exception queue as part of the team's routine. Verdict: PASS.

The five gates form this decision flow:

flowchart TD
  Candidate["Candidate workflow"] --> G1{"Gate 1: Enough volume?"}
  G1 -- No --> D1["Prefer other candidates"]
  G1 -- Yes --> G2{"Gate 2: Rules documented?"}
  G2 -- No --> D2["Document the rules first"]
  D2 --> G2
  G2 -- Yes --> G3{"Gate 3: Data accessible?"}
  G3 -- No --> D3["Fix data access first"]
  D3 --> G3
  G3 -- Yes --> G4{"Gate 4: Output checkable?"}
  G4 -- No --> D4["Define acceptance criteria"]
  D4 --> G4
  G4 -- Yes --> G5{"Gate 5: Owner assigned?"}
  G5 -- No --> D5["Name an operational owner"]
  D5 --> G5
  G5 -- Yes --> Ready["Ready for the 2-3 week diagnostic"]

Making the prioritization trade-off

When multiple candidates pass all five gates, do not rank them by hypothetical cost savings. Treat savings as a hypothesis to validate in the pilot, not as a selection criterion.

Among the candidates that pass, prefer the flow with accessible data, documented rules, and a checkable output. Write down the remaining dependencies of each candidate; they feed the diagnostic planning.

A diagnostic is usually planned for 2 to 3 weeks. When a pilot is viable, it is usually estimated at 4 to 6 weeks after the scope is defined.

In summary: the qualification checklist

Before allocating engineering resources or budget, run your candidate through this checklist:

• Gate 1: Daily or weekly cadence with measurable operational volume.
• Gate 2: Explicit decision logic documented in writing.
• Gate 3: Programmatic access to inputs and reference tables.
• Gate 4: Testable pass/fail verification criterion.
• Gate 5: Named operational owner responsible for exception queues.

If any gate fails, address that specific blocker before touching code. If all five pass, your workflow is ready for the diagnostic.

Want to run this triage across your operational backlog? Request a diagnostic.