Direct answer
A freight tender bid is usually lost in the assembly, not in the pricing idea. The client sends a spreadsheet of lanes and a deadline; several people source costs, someone edits a copy, a condition gets forgotten and the file that goes out is not the file anyone approved. The fix is a single lane sheet that is the one source of truth, a named owner per step, explicit assumptions written next to the numbers and an approval before anything is submitted.
This page describes the process. It does not publish any rates or margin logic, and it does not claim rate-API, carrier or EDI connections; those are scoped per project only where an API exists. If you are the supplier side of this exchange (requesting quotes from carriers), see freight RFQ management instead. This page is about answering your client.
Intake: decide whether and how to bid
Start by logging the tender as a record with its deadline, the client contact, the format they require and any questions window. A tender that lives only in an inbox has no owner and no clock.
- Assign one bid owner who is accountable for the deadline, whatever the number of contributors
- Read the tender terms once, early, and list every requirement you cannot meet or must clarify
- Send clarification questions inside the questions window; write down the answers on the record
- Make an explicit bid or no-bid decision, with a reason, so the team is not half-working a tender nobody chose
- Save the original file untouched, so you can always prove what the client actually asked
The lane sheet: one file, one version
The lane sheet is the core artefact. Each row is a lane as the client defined it: origin, destination, mode, equipment or cargo type, expected volume as the client stated it, and any special conditions. Keep the client's column structure so the returned file matches what their team will evaluate.
Add your own working columns beside, not inside, the client's: the source of the cost, the assumption behind it, the person who filled it and a status per lane. One row per lane, one status per row, and the whole team edits the same sheet or system rather than emailing copies. If the tender has hundreds of lanes, status per lane is what tells you on the last day which ones are still empty.
Rate sourcing
Costs come from your carriers and partners, from your own contracted rates or from a recent quote. What matters for the workflow is that every number has a traceable source and a validity date. A cost with no source cannot be defended when the client asks a question, and a cost that expires before the tender's validity period is a risk you should see immediately.
- Request costs from suppliers in a consistent format so they can be pasted against lanes without retyping
- Record for each cost: who supplied it, when, and how long it holds
- Flag lanes with no cost yet, lanes with a single source and lanes where the source's validity ends before the tender's does
- Keep the cost columns and the pricing columns separate, and restrict who can see and edit the pricing ones
- Where a system exposes a rate API, pulling costs from it is a per-project integration. Do not assume it exists
Assumptions and exclusions
A bid is a set of numbers plus the conditions under which they hold. Write the conditions down. Typical items to state are what volume basis the rates assume, what is included and excluded, how accessorial or surcharge items are treated, the validity period, the payment terms you are proposing and what happens if the client's volume or lane mix changes.
Put the assumptions in a dedicated section of the response and, where they attach to one lane, in a notes column on that lane. Anything you say verbally to the client must also be in the file. Contract and legal wording should be confirmed with a lawyer and in your own standard terms; this workflow only makes sure the commercial assumptions are visible.
Approvals before submission
Decide in advance who must approve what. A common pattern is that the bid owner approves completeness, a commercial lead approves pricing and someone with authority approves any non-standard term. The rule that matters is that approval is recorded against a specific version of the file, and the submitted file is that version.
- Before sending, someone who did not build the sheet checks it against the client's instructions
- Every lane requested has a response, or an explicit no-quote with a reason
- No working columns, internal notes or cost figures are visible in the client copy
- File format, naming and submission channel match the instructions exactly
- Assumptions and validity match the approved version
- Submitted before the deadline, with proof of submission saved on the record
Follow-up and win/loss capture
Submission is not the end. Log the date the client said they would decide and schedule a follow-up. Clarification rounds and best-and-final requests are common, and each should run through the same lane sheet so the versions stay in order.
When the result arrives, record it: won, partly won, lost. Capture what the client told you about why, which lanes were awarded, and what the competing position appeared to be if they share it. This is the part most teams skip, and it is the only way the next bid gets better on evidence rather than memory. Over time the record also shows which kinds of tender you win and which ones cost more effort than they return.
Where software helps and where it does not
A shared sheet with discipline is enough for an occasional tender. Purpose-built tooling starts to earn its place when tenders are frequent, lane lists are large, several people contribute costs and approvals need a visible trail. A custom build can hold the tender record, the lane sheet, cost sources, approvals and the win/loss log in one place, shaped to how your team actually bids. What it should not do is decide your prices; the pricing decisions stay with your people.
For a broader view of what custom logistics software covers, see logistics software development. If your tenders begin in the sales pipeline, CRM implementation for freight forwarders covers the record that sits before the bid.
Questions
Do you publish freight rates or margin rules?+
No. This page describes the workflow around a bid. Rates and margin decisions belong to your own commercial team and are never published here.
Can the system pull rates from carriers automatically?+
Only where a carrier or rate provider offers an API, and only as a per-project integration that is scoped and confirmed. It should not be assumed for any given carrier.
What is the most common way bids go wrong?+
Version confusion: several copies of the lane sheet, and the submitted one differs from the approved one. A single sheet with recorded approvals prevents most of it.
Is this different from managing supplier quote requests?+
Yes. Supplier RFQs are how you collect costs. A tender response is how you answer your client. The two connect at the rate sourcing step.
Why record lost bids?+
Because the reasons clients give are the only evidence you get about how to bid better. Without a record, each tender starts from memory.