How to Automate LTL and FTL Quoting for a Trucking Agency

To automate LTL and FTL quoting, run two agents, one per mode, and let code make every decision that carries money or liability while the language model only reads the email. LTL is priced by ZIP and freight class through a carrier rate API. FTL needs full pickup and delivery addresses and a margin you set yourself. Each agent reads the customer’s request, fills the shipment fields, classifies the freight, prices it, and replies in the same thread. Anything outside a set guardrail, such as a doubtful class or a price above the agency’s cap, goes to a person instead of being guessed. In one live test, a single LTL rate call returned 14 carrier prices for one three-pallet shipment, which is why the reply step needs the most care.

A trucking agency lives in its inbox. A customer writes “3 pallets, Salt Lake to Portland, Thursday pickup,” and someone has to turn that into a class, a set of carrier rates, a margin and a reply before the customer asks somebody else. This guide is how we build that for the trucking agencies and brokers we work with, written as the design principles we follow. It is part of TIO’s work as an AI agent workforce for freight forwarders and 3PLs, and it covers quoting and booking, one mode at a time.

What does it mean to automate LTL and FTL quoting?

It means the agent handles the whole path from an inbound quote request to a priced reply, and a person only sees the exceptions. Quote automation is the process of reading a customer’s request, completing the shipment details, classifying the freight, pricing it against carrier rates plus your margin, and answering in the customer’s own email thread.

Four things are inside that definition, and each one is a separate job:

• Reading: pulling origin, destination, pieces, dimensions, weight, pickup date and special handling out of free text and attachments.
• Classifying: assigning an NMFC class and density for LTL, or equipment type and stops for FTL.
• Pricing: calling the rate source, applying the agency’s margin rule, and checking the result against caps.
• Replying: sending one clear message that a customer can accept with a single line back.

A tool that only does the first step hands your team a tidy form and leaves the other three by hand. That is a data-entry aid. For the same reason, rating alone is not the goal. Carrier APIs already return prices in seconds, and the slow part of the job is the reading, filling and replying your team does around that price.

Why should LTL and FTL be two separate agents?

Because the two modes differ at the system you book in, in what the rate needs as input, and in where your margin can live. We split them into an LTL agent and an FTL agent, each with its own inbox address, run view, version history, kill switches and settings. The code underneath is one module, so email design and parsing are shared and never forked.

	LTL agent	FTL agent
Rate input	ZIP to ZIP, pieces, weight, class	Full pickup and delivery addresses, equipment, stops
Where the price comes from	Carrier rate API, many carriers per call	One carrier cost per load, entered or fetched
Where margin lives	On the platform side, so the invoice matches the quote	In the agent’s own margin table, written to the order
Main risk	Wrong freight class, which changes the price	Missing address or equipment detail
Customer reply	Switched on once the guardrails pass	Stays off until the agency turns it on

The margin row is the one agencies get wrong. If the platform that invoices your customer computes the bill from its own sell rate, a markup you add only inside the email never reaches the invoice. The customer is quoted one number and billed another, and your split is computed on the smaller one. We keep each customer’s margin in one place.

The split also keeps mistakes contained. A class problem in LTL cannot break FTL quoting, and turning off customer replies for FTL does not touch LTL.

How does the agent turn a messy email into a priced quote?

It follows the same six steps every time, and each step either completes or stops visibly. Skipping a step is how an agent ends up sending a confident wrong number.

1. 01Read the email as dataFixed fields only, instructions inside the email ignored
2. 02Check what is missingAsk once, match the answer back to the thread
3. 03Resolve the classdispute → personStated, then saved, then the table, then ask
4. 04Rate it14 carrier prices on one live LTL call
5. 05Apply the rules in codeover cap → personMargin, minimums, caps
6. 06Reply in threadShort list, assumptions stated, one-line accept

1. Read the email as data. The model extracts a fixed set of fields from the body and attachments. The email text is never treated as instructions.
2. Check what is missing. If a required field is absent, the agent asks for it once, in one message, and matches the answer back to the same thread. FTL asks for full addresses up front, because the booking side requires them.
3. Resolve the class. LTL only. Class comes from a fixed order described in the next section.
4. Rate it. The agent calls the carrier rate source with the resolved fields and gets prices back.
5. Apply the rules. Margin, minimums, caps and appointment defaults are applied by code. Anything that breaks a rule becomes a task for a person.
6. Reply in thread. One message, a short list of the best options, the assumptions stated, and a clear way to accept.

Accessorials are handled the same disciplined way. The agent does not ask a customer about liftgate or residential delivery unless the email names them. When the email does name special handling, or gives pickup hours outside a normal day, the agent records it in the bill of lading remarks so the driver sees it.

Who decides the freight class, the model or the code?

Code decides the class. The model reads the email, and that line between reading and deciding is the design choice that matters most in LTL. A language model can read “boxed auto parts on two pallets” from an email. It should not be trusted to decide the freight class, because a wrong class changes the price and produces a billing adjustment weeks later.

Class is resolved in a fixed order:

1. The class the customer stated in the request.
2. That customer’s saved commodity class, learned from earlier answers.
3. The reference table: 215 NMFC items, each with a 13-tier density scale.
4. One question back to the customer, whose answer is saved for next time.

The table step matters because density moves class. The same commodity at two different weights per cubic foot can land in different classes, and the table encodes that as a lookup. The saved commodity class matters because agencies quote the same customers on the same freight repeatedly. After the first answer, the agent never asks that customer again.

