How to Write a TMS RFP: Our Experience [+ 5 Free Templates]

We answer transport management system RFPs (Request for Proposal) every week. Some are a pleasure to work through. Some are a lesson in what not to do.

This article is what I'd build if I were running a TMS selection process from scratch today. It's based on RFPs we've responded to, patterns that repeat across companies and industries, what most of them include, and which common mistakes we see.

If you're a sourcing specialist, most of this will feel familiar. Hopefully some of it saves you at least one unnecessary clarification round.

What is a TMS RFP?

A TMS RFP (Request for Proposal) is a structured document you send to transport management system vendors. It describes your logistics operation and asks each one to propose how their system would handle it, against the same set of requirements. The whole point is comparability. Same questions, same format, same context, so what comes back can be lined up side by side instead of read as five separate sales pitches.

You don't always need one. An RFP earns its keep when the decision is complicated, or when you'll have to justify it to other people internally. If your logistics operations are simple, a product demo + a call with a few vendors will suffice.

Do you really need to run a TMS RFP tender?

Getting this wrong is the most expensive mistake in the whole TMS selection process. Decide this before anything else.

It comes down to how complex your logistics are, not how big your company is.

Run a structured TMS RFP tender if you ship from several sites, use multiple transport modes, and need the system to plug into your ERP. That's when you need every vendor lined up side by side, so nothing important slips through. Vendors connect to carriers in very different ways. One calls it "native," the next quietly routes it through somebody else. In a loose process, you won't catch that until after you've signed. Too late.

Skip the formal RFP tender if you run a single site with a handful of carriers and you already know what you need. Why? Because the moment you run an RFP, you've put yourself in the enterprise pricing tier. 2-3 good demos with pointed questions often get you a better system, cheaper, and faster. Tell those 2-3 vendors what you ship and what you're trying to solve, then ask them to show you in their live system. You'll know within the hour. And if you mostly ship parcels rather than pallets or freight, you may not need a full TMS at all - multi-carrier shipping software is a different, lighter category built for that.

So, be honest about which one you prefer before you start. Running an RFP you didn't need is the slowest, priciest way to buy a TMS.

Running an RFP you didn't need is the slowest, priciest way to buy a TMS.

Another warning if you do go the full-RFP route. A process loaded with governance language, methodology frameworks, and fixed-price demands takes weeks to respond to, and the vendors who can absorb that overhead tend to be the big, established ones. So if a leaner, more modern platform would actually serve you better, an overly bureaucratic process may quietly filter them out before you ever see a demo.

The goal is to find the right solution for you. Design the process around that, not around managing the process itself.

The TMS RFP process in 9 steps

A TMS selection doesn't have to be complicated. But it does need a clear sequence. Skip steps and you'll pay for it later - usually during implementation, when assumptions that should have been clarified early on become expensive surprises later.

Done well, the whole thing takes 8 to 12 weeks. Less for a simple scope, and it rarely needs more.

Here's the sequence that works:

1. Market scan. Before you write a single requirement, spend time understanding what's out there. The TMS market has moved a lot in the last five years: there are good enterprise platforms, good mid-market platforms, and genuinely capable modern SaaS transport management software solutions that didn't exist five years ago. Build a longlist of 5-8 TMS vendors worth approaching.
2. NDA. Send it early. You'll be sharing operational data like volumes, carrier names, and internal system details, and a signed NDA before the RFP goes out is standard practice that protects both sides.
3. RFI (optional). A short Request for Information makes sense if your longlist is broad and you want to filter before investing in a full RFP process. Keep it to one page: company background, key capabilities, rough pricing range. Enough to shortlist without asking vendors to write essays.
4. RFP. The core document. It gives every vendor what they need to propose accurately. More on this in the next chapter.
5. Q&A window. Always include one. Vendors will have questions, and the answers often improve every proposal you receive. Run it in writing, share all questions and answers with all vendors simultaneously. Keeps the process clean and comparable.
6. Shortlist and presentations. Score the written proposals, then invite 2-3 vendors to present. A presentation should include a live system walkthrough based on your actual use cases, not a generic demo. If a vendor can't show you your scenario in their system, that's useful information.
7. Second round (if needed). For a complex decision, a deeper session focused on the specific gaps like security, integration, commercial terms, is worth the time. Don't schedule it unless you have real questions left.
8. Decision and contract. Get aligned internally before you negotiate. Know your must-haves, your acceptable compromises, and your walk-away points.
9. Onboarding. This doesn't end at signature. The best RFP outcomes have an onboarding plan agreed before the contract is signed.

