The template

The drayage TMS RFP template.

Ten requirement sections written specifically for container drayage. Copy what applies, delete what doesn't, and send the same list to every vendor — including us. The questions are vendor-neutral: they protect you regardless of who wins.

Before you send it

How to use this template.

  1. 01

    Trim before you send: delete requirements that don't apply to your operation. A 40-question RFP gets better answers than a 200-question one.

  2. 02

    Require written answers, then verify the top five claims live in the demo — on your own container numbers, not the vendor's dataset.

  3. 03

    Send the same list to every vendor, including us, and require the pricing section on one page.

  4. 04

    Weight the sections before answers arrive. If demurrage is your pain, say so in the scoring — otherwise the glossiest proposal wins by default.

Section 01

Container data quality

The foundation. Every downstream feature inherits the quality of the container data, so make vendors answer in writing.

  1. 1.1

    List the data sources you collect container status from for the terminals and rail ramps in our operating markets (name them per facility).

  2. 1.2

    For each source: is it an official API, a data license, or website collection? How often does it refresh?

  3. 1.3

    When two sources disagree about the same container, what does the user see, and which source wins?

  4. 1.4

    How do you detect that a source has silently stopped updating or changed its format, and how quickly? Who is notified?

  5. 1.5

    Can the user see the origin and timestamp of each data point on screen?

  6. 1.6

    How is vessel identity resolved (name, IMO, MMSI)? What prevents a same-named vessel from attaching wrong data?

  7. 1.7

    Provide your data-accuracy or freshness SLA, if any, and your remedy when it is missed.

Section 02

Demurrage, per diem & cost control

The money section. Alerts are not the requirement — computed exposure before the charge exists is.

  1. 2.1

    Show how last free day and empty-return deadlines appear in daily operating views (not a report).

  2. 2.2

    Is exposure computed in dollars from OUR carrier agreement free-day and per-diem terms, or only shown as dates? Demonstrate with our terms.

  3. 2.3

    When is a hold that blocks pickup surfaced, and where? Before or after a driver is dispatched?

  4. 2.4

    What evidence does the system retain to dispute a per-diem invoice (gate transactions, interchange receipts, timestamps)?

  5. 2.5

    What marks an empty container as returned — a reported milestone, or verified evidence? Which evidence?

  6. 2.6

    Walk through your most recent product changes in this area and what remains on your roadmap.

Section 03

Dispatch & execution

The daily workflow. Ask for demonstrations, not descriptions.

  1. 3.1

    Demonstrate a full order-to-invoice cycle: order intake, dispatch, driver execution, document capture, billing.

  2. 3.2

    How are street turns and double moves modeled? Demonstrate creating one.

  3. 3.3

    How does appointment scheduling relate to container availability and cost deadlines on screen?

  4. 3.4

    Demonstrate bulk operations: importing, updating, and dispatching many orders at once. Time it.

  5. 3.5

    What happens to in-flight work when a vessel slips a day? Show the re-planning workflow.

Section 04

Drivers & compliance

Credentials and hours decide whether the dispatched plan is legal and executable.

  1. 4.1

    How are driver credentials tracked (CDL, TWIC, medical card, port credentials, insurance)? Who is alerted before expiration, and when?

  2. 4.2

    What does the driver need to install to run a load? What happens with owner-operators who refuse app installs?

  3. 4.3

    How is proof of delivery captured, and what metadata (signature, geolocation, timestamp) attaches to it?

  4. 4.4

    Which ELD providers integrate, and what data flows (duty status, remaining hours)? Is the integration first-party or third-party?

  5. 4.5

    Demonstrate driver settlement from completed loads.

Section 05

Documents & billing

