Delivery keeps changing, and so do customer expectations around it. There are more delivery platforms to choose from every year, and AI is bringing real improvements to the category. It also means many vendors now describe their products in similar terms.
More choice is good news for buyers, but it makes an RFP harder to write well. If most of its criteria are feature questions, many vendors will answer them the same way, and the scoring won't show you which platform will hold up inside a large operation.
This guide covers eight criteria to include in an RFP for enterprise delivery management software, with what to ask vendors and what a strong answer looks like for each.
Quick answer: What should an RFP for enterprise delivery management software evaluate?
- Feature questions still belong in the RFP, but they rarely separate vendors on their own. Eight other criteria tend to make the difference: API depth, uptime and reliability, security and compliance, hybrid fleet support, reporting, integrations, implementation, and ongoing support.
- Supporting documents make vendor answers easier to compare. Public API documentation, a current SOC 2 Type II report, and contract terms for uptime, breach notification, and data export give your team something concrete to check.
- If outside couriers handle part of your deliveries, check whether the platform manages those orders end to end, with the same tracking and customer notifications as your own drivers.
- Implementation and support deserve as much weight as the product itself. A clear rollout plan, early driver involvement, and a named customer success contact after launch all shape how quickly the platform pays off.
- Weight each criterion by what would hurt your operation most if it went wrong, and agree on those weights across departments before responses arrive.
Technical and Security Criteria
These three criteria cover the technology and security review. Ask vendors to attach supporting documents to their RFP responses, so your team can check each answer.
1. API depth and documentation
At enterprise volume, the API is how orders get into the platform and how status flows back to your order systems, customer service tools, and data warehouse. A weak API shows up as delayed updates, failed syncs during peak, and engineering time spent on workarounds.
Questions to ask:
- Is the full API reference public? Your engineers can assess the integration during the evaluation instead of after signing.
- What's the rate limit, and how does it compare to your peak volume? Estimate the requests your busiest hour would generate, including status updates, and check that number against the documented limit.
- Are webhooks available for task and driver events, and how are failed deliveries retried? Webhooks remove the need to poll for updates. Retry behavior decides whether a short outage on your side means lost events.
- Is there a sandbox or test environment? You'll want to test integrations and changes without touching live deliveries.
- How are API changes versioned and announced? Unannounced breaking changes get expensive when several internal systems depend on the integration.
Strong answer: Public documentation, a documented rate limit with a path to raise it, webhooks with retry logic, batch endpoints for high-volume order creation, and a clear deprecation policy.
Red flag: Documentation that's only available after signing, or "unlimited" API calls with no published throttling policy.
2. SLA, uptime, and reliability
When deliveries run across many locations, downtime means drivers without routes, customers without updates, and a support team taking the calls. The contract terms matter, and so does how the vendor performs and communicates day to day.
Questions to ask:
- What uptime commitment is in the contract, and how are service credits calculated? Get the terms in writing, whether they come from the vendor's standard terms or an enterprise agreement.
- What does the incident history look like? A public status page shows how often incidents happen and how the vendor communicates during them.
- What are the support response times, and do they differ by plan? An issue in the middle of your delivery window needs a fast response, so check how urgent issues are defined and how quickly they're picked up on the plan you'd buy.
- How does the driver app handle poor connectivity? Drivers lose signal inside buildings, in parking garages, and on rural routes, so check whether they can keep working offline.
Strong answer: Uptime and credit terms written into the agreement, a public incident history you can review yourself, defined support response times, and a driver app that keeps working when the signal drops.
Red flag: Uptime and support terms you can't see until late in negotiation, which makes them impossible to compare across vendors while you're still evaluating.
3. Security and compliance
Any platform that holds customer names, addresses, and delivery history will go through your security review, and in regulated industries, through legal as well. A vendor with evidence ready to share makes that review much faster.
Questions to ask:
- Can you share your current SOC 2 Type II report, and what does it cover? Check the audit period and confirm the scope includes the systems you'll actually use.
- Which subprocessors handle our data, and what are they held to? Customer data may pass through hosting, messaging, and mapping providers.
- Do you support SAML SSO and role-based permissions? Large teams need access managed centrally and limited by role and location.
- How is data encrypted, and where is it hosted? Your security team will expect encryption at rest and in transit, and some contracts or regulations require data to stay in a specific region.
- How quickly will you notify us of a data breach? Look for a specific timeframe in the contract.
- How do we get our data out if we leave? Check the export window after termination before you sign.
- Will you sign a Business Associate Agreement? This applies if you deliver for healthcare or pharmacy, where patient delivery addresses count as protected health information under HIPAA.
Strong answer: A current SOC 2 Type II report that covers the product, plus SSO and encryption at rest and in transit. The contract sets a clear breach notification timeframe and data export window, and includes a BAA if you need one.
Red flag: A contract that promises breach notification "without undue delay" but gives no specific timeframe, which leaves your own notification obligations to customers and regulators open-ended.
Operational Criteria
These two criteria decide whether the platform fits how your delivery network runs day to day.
4. Hybrid fleet and orchestration support
Many enterprise delivery operations combine internal drivers with third-party delivery partners for overflow, new regions, or specialized orders. What matters is whether the platform treats partner deliveries as part of your operation or hands them off at dispatch.
Questions to ask:
- Can we dispatch to internal drivers and delivery partners from the same dashboard? Ask to see both in a live demo.
- What does the customer see when a partner delivers? Tracking links, notifications, and proof of delivery should look the same no matter who's driving.
- How are orders assigned between fleets? Check whether you can set rules by zone, order type, or capacity, and how much still has to be done by hand.
- Can we compare cost and performance across fleets? Using the same metrics for every fleet shows which partners are worth what they cost.
- How do we find and onboard new delivery partners? Some platforms give you access to vetted couriers. Others leave sourcing to you.
Strong answer: Both fleets managed and tracked in one place, a consistent customer experience, assignment rules you control, and partner performance measured the same way as your own drivers.
Red flag: A platform that can send orders to delivery partners but stops tracking them once they're handed off. You end up with one view of your own drivers and a separate one for each partner, instead of every delivery in one place, which is the gap delivery orchestration is meant to close.
5. Reporting and analytics
Delivery data feeds performance reviews, carrier negotiations, budget requests, and customer disputes. At enterprise scale, answering those questions means pulling data from many locations and many months of history.
Questions to ask:
- Which metrics are standard, and how can we break them down? On-time rate, success rate, and service time are the basics. You'll want them by location, driver, and delivery partner.
- How long is data retained on each plan tier? Year-over-year comparisons and dispute investigations both need history.
- Can we get raw data out? CSV exports cover one-off analysis. API access lets your data team pull delivery data into your BI tools.
- What proof of delivery is stored, and for how long? Photos, signatures, and timestamps settle disputes and, in regulated industries, can serve as the record auditors ask for, so check that retention matches your legal requirements.
Strong answer: Standard metrics broken down by location, driver, and partner, retention that covers your audit and review cycles, and raw data available by export and API.
Red flag: A plan that only keeps a limited window of delivery history. By the time you need last year's numbers for a review or the records behind an older dispute, the data may already be gone.
Integration, Implementation, and Support Criteria
These three criteria are easy to underweight in an RFP, and they shape most of the cost and effort after the contract is signed.
6. Integration ecosystem
Orders need to flow in from your ERP, OMS, or eCommerce platforms automatically, and delivery status needs to flow back. In a large stack, integrations are also where most of the long-term maintenance effort goes.
Questions to ask:
- Which of our systems have prebuilt integrations? Map the answer against your actual stack, system by system.
- Is each integration native, partner-built, or run through an iPaaS? Each type has a different owner when something breaks, and a different path for updates.
- Does data sync in both directions, and how often? Status updates that reach your OMS late create extra work for customer service.
- What happens when a sync fails? Ask about alerts, retries, and who gets notified.
- Who else runs a stack like ours? A reference customer with similar systems is the quickest way to check the answers above.
Strong answer: Named, prebuilt connections for your core systems, a clear owner for each one, documented error handling, and an open API for anything else.
Red flag: An integration that only works in one direction. Orders flow into the delivery platform, but delivery status and proof of delivery never make it back to your ERP or OMS, so customer service ends up checking two systems for every question.
7. Implementation and onboarding
Rolling out a new platform across many locations is mostly a people project. Dispatchers change how they plan, drivers learn a new app, and store or branch teams change how they handle customer questions.
Questions to ask:
- What does the phased rollout plan look like? Look for a defined pilot group and clear criteria for expanding beyond it.
- What does the vendor need from our team? Ask for the roles and time expected from IT, operations, and site managers.
- How are drivers trained and brought on board? A new app and new steps at each stop can slow adoption if drivers' concerns aren't addressed early.
- How does training scale across sites? Train-the-trainer models and regional check-ins help larger networks move faster.
- Can we speak with a customer who rolled out across a similar number of sites? A customer with a similar footprint can tell you what the rollout actually took.
Strong answer: A pilot with expansion criteria, a clear list of what's needed from your side, a training model that scales, and a reference with a comparable footprint.
Red flag: A rollout timeline that doesn't account for your own team's time. If the plan assumes IT and site managers are available whenever the vendor needs them, the schedule will slip.
8. Ongoing support model
After launch, the support model decides how fast issues get fixed and whether the platform keeps pace as your operation changes.
Questions to ask:
- Do we get a named customer success manager, and at which plan tier? A named contact who knows your operation saves you from re-explaining it every time something comes up.
- What are the support hours, channels, and escalation paths? Check that coverage matches your time zones and delivery hours.
- How are product feedback and feature requests handled? Your needs will change after launch, so check whether customer input actually shapes the product roadmap.
- What does account review look like after launch? Regular reviews of performance and usage keep the platform aligned as your operation evolves.
Strong answer: A named CSM who stays on the account after launch, support coverage that matches your delivery hours, and a documented escalation path.
Red flag: A support model that's strong through go-live but gets thinner afterward, just as adoption issues start to surface across sites.
Turn the criteria into a scorecard
Once your criteria are set, you need a way to score vendors side by side. Onfleet's free last-mile delivery vendor comparison tool is a spreadsheet that scores vendors against 30 criteria weighted by your priorities. It also includes demo questions, a ready-made score summary for your buying committee, and a calculator for the annual cost of your current setup, which helps with the CFO conversation.
How Onfleet Answers These Criteria
Onfleet is an AI-powered delivery orchestration platform built for operations that run internal drivers and third-party delivery partners together. Here's a summary of how it approaches each criterion:
- API depth. A public, well-documented API built for high-volume integrations, with webhooks, batch endpoints, and a separate test environment.
- Reliability. A public status page with incident history, an offline mode for low-connectivity areas, and Onfleet's highest support SLA tier on Enterprise plans.
- Security and compliance. SOC 2 Type II certified, with BAAs available for healthcare and SSO support. Security documentation is in the Onfleet Trust Center.
- Hybrid fleet support. Internal drivers and delivery partners in one dashboard, plus access to 150+ vetted couriers through Onfleet Connect.
- Reporting. Delivery performance by location, driver, and delivery partner, with raw data available by export or API.
- Integrations. Native and partner-built integrations, plus an open API for the rest of your stack. See the Onfleet partner ecosystem.
- Implementation. Guided onboarding with a dedicated customer success rep.
- Support. The same customer success rep stays with your account after launch.
How Dulux Decorator Centre rolled out Onfleet across 230+ stores
Dulux Decorator Centre, the UK's leading trade decorators merchant, needed to replace paper routes and phone updates across a network that had grown to 230+ stores.
It piloted Onfleet in about 25 stores, rolled out in phases with a train-the-trainer model, and brought drivers in early to address tracking concerns. Within six months, Onfleet was live across every store, and delivery inquiry calls dropped by about 80%. It's a useful benchmark for the implementation criterion in your RFP: a defined pilot, a phased rollout, and early driver buy-in across a large network. Read the full Dulux Decorator Centre case study.
If you're building your vendor shortlist, talk to our sales team. We'll walk your team through the API, security documentation, and enterprise terms against your own RFP.
Frequently Asked Questions About Enterprise Delivery Management Software
What should an RFP for enterprise delivery management software include?
An RFP for enterprise delivery management software should include your feature requirements plus the criteria that tend to separate vendors: API depth, SLA and uptime terms, compliance certifications, hybrid fleet support, reporting, integrations, implementation, and ongoing support. Ask vendors to back each answer with documents, such as public API docs, a SOC 2 Type II report, and an integration map. Onfleet publishes its API documentation openly and shares security documentation through its Trust Center, so buyers can verify most answers early.
How should you weight criteria in a delivery management software RFP?
Weighting criteria in a delivery management software RFP should reflect what would hurt your operation most if it went wrong. A pharmacy or healthcare shipper will usually treat security and compliance as pass/fail before scoring anything else, while a retailer rolling out across hundreds of locations may weight implementation and integrations most heavily. Agree on the weights with every department involved before responses come in, so the scoring stays consistent across vendors. Onfleet's free last-mile delivery vendor comparison tool lets teams weight 30 evaluation criteria by their own priorities and share a score summary with the buying committee.
How do you evaluate AI claims in delivery management software?
To evaluate AI claims in delivery management software, ask each vendor what specific decisions the AI makes, such as route planning, driver assignment, or ETA prediction, and what data it uses to make them. Then ask how dispatchers can review or override those decisions. A vendor that can explain this clearly and point to measurable results from customers in a segment like yours, such as lower fuel costs, more delivery capacity per driver, or higher on-time delivery rates, is far easier to compare than one that only uses the label. Onfleet publishes customer results across operations such as pharmacy delivery, medical and lab specimen delivery, grocery, and retail, which gives buyers comparable reference points.
Should an enterprise delivery software rollout start with a pilot?
A pilot is one way to lower risk in an enterprise delivery software rollout, particularly for operations with many locations. Starting with a limited group of sites or a single region lets your team test workflows, integrations, and driver adoption before expanding. It isn't the only approach, and some operations choose a broader launch when timelines are tight or workflows are consistent across sites. Whichever route you take, agree with the vendor upfront on what a successful rollout looks like. Onfleet's enterprise onboarding supports rollouts at the pace that fits your network, whether that starts with a pilot or a wider launch.
How do you calculate the total cost of ownership for delivery management software?
For delivery management software, the subscription is rarely the number that decides total cost of ownership. Implementation, integrations, and internal IT time add to the platform side, but the bigger figure is usually what your current delivery operation already costs: failed deliveries, manual dispatch hours, fuel, driver turnover, and the capacity you'd otherwise add as volume grows. The savings estimate is where most business cases get challenged, so anchor it to your own data and to results from customers with operations like yours. Be careful with time savings in particular: hours your dispatchers no longer spend planning routes only save money if you can avoid hiring another dispatcher, or if your current team can handle more deliveries. Onfleet's vendor comparison tool includes a calculator for the annual cost of your current setup, which gives finance a baseline to test those assumptions against.