Most logistics software RFPs are too vague to produce useful vendor responses. They describe the operation at a high level, ask for pricing, and get back a range of quotes that cannot be compared because they cover different scopes. A logistics software RFP that produces comparable, useful vendor responses requires specific operational context, explicit evaluation criteria, and structured questions that vendors cannot answer generically.
Key Takeaways
- A logistics software RFP should specify the exact data sources the software must integrate with (WMS name and version, TMS vendor, carrier list), not just "our WMS and TMS."
- Evaluation criteria must be weighted and shared with vendors in the RFP: price, integration depth, references in the specific logistics vertical, and implementation timeline should each carry a defined percentage weight.
- For custom development RFPs, include a representative data sample and a sample reporting requirement so vendors can scope the integration accurately rather than guess.
- Request implementation references in the same logistics vertical (3PL, distribution center, freight broker) rather than general references — vertical experience determines whether the vendor understands the domain.
- Timeline requirements should specify the hard date constraints (go-live before peak season, before a customer commitment date) separately from the preferred timeline.
What a Logistics Software RFP Is For
An RFP (request for proposal) serves three purposes: it defines what you need precisely enough that vendors can scope it accurately, it creates a structured basis for comparing different vendors' responses, and it establishes the evaluation criteria before you see the responses.
The third purpose is the most undervalued. Evaluating vendor responses against criteria you defined before seeing them prevents the common problem of re-weighting criteria based on which vendor had the most impressive presentation. Define the weights first.
Logistics software RFPs are appropriate for three procurement types:
Off-the-shelf platform procurement: Selecting a WMS, TMS, fleet management platform, or logistics analytics platform from a set of vendors. The RFP collects functional capability responses, pricing, and implementation approach.
Custom development procurement: Selecting a development agency or systems integrator to build a custom analytics application, workflow tool, or client portal. The RFP defines the capability requirement and collects scoped development proposals.
Implementation services procurement: Selecting an implementation partner for a platform already selected (WMS go-live, TMS implementation). The RFP focuses on implementation methodology and references.
Each type requires a different RFP structure. The sections below cover the elements common to all three types, with notes on what changes by type.
Section 1: Company and Operation Overview
Vendors need enough operational context to scope your requirement accurately. Generic descriptions produce inaccurate scopes.
Include:
- Operation type: Distribution center, 3PL, freight broker, logistics service provider, shipper — and the specific business model (contract logistics, e-commerce fulfillment, temperature-controlled, multi-client)
- Facility count and locations: Number of facilities, states or countries of operation, building square footage
- Volume metrics: Orders per day, shipments per month, SKU count, peak-to-average volume ratio
- Current technology stack: Every system currently in use with vendor name and version: WMS (Manhattan Associates v2022.1, Blue Yonder 2021.2, etc.), TMS, ERP, carrier systems, automation platforms
- Team size: Operations headcount, IT team size (relevant for estimating implementation support capacity)
The precision of the current technology stack listing is critical for custom development and integration RFPs. A vendor responding to "our WMS" cannot scope an integration. A vendor responding to "Manhattan Associates Active Omni 2022.1 with a REST API and a PowerBI dataset export" can.
Section 2: Requirement Specification
The requirement section is where most RFPs are too vague. "We need a dashboard for our logistics operations" generates useless responses. A specific requirement specification generates comparable proposals.
For Off-the-Shelf Platform RFPs
List functional requirements in a structured format with priority levels:
| Requirement | Priority | Notes |
|---|---|---|
| Multi-carrier tracking in a single interface | Must have | FedEx, UPS, 15 LTL carriers |
| EDI 210 invoice processing | Must have | 45 carrier invoices daily |
| Customer SLA reporting | Must have | 3 client tiers with different SLA windows |
| API integration with Manhattan WMS | Must have | Outbound shipment status updates |
| Mobile app for driver proof of delivery | Nice to have | Driver pool of 12 |
Must-have requirements are non-negotiable. Vendors who cannot meet them should be eliminated before evaluation, not during it. Nice-to-have requirements distinguish vendors who can meet them from those who cannot.
For Custom Development RFPs
Include:
- A description of the specific capability gap the application fills
- The data sources the application must integrate with (vendor, version, access method if known)
- A list of dashboard views or workflow steps with metrics defined
- The user roles and access control requirements
- A sample data export from the primary source system (redacted for any PII)
- A sample reporting output (the Excel report the application should replace)
The sample data export and sample report are the most valuable elements of a custom development RFP. They let vendors assess integration complexity with real data rather than assumptions.
Section 3: Integration Requirements
Integration requirements deserve their own section in every logistics software RFP. They are the most common cause of cost and timeline overruns when underspecified.
For each system the software must integrate with, provide:
- System vendor and version: Manhattan Associates Active Omni 2022.1, not "our WMS"
- Available integration methods: REST API (document the base URL format if possible), database view, flat file export (SFTP, format, frequency), EDI (transaction sets supported)
- Authentication method: API key, OAuth 2.0, IP allowlist, database credentials
- Data volume: Records per day for the relevant data types
- IT contact: The internal contact who manages the source system and can support integration testing
Ask vendors to describe their experience integrating with each named system and request references for previous integrations with the same system.
Section 4: Implementation Requirements
Implementation requirements define the non-functional requirements that determine how the project will run, not just what it produces.
Include:
- Timeline: The required go-live date (hard constraint) and preferred go-live date (target)
- Implementation model: On-site vs. remote implementation; expected client team involvement
- Training requirements: Who needs training, and what format (on-site, video, documentation)
- Data migration: Whether historical data from the current system must be migrated to the new system
- Testing requirements: Whether the client will conduct UAT and what the acceptance criteria are
- Change management: Whether the vendor is expected to support user adoption
Section 5: Pricing Structure Request
Ask vendors to provide pricing in a structured format, not a narrative. Comparable pricing requires comparable structure.
For off-the-shelf platforms, request:
- Base subscription cost per year
- Per-user or per-facility licensing cost
- Implementation services cost (separately from subscription)
- Integration development cost (if integrations are billed separately)
- Annual maintenance and support cost
- Total 3-year cost of ownership
For custom development, request:
- Development cost (fixed price or time-and-materials; if time-and-materials, provide an estimate with a cap)
- What is included in scope (enumerate what deliverables the price covers)
- Change order process (how out-of-scope requests are handled)
- Post-deployment maintenance pricing
For both types, ask for a cost breakdown by phase or component. A single total number cannot be evaluated against scope.
Section 6: Evaluation Criteria
Define your evaluation criteria and their weights in the RFP. This keeps the evaluation objective and signals to vendors what matters most.
A representative weighting for a logistics analytics custom development RFP:
| Criterion | Weight |
|---|---|
| Integration experience with named source systems | 25% |
| References in the same logistics vertical | 20% |
| Application quality (portfolio review) | 20% |
| Development cost | 20% |
| Implementation timeline | 10% |
| Ongoing support and maintenance approach | 5% |
Adjust weights to reflect your priorities. If timeline is the critical constraint (go-live before peak season), weight it at 30% and reduce cost. If budget is the binding constraint, weight cost at 35%.
Sharing the evaluation criteria with vendors in the RFP is good practice. It focuses responses on what actually matters and reduces the padding in vendor proposals.
Section 7: Reference Request
References are the most predictive evaluation signal for logistics software vendors. Request:
- Three implementation references in the same logistics vertical (3PL, distribution center, freight broker)
- Reference contact name, title, and direct contact information (not a general email)
- The scope of the engagement (application type, integration complexity, timeline)
- The go-live date (to assess currency of the reference)
For custom development vendors, also request portfolio examples: screenshots or demo access to production applications built for other logistics clients.
References in the same vertical matter because logistics domain knowledge is specific. An analytics application developer who has built WMS integrations for distribution centers understands the data model in ways a general application developer does not.
Logistics Software Procurement Consulting
Operations teams evaluating WMS, TMS, or custom development vendors sometimes need a vendor-independent technical partner to structure the RFP and evaluate responses. LOW/CODE Agency consults on custom logistics analytics and workflow application procurement for operations that want expert input on development scope, integration requirements, and vendor evaluation.
Schedule a consultation with our Senior Partners to discuss your logistics software procurement requirements.
Frequently Asked Questions
What sections should a logistics software RFP include?
Company and operation overview, requirement specification, integration requirements (with named source systems), implementation requirements, pricing structure, evaluation criteria with weights, and reference request.
How specific should a logistics software RFP be about technology?
Very specific. Name every source system with vendor and version. Vendors who cannot see the exact integration requirement cannot scope it accurately.
Should I share evaluation criteria with vendors in the RFP?
Yes. Sharing evaluation criteria focuses vendor responses on what matters and keeps your evaluation objective. Define the weights before you see the responses.
What references should I request from a logistics software vendor?
Three references in the same logistics vertical (3PL, distribution center, or freight broker), with direct contact information and the scope and go-live date of each engagement.
What is the most common mistake in logistics software RFPs?
Underspecifying integration requirements. "Our WMS and TMS" tells vendors nothing. "Manhattan Associates Active Omni 2022.1 with REST API access" lets them scope accurately.
Should I include sample data in a custom logistics development RFP?
Yes. A sample data export from the primary source system (redacted for PII) and a sample of the reporting output the application should replace are the most valuable elements for accurate custom development scoping.