TMS RFP timeline you can copy

Rough duration by scope:

• Single straightforward site: 6 to 8 weeks (you may not need a full RFP).
• Multiple sites + ERP integration: 8 to 12 weeks.
• Global, multi-entity, complex integration: 12 to 20 weeks, with two presentation rounds likely.

Download the RFP timeline template (.docx)

What to include in your TMS RFP document

The RFP document is your single most important tool in this process. A good RFP document does most of the evaluation work for you, so keep it focused. A tight 10-page RFP beats a 30-page one that tries to cover everything.

1. Cover letter and objective

One page. Who you are, what you're looking for, why now. Keep it factual. Vendors don't need a vision statement, they just need to understand your operational problem.

2. Timeline

A clear schedule with real dates: RFP issue, Q&A deadline, submission, presentation window, decision. Vendors plan their response effort around this. Vague timelines get you vague proposals.

3. Company and operational background

This is where most RFPs fall short, and it's the difference between comparable proposals and a clarification round. Don't just describe your business, but describe your logistics operation. How many sites. How many legal entities. What transport modes (parcel, LTL, FTL, air, sea, rail). Which regions. Approximate volumes. Current systems. What "good" looks like also changes by sector, the requirements for electronics, machinery, chemicals, or printing and packaging manufacturers aren't the same. This is the context vendors need to scope their proposal accurately. If you don't provide enough detail here, you'll spend two weeks answering clarification questions that could have been avoided entirely. It gets its own section below, in the next chapter.

4. Functional requirements

A table of what the system needs to do prioritized by importance: must-have / should-have / nice-to-have (Excel is fine). Ask vendors to respond to each requirement with their level of coverage: a) native, b) third-party, c) customization, or d) not supported. This is what makes proposals comparable. More on how to build this list further down.

5. Evaluation criteria

Tell vendors how you will make the decision: functionality, price, implementation approach, references, security, team. Share the weighting if you're willing to. The more transparent you are, the better the proposals.

6. Pricing model

Ask for a full breakdown: subscription, implementation, transaction fees, support, anything else. Ask for a sample invoice if possible. Pricing structures vary a lot between vendors, and the hidden costs have a habit of showing up late. Try to find those out early.

7. Response format

Tell vendors exactly how you want the proposal structured, and if you provide them templates, require their use. Comparable proposals save you days during evaluation, and the format is entirely in your control.

Download the RFP document template to start from the full structure above:

Download the RFP document template (.docx)

The operational information most TMS RFPs leave out, and why it's the most important one

This is the chapter I wish every TMS RFP author would read first.

We respond to a lot of TMS tenders. Almost every proposal we write needs a clarification round, and it's rarely because the requirements were unclear. It's because the operational context wasn't there: volumes, site structure, carrier landscape, current systems.

The RFPs that required a full clarification round nearly always have one thing in common:

We've seen companies spend weeks crafting evaluation criteria and requirement lists, then send an RFP that doesn't mention how many shipments they process per month.

Without it, vendors guess. And when they guess, the proposals come back generic, the pricing is not final, and there's nothing solid to compare.

For example, a global manufacturer with 10 warehouses and SAP needs a completely different proposal than a single-site distributor running their logistics on spreadsheets. If a vendor can't tell which one you are, they hedge, and you end up with proposals that commit to nothing.

The fix takes an afternoon. Answer these ten questions in the RFP before it goes out.

