Choose the unit of automation first
“Automate order processing” covers several jobs: reading a message, mapping its wording to a product code, looking up contract prices, and creating an order. A reviewer can fix a bad extraction before it causes harm. A bad order discovered after registration may require corrections with shipping and the customer. The same error has different consequences depending on where it is found.
Draw the path for a single job from input through approved decision criteria to the system of record. Check whether a form or API can collect the input. For structured input, compare the cost and verification burden of using the values directly. If you keep email, distinguish what the mail says from values confirmed by the customer system. Confirming that a sender really has ordering authority depends on the same kind of data integrity discussed in customer identifiers and events in CRM.
Google PAIR’s guide to user needs and success[1] compares automation with assistance by asking what value it provides. Define when a unit of work is finished before judging how convincing the demo was. In order processing, an order number and correct customer, product, quantity, and price may be required. A draft can save input time, while the number of completed orders must come from the system of record.
Match the execution method to the input and the path
Apply one row of this table to each step. If you cannot fill in the last column, have the owner define how to judge the result first.
| Condition | Method to compare first | Example | Operating evidence |
|---|---|---|---|
| Approved conditions, calculation, and structured input | Rule-based automation | Calculate the amount using the contract price, quantity, and effective date | Rule version, boundary results, and amount reconciliation |
| Systems have a supported interface | API integration | Query products and stock and register an approved order | Authentication and object access, lookup after response loss, uniqueness |
| No supported API and a stable interface | Screen automation such as RPA | Look up a legacy code or download an authorized file | Interface change detection, task-specific account, reconciliation with the ledger |
| Unstructured text needs extraction or classification | AI extraction or classification within a fixed workflow | Separate product, quantity, and shipping requests from email | Values linked to source text, hold on missing fields, reviewer corrections |
| Next action depends on intermediate findings | Bounded agent with outcome verification | Find compatible alternatives to a discontinued part in approved sources | Tool and task limits, time and step bounds, cited evidence, stop and handoff |
| Policies conflict or an owner must exercise discretion | Human decision with review assistance | Approve an exceptional discount or delivery commitment | Rationale, approval, customer communication, outcome |
An API is an interface for exchanging structured information. Separate read and write operations and attach the permissions that fit each. A supplier research task can expose unrelated contract prices if its reads reach every account. Sending its findings outside the system is a separate write operation.
RPA follows a sequence in an interface. It can work for a long-running application without an API when the steps are stable. Unexpected dialogs, expired sessions, changed buttons or field rules should stop the run and notify an owner. Compare the resulting order number or ledger where possible. Where there is no independent evidence, constrain what can run and which losses are acceptable.
Anthropic distinguishes workflows that follow code-defined paths from agents that choose what to do next, and recommends starting with the simplest adequate design. Varied email formats can still fit a fixed sequence of intake, validation, approval, and registration. An agent is a candidate if the next investigation depends on what it finds and useful paths are difficult to enumerate. Anthropic — Building effective agents[2]
Connect the data each campaign needs — Define events and attributes from campaign needs, then align identifiers, transmission timing and measurement tools.
Follow a fictional order from email to registration
A fictional distributor receives “Three boxes of our usual small brackets, same terms as last time.” Product nicknames, pack sizes, and effective prices vary by customer. A forwarded message can repeat an old order, and a new mail may amend it. The model extracts “small brackets” and “three boxes” and flags “usual” and “last time.” Showing the current text alongside any quoted history helps a reviewer see where each value came from.
Find product and customer mappings in maintained reference data. If the lookup returns two candidates, show the differences. Similar names may hide different specifications, and a guessed pack-size conversion can be hard to notice in a draft. Define which fields the system can verify and which need a reviewer.
| Step | Values in this example | What to do on a mismatch |
|---|---|---|
| Interpret | Extract product wording, quantity, and delivery request from the email | Hold if a value is absent or came from quoted history |
| Map | Look up the contract product code and valid packaging unit | Ask the owner to choose among multiple matches |
| Calculate | Apply the contract price and approved quantity and discount | Escalate unclear dates, units, or terms |
| Execute | Call the authorized order API with approved fields and a work ID | Look up an existing result for the same work; handle changed content as an amendment |
| Confirm | Compare the order number and stored product, quantity, and amount | Look up the outcome after an interrupted response before anyone creates a second order |
Message IDs alone miss a duplicate purchase order sent in a new email. Choose business identifiers such as the customer’s purchase order number, the intake ID, and the revision. Decide what changed content with the same work ID means. When a provider supports idempotency keys, verify the request scope and time window. Keep a lookup or reconciliation path when responses are lost or keys are unavailable. AWS Builders’ Library — Making retries safe with idempotent APIs[3]
Bind approval to the product, quantity, price, and delivery details shown to the reviewer. A new quantity needs a new approval while the old one applies to the original values. Test a contract price change or a revoked ordering permission just before registration. Recheck those conditions in the API at execution time.
Compare other ways to solve the same problem
If customers can use common fields, a required order form and an API are strong starting points. A form catches omissions at submission time. Some customers may still need to send mail, in which case AI can prepare a draft. When assessing RPA for a system without an external API, begin with read-only work. Before automating registration, confirm that people can verify state before and after saving.
Investigating replacements is a different job. After a part is discontinued, agents may choose specification searches and compatibility checks. Limit the documents and tools they can access and retain the specification and passage behind each suggestion. An actual order still follows the approval process, and the business system grants execution permissions. OWASP — AI Agent Security Cheat Sheet[4]
Seven questions for an automation decision
- When is the work complete? Decide whether you need a draft, approval, or a confirmed state in the system of record.
- Can you simplify the input? Compare forms, reference data, and supported interfaces. Check whether the other party can make the change.
- Does the sequence change or only one input? Try AI extraction or classification within a fixed path first where appropriate. Write down rules for choices workers can already explain.
- Who owns the source of truth for prices, permissions, and customer status? Decide which value prevails if email and the ledger disagree and who resolves ambiguity.
- Is this a read or a change? Record the actor, scope, approval values, and how you verify the outcome after a failure.
- Where does an error or unknown result go? Specify a queue, recipient, deadline, and recovery or correction. Decide what to tell the customer.
- How will you compare outcomes and operating costs? Include approval delays, rework, manual fallback, maintenance, and training as well as processing time.
An unanswered question points to evidence you need before expanding functionality. If reviewers repeatedly correct customer aliases, try maintaining those mappings. Where a rule exists but is hard to check, prepare a test environment and usable samples. The test automation portfolio applies execution frequency, failure impact, clear expected results, and repeatable environments to distinguish candidates from work ready to verify.
Measure the review burden in a small trial
Start against a representative interface without saving production orders. Use approved examples of ordinary orders, ambiguous units, unknown products, omissions, and revisions. Ask a business owner to write the expected results before the trial. Use approved test data and check what each new model or account receives. Compare how staff perform the same work today and track their time and time lost on failures in either path. NIST AI 600-1[5] discusses pre-deployment testing and tracking risk.
Suppose 100 test orders produce 70 drafts, and 60 proceed unchanged. The draft rate is 70%. The unchanged rate is 60% of all intake or about 85.7% of drafts. Include draft review time and the 40 cases still requiring work: 10 edits and 30 cases without a draft. Call or script success alone can hide extra handling.
Interpret the time saved at the level of the operation. Scattered minutes may or may not lower spending. If the change reduces a busy-hour backlog, look at deadlines and overtime. Include interface changes and account upkeep for RPA, and updates to classification rules and post-change evaluations for AI. A new review queue and its handoff are operating costs.
Expand as the team learns to detect and handle specific failures. Start with draft product and quantity values, then allow the authorized reviewer to save standard orders. Test within an approved set of customers and products and verify alerts and manual fallback. Address any out-of-scope registration or unrecoverable case before expanding.
