A freight software request for proposal (RFP) should give every shortlisted vendor the same scope and questions. The demonstration should then test the same freight workflows with the same sample data. That makes it easier to distinguish a capability shown working from a feature described in a sales presentation.
Download the freight software RFP and demo scorecard to collect written responses, record live evidence and compare up to three vendors. This template is for buying software. It does not request freight rates from carriers or agents.
Download the editable RFP and demo scorecard
The workbook has five tabs:
The sample criteria and weights are a starting point. Agree the scope, applicability, weights and required items before vendor demonstrations.
Describe your operating model before asking for product claims. Include the modes and services you sell, offices and legal entities, customer and internal user roles, expected transaction volume, current systems and required data exchanges.
Ask each vendor to state whether a requirement is included in its proposal, requires configuration, needs another module or integration, requires development, or is unavailable. Request a supporting document and a named owner for any work outside the standard product.
| RFP area | Evidence to request |
|---|---|
| Functional scope | Included modules, supported workflows, limitations and exclusions. |
| Commercial model | License basis, billable event, included usage, tiers, overages and sample invoice. |
| Data and integrations | Field maps, supported connections, system-of-record rules and error handling. |
| Security and access | Roles, customer account boundaries, identity controls and audit records. |
| Migration and delivery | Data responsibilities, implementation plan, tests, staffing and acceptance criteria. |
| Support and exit | Support terms, renewal rules, export formats and transition obligations. |
Compare the total budget separately with the freight software TCO worksheet. A strong demo score does not establish the full cost of the proposal.
Send vendors the same anonymized test pack in advance. Include a sample carrier rate sheet with inconsistent charge names, a customer request, an approval exception, an accepted quote and a booking handoff. Identify the CRM and TMS records that should be created or updated.
Ask the presenter to complete the workflow live while your team records the result:
Allow each vendor the same time and the same opportunity to explain configuration requirements. Record a link, screenshot reference or evaluator note for each result. A slide describing a future capability is not the same evidence as a working demonstration.
The template starts with a 0–4 scale:
| Score | Meaning |
|---|---|
| 0 | The test failed or the vendor did not show it. |
| 1 | The result required a manual workaround. |
| 2 | The result was partial or needs substantial configuration. |
| 3 | The demonstrated workflow met the agreed test. |
| 4 | The workflow met the test and showed useful controls or handling of exceptions. |
For an applicable requirement, weighted points = score ÷ 4 × criterion weight. The weighted percentage divides earned points by the total weight of applicable tests.
Leave a score blank while the test is pending; enter 0 when it was assessed and failed or was not shown. The workbook labels a vendor incomplete until every applicable test has a numeric score. An item marked must-have with a score below 3 appears as a gate issue. A high overall score does not clear that issue.
Set applicability once for all vendors. Removing a test only for a vendor that performs poorly would make the percentages incomparable.
Bring sales, pricing, operations, IT, finance and the project owner into the evidence review. Check which gaps can be resolved during configuration, which require paid development, and which change the intended operating model. Ask the vendor to put any remediation and acceptance test in writing.
Use the scorecard alongside references, contractual terms and the three-year cost model. After selecting a provider, move the agreed scope and tests into the freight software implementation plan. The scorecard records the buying decision; that guide covers migration, rollout and adoption.
Download the software RFP and demo scorecard, agree the tests with your buying team and send the same scope to every shortlisted provider. If VelocityOS is one of the options, request a demonstration using your test scenarios.
The RFP response is the vendor’s written description and commitment. The demo score records what your evaluators observed against a predefined test. Keep both, including any difference between the answer and the demonstration.
Enter zero if the test was due and the vendor did not demonstrate it. Leave it blank if the test has been scheduled for a later session; the summary will remain incomplete.
Agree and record weights before demonstrations. If your requirements change, document the reason, revise the rubric for every vendor and rerun affected tests where needed.
No. Review unresolved must-have items, evidence quality, implementation dependencies, total cost and contract terms before approving a vendor.
No. This template evaluates software providers and their demonstrated capabilities. A carrier or agent RFQ requests comparable transportation rates and service terms for freight movements.