1. Organization and scope. How many legal entities and sites are in scope? Is the rollout parallel or phased? How independently do sites operate - separate carrier contracts, separate teams?
2. Shipment volumes. Monthly and daily shipment counts per site, average and peak. Any seasonality. Inbound versus outbound split.
3. Transport mode breakdown. What share is parcel, LTL, FTL, air, ocean? Which modes are growing? Which are most operationally critical?
4. Carrier landscape. How many carriers per site and per mode? Shared across sites or managed locally? Any strategic carriers that must be prioritized, or customer-nominated carriers you can't change?
5. Geography and trade lanes. Which regions are in scope? Which lanes matter most: domestic, cross-border, intercontinental? Key ports or logistics hubs?
6. Current state. How are shipments planned, booked and tracked today? In ERP, spreadsheets, carrier portals, email? What are the main pain points in the current process?
7. Financial setup. Who pays for transport - one entity or several? Any third-party or customer account numbers? How is freight cost captured and validated today?
8. Business model. B2B, B2C? If mixed, the split. The operational and system requirements differ quite significantly.
9. Integration landscape. Which systems need to connect to the TMS: ERP, WMS, CRM? Any existing carrier integrations to maintain? How automated does it need to be from day one?
10. Timeline and constraints. Is there a go-live target? Any internal milestones like financial year end, peak season, system migrations, that affect the schedule?

None of this is hard to write down. But it changes everything about what comes back.

Download the operational information checklist to turn these ten questions into a fill-in table you drop straight into your RFP:

Download the operational information checklist (.docx)

How to write TMS functional requirements

Functional requirements are the heart of the RFP. Get them right and you get a clear, comparable picture of what each vendor can and can't do. Get them wrong and you might spend weeks decoding answers that all say "yes."

The goal isn't the longest list. It's the most honest one.

Prioritize ruthlessly: must-have, should-have, nice-to-have

Not everything you want is equally important. Use three categories and stick to them:

1. Must-have (M): non-negotiable. A vendor who can't meet it is out, whatever else they bring.
2. Should-have (S): important, but you can live with a workaround or a near-term roadmap promise.
3. Nice-to-have (N): good to know about, but it sits behind everything above.

Most lists have far too many must-haves. If everything is critical, nothing is. Be honest about what would genuinely stop the system working for you, and mark only those as must-haves.

Ask vendors to classify functionality coverage: native / third-party / customization

For every requirement, make them answer with one of these:

This column is where proposals earn or lose your trust. A vendor who answers honestly and writes not supported where it's true shows you how they'll behave as a partner. A vendor who answers native to everything is telling you something important too.

Be specific in the question

"Does the system support carrier pricing?" will get you a useless "yes". "Can the system calculate the freight price for every carrier, including ones without a pricing API, and show them side by side per shipment?" gets you something you can actually evaluate.

Where does ERP end, and TMS begin?

One of the most common sources of confusion in transportation management system evaluations is where the TMS ends and the ERP begins.

Financial processes like GL coding, landed cost, and freight audit are often handled on the ERP side, with the TMS feeding the data to the ERP. That's normal, and often the right setup. But it has to be spelled out. When a vendor answers "handled via ERP integration" on one of your must-haves, dig into exactly what that means for your implementation, and who builds it.

Specify the goal, not the technical solution

Describe what you need to achieve, not how the system should technically achieve it. Over-prescriptive requirements knock out good solutions for the wrong reasons. Leave vendors room to show you a better way than the one you had in mind, because sometimes they have one.

A 30-line list of honest, prioritized requirements will tell you more than a 150-line spreadsheet where everything's critical and every vendor has ticked every box.

A starter set of TMS requirements to adapt

Most first-time buyers want a headstart on the list itself, so here's an example set from our experience, already categorized, which you can adapt to your operation. The full list is downloadable in the scoring sheet below, this is enough to see the shape of it.

Download the functional requirements scoring sheet, already built with priorities and a coverage column per vendor:

Download the functional requirements scoring sheet (.docx)

How to compare TMS cost (and build a 3-year model)

"How much does a TMS cost?" is the question buyers most want answered and vendors love to avoid. But, subscription fee is rarely your final cost. For a mid-sized, multi-site shipper, implementation and integration can even drive the three-year total more than the monthly fee does, and that's the line vendors stay the most vague about. So the skill here is structuring the question so the answers come back comparable and the real cost is visible.

