Make the Freight Software RFP Score Completed Work

Key Takeaways

Most freight software RFPs score what vendors write about themselves, so every finalist answers “yes” and lands within a few points.
Write each RFP question against a sample shipment you supply, and name the evidence the vendor must submit with the answer.
Score every line on a 0–3 evidence scale, and weight sections by where your coordinators lose hours today.
Treat control items (approved carriers, approval limits, escalation) as pass/fail gates, and require at least one forced failure in the scenario pack.
Wilson, by Cartage, is an AI logistics agent and should be scored the same way: on the quotes, bookings, exceptions, PODs, invoice audits and payments it completes under the buyer’s rules.

Why do most freight software RFPs reward the wrong answers?

Because the typical RFP asks vendors to describe capabilities, and a description scores the same whether the software finishes the work or a coordinator does. A freight software RFP should score completed work: outcomes the buyer can observe on a shipment, backed by evidence each vendor must submit.

The usual template is a long list of rows answered Y, N or “roadmap,” and none of them defines what done looks like. “Supports carrier follow-up” can mean the system drafts an email for a person to send, or that it chased the carrier twice, recorded the answer and moved the shipment forward. Those are different products. Replace “Describe your carrier follow-up capability” with “On scenario B, the carrier hasn’t replied to the quote request. Show the follow-up, the reply and the resulting shipment record.” The second version has an end state you can check.

Buy freight communication software for completed work, not messages sent applies this idea to carrier messaging, and the 12 questions to ask before buying an AI logistics agent are built for vendor conversations. This guide covers the RFP document itself: questions, required evidence and weights.

How should the RFP document be structured?

Build the RFP in five parts, and send the scoring rules with the questions.

Scope statement. The modes you ship, main lanes, rough monthly volume by mode, where orders come from (ERP feed, scheduled file drop, spreadsheet, email or API), and who approves what.
Scenario pack. Three to five anonymized shipments from your operation, each with an expected end state: one clean order, one with a missing or wrong field, and at least one with a failure you will introduce.
Outcome questions. Each written against a named scenario: “On scenario C, show…” Drop “describe,” “explain your approach” and “do you support.”
Evidence requirements. For each question, the artifact that proves completion: carrier message and reply, rate confirmation, status update with its source, approval request, POD file, invoice compared with the booking.
Scoring rules. The 0–3 scale, section weights, gates and tie-breaker, fixed before responses arrive.

Which questions belong in the RFP, and what evidence should each require?

Each question should name a scenario, an action and the evidence that proves the action finished. These are the lines most freight RFPs need, by stage.

Order intake. “Take scenario A from our ERP export and show the shipment it becomes. Scenario B has no delivery appointment; show what happens.” Evidence: the created shipment and the flag raised for the missing field.
Quoting. “Request rates from our approved carriers on the scenario A lane. One won’t reply; show the follow-up.” Evidence: requests, follow-up, replies recorded on the shipment, and the comparison against our rate target.
Booking. “Book within our approval limit, then show what changes when the lowest rate is above it.” Evidence: the rate confirmation and the approval request with the approver’s context.
Pickup and tracking. “Confirm pickup and show where each status update came from.” Evidence: the confirmation and the source behind every status change.
Exceptions. “The carrier misses pickup on scenario C.” Evidence: the carrier contact, the team notification, and a rebooking from approved carriers or an escalation.
POD close-out. “The POD hasn’t arrived after delivery.” Evidence: the POD on the shipment, or an escalation after the agreed window.
Invoice audit and payment. “The invoice includes a detention charge that wasn’t booked.” Evidence: the discrepancy flagged, the payment held for approval, and the payment record after a decision.
Residual manual work. “List every task our coordinators will still do on these scenarios after go-live.” Evidence: a written, task-level list. Vendors find this one hard to answer vaguely, which is why it belongs in the document.

How should buyers score and weight the responses?

Score each question 0–3 on the evidence submitted, weight sections by where your team’s time goes, and keep control items out of the weighted total.

0: claim only, or evidence “available on request.”
1: the system drafts or alerts; a person sends, books or updates.
2: completed on the clean scenario with evidence, but the failure scenario ends with a coordinator rebuilding the context.
3: completed on both, and any escalation arrives with what happened, what was tried and the decision needed.

Rules that keep the scores honest:

Gates before weights. Booking only approved carriers, respecting approval limits and escalating when no rule applies are pass/fail. Failing a gate removes a vendor, whatever its total.
Weight by pain, not feature count. If coordinators spend most of their day chasing carrier replies and PODs, those sections carry the most points.
No points for integration names. Score intake on whether scenario A, in the format you actually export, became a usable shipment.
Same rules for every vendor. If one demo required approval on every booking and another didn’t, rerun one of them.
Residual-work list as tie-breaker. The shorter, more specific list usually belongs to the vendor doing more of the work.

What does a weighted RFP scorecard look like in practice?

Here is an illustrative RFP scorecard for a distributor whose coordinators lose the most time on carrier follow-up and exceptions. Weights total 100 points. Weighted points = weight × score ÷ 3.

Section	Weight	What earns a 3	Vendor A	Vendor B
Order intake	10	Scenario A becomes a shipment; missing field is flagged	2	2
Quoting and follow-up	20	Non-responding carrier is chased; replies recorded against the rate target	1	3
Booking within limits	10	Booking under limit proceeds; over-limit rate goes to approval with context	2	2
Pickup and tracking	15	Pickup confirmed; every status shows its source	1	2
Exception handling	20	Missed pickup leads to rebooking from approved carriers or a clear escalation	1	3
POD close-out	10	POD attached, or escalated after the agreed window	1	2
Invoice audit and payment	15	Unbooked charge flagged; payment held for approval	0	2
Weighted total	100		35	80
Control gates	Pass/fail	Approved carriers only, approval limits respected, escalation works	Pass	Pass

On a yes/no checklist, Vendor A would likely have scored close to Vendor B. The gap appears only because each row demanded evidence on a scenario with a failure in it. Set your own weights before the RFP goes out, not after responses arrive.

How does Wilson, by Cartage, answer an RFP built this way?

Wilson, by Cartage, is an AI logistics agent built to be scored on completed work, so the expected answer to every line above is a shipment record, not a paragraph. New to the category? Start with what an AI logistics agent is.

Wilson replaces the TMS for freight execution and connects to the company’s ERP and existing order data flow: an ERP feed, scheduled file drop, spreadsheet, email or API. Wilson works with SAP, NetSuite, Microsoft Dynamics 365, Oracle, Infor, Epicor, Sage, Acumatica, and other ERP environments, with the exact connection depending on the customer’s data flow and scope.

Against the scenario pack, Wilson quotes the customer’s approved carriers, negotiates against the customer’s rate targets under configured rules and approval limits, and books only approved carriers, tendering them first. Cartage can introduce additional capacity, but the customer approves any carrier before Wilson uses it; if no approved carrier accepts, Wilson escalates. It tracks each load with the best available source and follows up by email or phone when that source is silent. It audits and reconciles carrier invoices against the booking and pays from the Wilson Wallet under approval rules.

For the evidence column, messages, confirmations and changes are recorded in each shipment’s history. For the residual-work question, the answer is specific: approving carriers, decisions outside configured limits, and anything Wilson escalates. Wilson starts with assisted execution, and the scope can expand step by step as the team gains confidence.

If you have an RFP draft or a scenario pack, send us one real shipment from it and score Wilson’s evidence against your own rubric.