How AI reads and processes freight RFQs

An AI system that handles freight RFQs does four jobs in sequence: it decides whether an email is a quote request, pulls the job details into structured fields, flags what is missing or unclear, and drafts a reply for a person to approve. The part it should not do is invent the price. In a well-built system, the number comes from a lookup against your rate card, and the AI's job is to read the email accurately enough for that lookup to work.

What happens when an RFQ email arrives?

Here is the pipeline, step by step. Not every product splits it the same way, but every serious one has to do each of these things somewhere.

1. Intake. The system watches a shared inbox (quotes@, sales@) or a web form. It captures the message, the thread history, the sender and any attachments.
2. Classification. Is this a quote request, a follow-up on an existing quote, a booking confirmation, an invoice question, or spam? Only quote requests go down the pricing path. Everything else is routed or left alone.
3. Extraction. The model reads the email and fills a fixed set of fields: container size and type, count, load type, cartons, pallets, SKUs, dates, origin and destination, commodity, hazmat, special handling and who the customer is.
4. Validation and missing-field detection. Each field is checked: found, missing, or ambiguous. Values are checked against allowed options (a container size has to be one you actually handle).
5. Customer and rate matching. The sender is matched to a customer record, which decides which rate card applies: a contract rate, a customer-specific card or your default.
6. Deterministic pricing. The structured fields are looked up against the rate card. Same inputs, same price, every time.
7. Drafting. The system drafts either a quote or a short question asking for the missing details.
8. Human approval. A person reviews the draft, edits it if needed, and sends it. Nothing goes out on its own.
9. Logging. The extracted fields, the rate lines used, the draft, the reviewer's edits and the send time are all stored against the customer record.

How does the AI decide an email is a quote request?

Classification is a judgment about intent, and language models are generally good at it because quote requests share patterns: a service ("unload", "transload", "store", "drayage"), a quantity ("2 x 40HC", "1,100 cartons") and a timeframe ("ETA next week"). An email that says "can you send pricing for" is easy. Harder cases are a reply on an old thread that adds a new container, or a customer who asks "same as last time?" A well-built system treats low-confidence classifications as "needs a person" rather than guessing.

What fields does the AI extract from a freight RFQ?

The fields should mirror your rate card. If your card prices by container size, load type and carton count, those are the fields extraction must fill. A typical set for a container unload or transload request:

Hazmat needs more than a yes. For shipments that are regulated hazardous materials, US shipping papers carry a basic description of identification number, proper shipping name, hazard class and packing group under 49 CFR 172.202. An RFQ that says "some hazmat" should trigger a request for those details, not a price.

Worked example: one inquiry, start to finish

From: Dana Okafor <dana@northgable-homewares.example>
Subject: Quote - 2 containers next week

Hi team,

We have 2 x 40s landing at Port Newark, ETA around the 20th.
Kitchenware and some ceramic pieces, about 1,100 cartons each,
floor loaded. Need them unloaded, put on pallets and stored
for about 30 days, then shipped out to retailers.

Can you send pricing? One of them might be palletized, I'll
confirm with the supplier.

Thanks,
Dana
Northgable Homewares (fictional)

Hi Dana,

Thanks for sending this over. We can price the unload,
palletizing and storage now. To get you an accurate quote,
can you confirm:

1. Are both containers 40ft standard or 40ft high-cube?
2. Is the one that may be palletized confirmed yet? If so,
   roughly how many pallets?
3. About how many SKUs per container?
4. Is the ETA October 20?
5. Any hazmat in either container? (We assume not for
   kitchenware, but need to confirm.)
6. For outbound: how many retailer destinations, and do any
   have routing guides or labeling requirements?

Once we have these, we will send the full quote the same day.

Notice what the system did not do: it did not pick 40ft high-cube because that is common, did not assume the second container is floor-loaded, and did not quote outbound shipping it had no basis for. You can try the same flow on your own test emails with our RFQ analyzer, a rule-based demo that runs in your browser and shows extracted fields, missing information and a draft for review.