As a rough orientation, mid-market cloud-based TMS tends to run from a few hundred to a few thousand euros a month, while traditional enterprise systems run from tens of thousands to over a million a year, with implementation that can reach six or seven figures. That's a wide range, which is exactly why a like-for-like model matters more than any single number. For a sense of what real TMS providers charge, see our research on the top TMS providers.

TMS pricing components

Almost every TMS quote is some mix of these:

Build a three-year cost model before you compare

A TMS vendor who looks cheap on subscription can turn out to be the most expensive once implementation, per-transaction fees, and carrier onboarding are in. Run every vendor through the same model:

3-year cost = implementation + (annual subscription × 3) + (per-shipment fee × annual volume × 3) + support + expected carrier and integration add-ons.

Use your real volumes, not a vendor's tidy example. That one table tends to reshuffle the shortlist.

Watch the different pricing components, not just the base fee

Some vendors price low on subscription and make it back on transaction fees or per-carrier charges. That's not automatically a bad thing, but it changes who's cheapest as you grow. If your volume is climbing, a per-shipment model can overtake a flat one quickly. Ask for a sample invoice and the subscription terms so you're comparing what you'll really pay, not a headline rate.

One question worth putting to every vendor: are new carrier integrations included, or billed each time? Some TMS platforms charge €5,000-€10,000 per new carrier integration and take months, others build new carrier integrations at no extra cost. For a mid-sized shipper adding carriers over the years, that single answer can move the three-year total more than the subscription line ever will.

How to evaluate TMS proposals beyond price

The proposals are in. They all look reasonable, most say yes to your requirements, and the pricing is in a similar range. Now what?

This is the point where teams quietly fall back on price, because everything else feels harder to compare. Don't. Here's what actually separates them.

1. Carrier connectivity.

For a TMS, carrier connectivity is the foundation. How does the vendor actually connect to carriers, through direct API/EDI integrations, third-party aggregators, or not at all (email + PDF orders regardless of their IT capabilities)? What happens when you need a carrier they don't support yet, how long does that take, and what does it cost?

A vendor with deep, direct carrier connectivity is a different animal from one routing everything through a middleware layer. You feel the difference in booking reliability, in tracking quality, and in whether you can add a carrier without opening a new commercial negotiation every time.

2. Carrier service level harmonization - this one matters more than most people realize.

Carriers aren't equal in their digital capabilities. Some have sophisticated APIs that cover real-time pricing, ETA prediction, address validation, label generation, detailed tracking events. Others send you a booking confirmation by email and that's the end of the conversation. Most carrier networks have both kinds in them at once.

That becomes your problem the moment you connect your ERP or WMS to the TMS. If your integration expects a full set of data back from every carrier like booking confirmation, tracking link, label, cost estimate, but some carriers can't provide it, you get exceptions, manual workarounds, and holes in your data. One weak carrier breaks the consistency of the whole workflow.

There are two ways different transportation management software providers deal with this, and it's worth deciding which you want before you read a single proposal:

• A thinner TMS passes through whatever each carrier provides, and it'll be your problem to deal with the gaps in your ERP or in manual work. Simpler integration, more exceptions to handle on your part.
• A TMS that normalizes the data & fills the gaps itself: calculates freight cost from your uploaded freight rate sheet when there's no pricing API; estimates transit time when there's no carrier-provided ETA; generates shipping labels when the carrier can't produce them; when they don't have tracking, it lets your carriers input tracking milestones manually, and more. The software fills the gaps in the technical capabilities of your carriers, and your ERP sees one consistent structure.

When evaluating proposals, ask vendors directly: how do you handle carriers with limited digital capabilities? The answer tells you a great deal about how mature their platform actually is.

3. Integration honesty.

Pay close attention to how vendors describe the integration scope (who does what). A proposal that says plainly "ERP-side development is on you, here's what we provide and how we support it" is more trustworthy than one that implies "seamless integration" without explaining which party handles which integration (you or them). Integration surprises are one of the most common reasons TMS projects blow through time and budget.

