Most requirement lists are assembled by copying a vendor's feature page, which guarantees you will select the vendor whose page you copied. This one is organised by operational capability instead.
Use it as a starting structure, delete what does not apply, and add what is distinctive about your business. A list under about 50 mandatory items is testable; a list of 200 is a document nobody reads properly, including the vendors.
How to weight
| Weight | Meaning |
|---|---|
| M | Mandatory — failure disqualifies |
| H | High — significant scoring weight |
| N | Nice to have — tie-breaker only |
Mark each item before you see any vendor. Deciding weights after demos means the weights describe the demo you liked most.
The requirements that actually separate vendors are the ones specific to your operation. Write those down first.
1. Planning and optimisation
- Multi-vehicle assignment and sequencing (M)
- Capacity constraints: weight, volume, pallets, compartments (M)
- Time windows, hard and soft, with configurable penalties (M)
- Vehicle-specific access restrictions — height, weight, zones (H)
- Driver shift rules, breaks and hours constraints (H)
- Service time by customer, with a fallback model (M)
- Time-of-day-dependent travel times (H)
- Multi-depot planning, including start and end at different depots (H if applicable)
- Fixed and dynamic planning modes (H)
- Pinned stops and manual overrides with re-optimisation around them (M)
- Scenario comparison with cost, distance, time and vehicle count (H)
- Infeasibility explanation — which constraint blocked a stop (H)
- Configurable objective weighting (H)
- Re-optimisation runtime at your peak volume (M)
2. Execution and dispatch
- Live route progress against plan (M)
- Add, remove and reassign stops during the day (M)
- Exception alerts: running late, failed stop, deviation (H)
- Communication with drivers (H)
- Reassignment of a whole route to another driver or vehicle (H)
- Depot and load-out sequencing output (H)
3. Driver mobile app
See the full driver app checklist. Minimum:
- Full offline operation for a whole shift (M)
- Proof of delivery: signature, photo, recipient, item-level (M)
- Exception capture with reason codes (M)
- Navigation handoff using service point coordinates (M)
- Normal stop completed in three interactions or fewer (H)
- Vehicle checks and defect reporting (H)
- Driver-reported data corrections (H)
4. Customer communication
- Delivery notifications by SMS and email (H)
- Live tracking page (H)
- Configurable notification sequence by customer segment (H)
- Automatic exception notification (H)
- Proof of delivery available to the customer (H)
- Self-service reschedule (N)
5. Integration
- Documented, public API covering all objects (M)
- Webhooks for operational events (H)
- Order import from your order source (M)
- Telematics integration with your devices (H)
- ERP integration for the flows you need (M if applicable)
- Bulk data export in a standard format, without vendor assistance (M)
- Sandbox environment (H)
6. Reporting and analytics
- Plan versus actual: time, distance, sequence (M)
- Stops per hour, cost per stop, by segment (H)
- Window compliance and failure reasons (H)
- Driver and route performance (H)
- Scheduled report delivery (H)
- Custom report building without professional services (H)
- Raw data access for your own BI tool (H)
7. Administration and security
- Role-based permissions with data scoping by depot or region (M)
- Single sign-on (H)
- Full audit log of user actions (H)
- Multi-entity or multi-depot structure (M if applicable)
- Configurable without vendor involvement (H)
8. Commercial and vendor
- Pricing model and five-year total cost (M)
- Uplift mechanism and cap (H)
- Implementation scope, fixed price, and timeline (M)
- Support hours matching your operating hours (M)
- SLA with credits (H)
- Data ownership and export rights on termination (M)
- Reference customers of similar size and sector (H)
- Product roadmap and release cadence (H)
- Financial stability of the vendor (H)
Turning it into a scorecard
- Assign weights before seeing vendors.
- Score each item 0–3: absent, partial, adequate, strong.
- Require evidence for any score of 2 or 3 — a demonstration, not a statement.
- Compute weighted totals per section, not just overall, so a vendor strong everywhere except the driver app is visible.
- Record the evidence alongside the score, so the decision is defensible months later.
See the vendor evaluation scorecard.
Frequently asked questions
How many requirements should we list?
Keep mandatory items under about 50 and total items under about 120. Longer lists cannot be tested properly, which means vendors answer them optimistically and you score fiction.
Should we send the checklist to vendors?
Yes, as part of an RFP, but do not rely on their self-assessment. Every vendor scores well on their own form. The score that counts is the one you assign after seeing a demonstration against your own scenarios.
What if no vendor meets all mandatory requirements?
Then one of your mandatory requirements is not genuinely mandatory, or the market does not serve your need and you should consider a different approach — a specialist product, a two-product combination, or custom development. Re-examine the requirement first; it is usually the answer.
How do we handle requirements we might need later?
Mark them as future and score them separately. Do not let speculative future needs disqualify a product that serves your current operation well — but do check that the architecture and API would allow the future capability.
Who should own the requirements list?
Operations, with input from IT, finance and drivers. Requirements lists owned by IT tend to over-weight architecture; lists owned by procurement tend to over-weight price. Both produce systems that operations then works around.