If two sources disagree, the row becomes a task for a person instead of being averaged or overwritten. Disagreement is information, and hiding it is how a class error survives.

What should stay with a person in a trucking agency?

The high-touch items stay with your team: anything where relationship, claim exposure or pricing judgment outweighs the time saved. The agent’s job is to send those cases to a person with the facts already assembled, so the person makes a decision and does not start from a raw email.

1. 01Read
2. 02Fill gapsask once
3. 03Class
4. 04Rate14 prices
5. 05Rules
6. 06Reply

A person decidesclass dispute · over cap

What we route to a person by design:

• Freight the rules do not cover: hazmat, oversize, exhibit freight, high-value cargo.
• Class disputes: any case where the stated class and the table class disagree.
• Pricing outside the plan: a customer who should pay below the agency’s floor, a new customer on introductory terms, or any price above the dollar cap the agency sets.
• Carrier relationships: negotiating a lane, chasing a claim, or choosing between two carriers for strategic reasons.
• Loads that go wrong: overages, shortages and damage, once a load is moving.

This list is short on purpose. It is how a small agency can scale without adding headcount: the team stops typing and spends its day on the handful of decisions that need a person. When an item lands in the queue, the customer gets a plain holding line, so nobody is left waiting in silence.

How do you keep an automated quote agent from hurting you?

You bound it in code and make every action reversible. There are four controls, and none of them depends on the model behaving well.

Guardrails in code. A doubtful class, a price above the cap, or a missing required field becomes a task, never a guess sent to a customer. The agent cannot raise its own limits.

A kill switch per surface. Every write the agent can make, such as a booking or a customer reply, has its own on and off flag for each customer account. Turning a flag off and redeploying stops that one surface in minutes and leaves the rest running.

An audit row for every action. Each write records who acted, for which customer, when, and the before and after values. When a customer disputes a price, you read what the agent saw and what it did.

Email treated as untrusted data. A quote request is text from outside your company, so it can contain instructions aimed at your agent. Ours reads only whitelisted fields out of the message and ignores instructions inside it. In a live check, the reader returned the correct lane, items and class from an email that also contained an injected instruction, and ignored the instruction.

These four controls are the answer to the obvious objection, which is that a quote agent might send a wrong number. The design assumption is that it eventually will, so the cost of any single mistake is capped and traceable.

What should you measure once the agents run?

Measure four numbers per desk, and publish none of them until the volume behind them is real.

• Turnaround: time from the request landing to the reply leaving.
• Hands-off share: the portion of requests that finish without a person touching them.
• Hand-off reasons: how many exceptions went to a person, and why, grouped by rule.
• Billing adjustments: how often the carrier later reclassified the freight and changed the bill.

The last one is the honest test of the classification design. A fast reply that gets reclassified is a slow reply with a delay attached. Track the first three to see whether the team’s day changed, and track the fourth to see whether the quotes held.

How do you roll it out without risking live customers?

Roll it out in four stages, each with its own off switch, and move on only when the stage before it is quiet.

1. Replay in a sandbox. Run real past requests through the agent with sending disabled and compare its replies to what your team sent.
2. Run one desk with customer replies off. The agent reads, classifies, prices and drafts, and your team sees what it would have sent.
3. Turn customer replies on for that desk. Start with the narrowest set of customers and the simplest freight.
4. Add the second desk. Repeat the same three steps for the other mode.

The same pattern extends to what comes after the quote. Booking, pickup handoff and check calls are the next desks, and they follow the same rules: code decides, exceptions go to a person, every write has a switch and an audit row. For a longer look at the carrier-side problem that sits upstream of a customer quote, see why trucking rate management stays in the inbox and why load postings get no carrier calls.

Frequently asked questions

How many carrier prices does an LTL quote agent have to choose from? More than a person will read. One live LTL rate call for an agency customer returned 14 carrier prices for a single three-pallet shipment. The agent ranks them, keeps a short list of the best options, and writes one reply, so the customer sees a short comparison instead of a rate sheet.

Who decides the freight class on an LTL quote, the AI or the code? The code decides. The model only reads what the customer wrote. Class then comes from a fixed order: the class the customer stated, then that customer’s saved commodity class, then the class table, then one question back to the customer. The table holds 215 NMFC items across a 13-tier density scale, so the answer comes from a lookup the agency can audit.

What should a trucking agency keep doing by hand after automating quotes? Judgment calls that carry relationship or claim risk. We route 5 categories to a person: freight the rules do not cover (hazmat, oversize), class disputes, pricing outside the plan, carrier relationships, and loads that go wrong. The agent hands each one over with the facts already assembled, so the person makes the decision instead of rebuilding the shipment.

How long does it take to roll out a quote agent without risking live customers? Plan for 4 stages, each small enough to undo. Replay past requests in a sandbox, run one desk with customer replies switched off, switch replies on for that desk, then add the second desk. Each stage has its own off switch, so a bad result stops one desk in minutes.

Where this fits

TIO builds these agents for trucking agencies and brokers as part of a wider agent workforce for 3PLs and forwarders, and the quoting agents sit on top of the systems you already use. If your team spends its day turning quote requests into replies, the demo is 20 minutes, and we run it on a real request so you see the classification, the guardrails and the hand-off queue on your own freight. The wider trucking rate management page covers the carrier-side workflow.