Paper is still how drayage moves. Measure the retyping the system removes — and the errors it prevents.

  1. 5.1

    Demonstrate delivery-order intake from a forwarded email and from an uploaded PDF. What is extracted, and who verifies it before it becomes an order?

  2. 5.2

    What per-document or per-template fees apply to intake automation?

  3. 5.3

    How are interchange receipts (EIR) captured and attached to the container record?

  4. 5.4

    Demonstrate invoicing with accessorial charges from our rate agreement, and the path to our accounting system.

  5. 5.5

    Can our customers receive a self-serve quote from our website that becomes a dispatchable order? Show it.

Section 06

Customer visibility

Your customers' experience of your operation is a feature of the TMS.

  1. 6.1

    How do our customers see their container status — portal accounts, shareable links, or both? What does each cost?

  2. 6.2

    Can a party without an account (our customer's consignee) see tracking for a single shipment? How?

  3. 6.3

    What do our customers see when data is stale or unavailable — and what do they NOT see (rates, other customers, internal notes)?

  4. 6.4

    Which notification channels exist (email, in-app), and who configures them?

Section 07

Integrations

Price the connections, not just the software.

  1. 7.1

    List every integration in your proposal with its one-time and recurring cost: EDI per trading partner, accounting, ELD, terminal appointment systems, customer systems.

  2. 7.2

    For each: typical implementation time, and who does the work (your team, ours, or a paid third party)?

  3. 7.3

    What happens when we win a new customer who requires EDI — cost and timeline for that single connection?

  4. 7.4

    Do you expose our data to AI assistants or APIs we control? Under what security model?

Section 08

Latency & performance

Two latencies matter: how old the data is, and how long the screen takes. Neither appears on a feature list.

  1. 8.1

    How old is the terminal data on a typical operating screen, and how would a dispatcher know?

  2. 8.2

    Demonstrate the same filtered view loaded twice. Does the second load wait on your servers?

  3. 8.3

    What is the system's behavior during your maintenance windows, and when did the last three outages occur (duration and cause)?

  4. 8.4

    Demonstrate the system with our expected container volume on screen, not a demo dataset.

Section 09

Pricing & total cost

Require the same structure from every vendor so the quotes are comparable. A bottom-line number is not an answer.

  1. 9.1

    Price each line separately: base license (and its unit — seat, truck, container, transaction), tracking/visibility, appointment tooling, each integration, implementation, data migration, training, support tier, and expected annual increase.

  2. 9.2

    State every unit that scales the bill as we grow (users? trucks? containers? customer logins? transactions?).

  3. 9.3

    What did your average customer's total bill change by over the last two years?

  4. 9.4

    What costs extra at renewal that was included at signing?

  5. 9.5

    Provide the all-in three-year total cost of ownership for our stated volumes, on one page.

Section 10

Implementation & support

The gap between contract and value is where TMS projects die.

  1. 10.1

    Provide the week-by-week implementation plan for our operation, with the date we track our first live container and the date we invoice our first customer from the system.

  2. 10.2

    Who migrates our historical and reference data, and what does it cost?

  3. 10.3

    Is support in-house or outsourced? What are the hours, channels, and response commitments — and is support included or priced separately?

  4. 10.4

    Name three customers of our size and market we may call.

Section 11

Security & data ownership

Standard questions, but confirm the drayage specifics: your data is your leverage.

  1. 11.1

    Who owns our operational data, and what is the export path (format, completeness, cost) if we leave?

  2. 11.2

    Describe tenant isolation between customers, and between us and our own customers' visibility.

  3. 11.3

    List current security certifications and audits, with dates — and what is scheduled, not just claimed.

  4. 11.4

    Describe your AI features' data handling: what is our data used for, and is any of it used to train models shared with other customers?

Our answers

Yes, we answer this template too.

Every requirement above goes to Conterminal the same as any vendor. Invite us to your process and we return written answers to each section, a live demonstration on your own container numbers, and a proposal with every billable unit defined before you sign.

Invite Conterminal to your RFP

No RFP? No problem.

Skip the paperwork and test the product.

If your evaluation is five container numbers and a stopwatch, that works too. We'll set it up on your live operation.

Request a walkthroughSign in