4. Implementation approach.

A phased approach, manual operational validation first and automation second, is usually lower risk than a big-bang launch. You get to confirm the system works for your real workflows before you lean your whole operation on it. From our side of the table, the vendors who propose this without being prompted have usually been through a messy go-live before. The ones pitching full automation from day one often haven't.

5. References

Ask for references from companies with similar operations, not just similar size or headcount. A reference from a single-site distributor isn't particularly useful if you're running a multi-site manufacturing operation with SAP integration. And ask the pointed questions: "How did the carrier onboarding go?" "How did the integration process go?" "What happened when something didn't work as expected?"

6. The proposal itself.

How a TMS vendor responds to your RFP is a preview of how they'll behave as your partner. Did they answer your questions directly, or wrap everything in qualifications? Did they flag the gaps honestly, or claim full coverage across every requirement? Did they show they understood your operation, or did they send you a slightly modified version of their standard deck?

A proposal that admits not supported in two places and explains why is worth more than one that says yes to everything. You'll find out the truth either way. Better to find it during evaluation than at go-live.

Download the vendor evaluation matrix to score vendors on weighted criteria:

Download the vendor evaluation matrix (.docx)

The TMS vendor presentation round

Written proposals tell you what a vendor claims. Presentations tell you whether they can back it up.

By this stage you should have a shortlist of 2-3 vendors. The goal of the presentation round is to put the proposal under real pressure, and see if the system works against your actual scenarios.

Ask for a live walkthrough, not a demo

A demo is a rehearsed sequence showing the system at its best. A walkthrough is you saying "show me how you'd handle this shipment, out of our Netherlands warehouse, with our carrier, at our agreed rate," and watching what actually happens.

Prepare 2-3 real scenarios from your own operation before the meeting: a standard outbound booking, a shipment that needs a spot quote, and something awkward like a delayed shipment, or a carrier that doesn't provide tracking. When a vendor keeps steering back to the polished demo instead of running your scenario, that's your answer right there.

Challenge the gaps

Every TMS proposal has them. Go straight at the parts where a vendor answered partially or where you've got doubts, and stay there. Don't let them slide back to something that works beautifully. How exactly does this work? Who does what? What happens when it doesn't work as expected?

Get the right people in the room

On the TMS vendor side, the people presenting should be the ones who will actually work on your implementation, and not just the sales team. Ask for that explicitly. On your side, bring someone from IT (if integration is in scope), and at least one person who will actually use the system every day. They ask different questions than procurement does, and you want both sets of questions asked.

Second round, only if needed

For a complex decision, a second session focused on specific topics is worth the time. Example topics to be covered:

• Security and data protection - request a pentest report or security documentation if your IT or information security team requires it
• Integration architecture - a technical session between your IT team and the vendor's
• Commercial terms - walk through the contract, SOW, and assumptions line by line before you go into formal negotiations

Don't book it just to replay the first meeting with more people in the room. Either it resolves specific open questions, or it shouldn't happen.

Confirm commitments in writing

Anything a vendor commits to in the room that isn't in the written proposal needs to be confirmed in writing before you proceed. Verbal commitments don't survive contract negotiations. If a TMS vendor says "yes, we can do that" on something important, follow up with an email the same day and ask them to confirm.

TMS contract and SOW (Statement of Work): what to check before signing

You've picked your vendor. Most teams "breathe out" at this point. I recommend you don't, because this is where the details everyone glossed over during evaluation quietly turn into your problem.

Align internally before you negotiate

Know your must-haves, your acceptable compromises, and your walk-away points before the conversation starts. Changing requirements mid-negotiation costs time, burns trust, and occasionally loses you the TMS vendor you actually wanted. Sort it out internally first, and then negotiate.

Understand what you're buying: SaaS, not a licence

Modern TMS platforms are SaaS subscriptions, not software licences. You're subscribing to a service the vendor hosts, maintains, and updates, not buying a system outright. That shifts what the contract has to cover: subscription terms, termination, data ownership and export rights, uptime commitments, support response times. Standard procurement templates weren't written for this model, so make sure yours has caught up.

