Turning Freight Inquiries and Quotes into a First AI Workflow

I am participating in an AI workflow project for a cross-border logistics company. To protect the client and an active project, this article does not reveal identities, prices, routes, internal documents, or unverified business results.

It records a reusable method: why the inquiry desk can be a useful first workflow and how to make its boundary observable.

Break “quote this shipment” into visible actions

An inquiry may arrive through email, chat, a form, or an attachment. What appears to be one request actually contains several actions:

• identify origin, destination, transport mode, cargo, and timing;
• detect missing or conflicting fields;
• ask for the information that changes the rule scope;
• retrieve the relevant pricing rule and validity period;
• detect oversize cargo, restricted categories, unusual routes, or customer exceptions;
• prepare a review package;
• return the approved result to communication and internal records.

Putting the entire process into one agent makes failure hard to locate. Separating the actions makes each input, source, output, and stop condition testable.

Classify fields before extracting them

Field group	Examples	Why it matters	Action when missing
Transport	origin, destination, mode	defines the search scope	ask; do not guess
Cargo	commodity, pieces, weight, dimensions	determines applicability and exceptions	pause matching when critical units are missing
Timing	expected departure, service preference	removes expired or unsuitable options	mark as pending; do not promise
Commercial terms	Incoterms, service scope	defines responsibility	make required or conditionally required
Special attributes	packaging, restrictions, sensitivity	may require escalation	route risk hits to a person
Provenance	channel, attachment, receipt time	preserves traceability	do not issue an external response without provenance

The output should distinguish original text, normalized values, inferred values, and unresolved fields.

Two synthetic examples

These examples were written for this article and do not contain real customer data.

Example A — insufficient chat message

We have some ordinary cargo going from A to B. Can it move soon?

Only origin, destination, and a vague time request are present. Commodity, pieces, weight, dimensions, mode, and service scope are missing. The correct output is a prioritized question list, not a speculative quote.

Example B — a complete-looking but conflicting form

Origin A; destination B; sample commodity; pieces, weight, and dimensions supplied; requested mode: option one; note: please use the transit time of option two.

The requested mode conflicts with the note. The system must preserve both source statements and ask for confirmation. Completeness is not enough; consistency matters.

Six measurable workflow nodes

Node	System action	Observable output	Human trigger
1. Receive	preserve original text, attachment references, and channel	immutable input record	unreadable attachment or unknown source
2. Extract	extract and normalize fields	values, citations, and state labels	critical field has multiple interpretations
3. Validate	find missing values, unit problems, and conflicts	missing and conflict lists	critical information is missing or inconsistent
4. Retrieve rules	search using confirmed fields	source, version, validity, and scope	rules conflict or are expired
5. Human decision	summarize input, rules, and exceptions	continue, return, or escalate	this is a formal node, not a temporary patch
6. Output and write back	prepare internal material and save the decision	traceable result and exception record	external sending follows the permission policy

The first pilot only needs to prove this small loop: the system receives the input correctly, knows when to stop, gives the person enough context, and carries the decision back into the process.

Prepare decisions before automating commitments

While rules are still being verified, the agent should prepare decision material rather than promise a final price. It can extract fields, identify gaps, cite candidate rules, and draft an internal summary. A commercial operator keeps the final price and external message.

Human corrections then become evidence. They reveal recurring missing fields, conflicting rules, and exceptions that belong in the SOP.

Every pricing rule needs provenance and validity

A freight quote is not one number copied from a static spreadsheet. Route, supplier, customer agreement, surcharge, and validity can all change the result.

Every retrieved rule should include:

• source and version;
• applicable customer, route, and cargo scope;
• effective and expiry dates;
• maintenance owner;
• escalation conditions.

An answer without a reviewable basis cannot be safely maintained.

Make handoff a first-class node

Missing information, conflicting rules, high-risk cargo, and unusual customer agreements may need different recipients. The handoff must include the inquiry, extracted fields, cited rules, conflicts, and suggested next action.

After the person decides, the result should return to the inquiry record and, when useful, update the SOP or exception log. See the full human handoff design and SOP maturity checklist.

Start by measuring field completeness, number of follow-up questions, review time, rule conflicts, and exception write-back. Only after those measures stabilize should the team discuss deeper automation of replies or calculations.

You can compare candidate workflows with the AI pilot priority scorecard, review the anonymized case summary, or place this example inside the AI agent workflow topic.