Why should the price come from a rate card, not the model?

Language models generate plausible text. That is what makes them good at reading messy emails, and it is also why they should not set prices. NIST's Generative AI Profile (NIST AI 600-1), a companion to its AI Risk Management Framework, names "confabulation" as a risk specific to generative AI, describing it as the production of confidently stated but erroneous or false content. The OWASP Top 10 for LLM Applications lists misinformation as a core risk and recommends human oversight and automatic validation, particularly for high-stakes outputs. A quote is a high-stakes output: it is a commitment to a customer.

Splitting the work removes most of that risk from the price itself:

• The AI extracts. It turns "2 x 40s, floor loaded, about 1,100 cartons" into structured fields.
• The rate card prices. A lookup takes those fields and returns line items from the card. Same inputs, same output. You can trace every dollar to a rate line.
• A person approves. They check the extraction was right and the price makes sense before the quote leaves.

Structured output features help with the first step, but only up to a point. Anthropic's documentation on structured outputs describes them as constraining responses to a specified schema so output is valid and parseable, with guaranteed field types and required fields. That guarantees the shape of the data, not that the values are right: a schema can force a container size field to be "20ft", "40ft" or "40HC", but it cannot make the model pick correctly when the email just says "40s". That is why ambiguous fields need their own status, and why the review step stays. For how to build a card a lookup can actually use, see how to build a 3PL rate card.

What goes wrong, and what are the safeguards?

Ambiguous units and shorthand

"40s" could be standard or high-cube. "1,100 pcs" could be cartons or units inside cartons. "2 pallets" could be what arrives or what leaves. Safeguard: an explicit "ambiguous" status, and a rule that ambiguous price-driving fields go back to the customer as questions rather than being filled with a default.

Attachments and PDF rate requests

Many RFQs arrive as a PDF, a spreadsheet of lanes or a packing list. Text in a clean PDF or spreadsheet can usually be read; scanned images and complex tables are less reliable. Safeguard: record which fields came from the email body and which from an attachment, and route large multi-lane spreadsheet bids to a person instead of forcing them through a single-job flow.

Forwarded threads

A forwarded chain can contain the original shipper, a broker and your own colleague, with different numbers in each message. The system has to work out which message is the current request and who the customer is. Safeguard: match the customer from the sender and signature, prefer the newest message for quantities, and flag conflicts ("thread mentions both 2 and 3 containers").

Multiple containers or jobs in one email

"Two 40HC floor-loaded and one 20ft on pallets" is three containers and two different rate lines. Extraction has to produce a list of line items, not one set of fields. Safeguard: a schema that allows repeated container entries, and a check that the line count matches the stated total.

Wrong customer match

A new contact at an existing account, or a personal email address, can cause the system to apply the default rate card instead of the contract rate. Safeguard: show the matched customer and the rate card being used on the draft, so the reviewer sees it at a glance.

Hallucinated values

If a field is not in the email, the right value is "missing", not a guess. Safeguard: instruct extraction to return null for absent fields, keep pricing in the deterministic lookup, and require approval before sending. For more on where the approval step belongs and what reviewers should check, see human approval in AI freight pricing.

Where does the time saving actually come from?

Not from removing the reviewer. It comes from the reviewer starting with a structured draft instead of a raw email: fields already pulled out, customer already matched, rate lines already applied, questions already written. The slow part of most quoting is gathering and re-keying details, and chasing the missing ones. That is also where most of the delay in responding to freight RFQs tends to sit. Logging every draft, edit and send time gives you the data to see whether that is actually happening in your own operation.

Adriana, the sales and quoting agent in Rapid Ai 10x, works this way: she reads incoming RFQs, recognizes the customer, extracts the job details, applies that customer's rate card, and drafts a quote or a missing-info question for a person on your team to approve before anything is sent. See how Adriana works.