The SOW matters as much as the contract

The Statement of Work spells out what gets delivered, by whom, and by when: account configuration, carrier onboarding, integration support, training, and the acceptance criteria that say the implementation is actually done. If it's not in the SOW, it's not included, no matter what was said in a meeting or an email. Read the assumptions section especially closely. That's where the scope is conditionally defined. If your carrier list turns out bigger than stated, or your ERP needs a non-standard integration format, the assumptions section decides whether that's a quick chat or a priced change request.

Be explicit about what's out of scope

Custom development, on-site training, data migration, integration work on your systems, carrier-side changes. These are usually priced separately. Getting it on paper before you sign removes the most common, and most avoidable, source of implementation friction: two sides who each assumed something different was included.

Agree the onboarding plan before you sign

Not after. Carrier prioritization, configuration timeline, integration milestones, go-live criteria, settle all of it while you still have leverage. A vendor who can't give you a clear onboarding plan at contract stage is telling you something you'll want to know before you commit.

After you sign: TMS implementation and onboarding

Most of the real risk lives after signature. Three things decide how it goes.

1. Data migration

Carrier contracts, pricelists, address books, historical shipments. Decide early what you need to migrate over, what gets cleaned first, and who owns the work. Messy source data is the most common reason the go-live date gets pushed further and further. Clean it before you migrate, not while you're migrating.

2. Carrier onboarding sequence

You don't connect every carrier on day one. Prioritize by volume and criticality, get the top few live and validated, then expand from there. This is exactly where the phased approach you asked about during evaluation earns its keep.

3. User adoption

The people booking shipments every day have to want to use the new system. Pull at least one of them in from the RFP stage onward, train them properly during hypercare (onboarding), and make sure the daily workflow is genuinely quicker than what they did before. A technically flawless rollout that the team just doesn't use is still a failed rollout.

10 common TMS RFP mistakes

The patterns we see most often, all in one place:

• No operational context. The big one. No volumes, no site structure, no carrier landscape provided to the vendors. A clarification round and generic pricing are guaranteed.
• Everything is a must-have. When every requirement is critical, the priority column is dead weight and you can't tell a dealbreaker from a nice-to-have.
• Vague timeline. No dates means vendors can't estimate their effort, so the proposals come back just as vague.
• Over-specifying the how. Prescribing the technical implementation instead of the operational outcome knocks out good solutions for the wrong reasons.
• Ignoring the ERP/TMS boundary. Assuming the TMS owns financial processes the ERP actually owns, then realizing it mid-implementation.
• Defaulting to price. Choosing on the subscription headline without a three-year model, or without weighing carrier connectivity and integration honesty.
• A demo instead of a walkthrough. Watching the vendor's polished sequence rather than making the system test out your real scenarios.
• References that don't match your operation. Looking at the impressive logos, but those companies might have logistics operations that look nothing like yours. Ask for references that look like you, then ask them how onboarding and integration actually went.
• Leaving onboarding until after signature. The plan you negotiate with leverage beats the one you negotiate without it.
• A process too heavy for the right vendor. Bureaucracy overhead that might filter out the modern platforms that would have served you best.

Free TMS RFP templates

We built five templates from the RFPs we answer, so you don't have to start from a blank page:

1. RFP document template. The full structure from this guide.
2. Functional requirements scoring sheet. Prioritized, with a coverage column per vendor.
3. Operational information checklist. The ten questions as a fill-in table.
4. Vendor evaluation matrix. Weighted scoring across vendors.
5. RFP timeline template. Activities, dates, owners.

Download the bundle - all five, free, no email required. Take what's useful, ignore the rest:

Download the full TMS RFP template bundle (.zip)

Cargoson is a transport management system used by mid-sized manufacturers and wholesalers across Europe and North America. We answer RFPs like the one you're about to write all the time, so if you'd rather talk your requirements through before you start writing, we're glad to help you think it through, no obligation.

Book a free 30-minute consultation here

Run the process well and it'll be worth every hour.