What are the stages of a TMS selection process?

A structured TMS selection typically runs: define requirements, build a longlist of candidate vendors, issue an RFP against your requirements, narrow to a shortlist, run scripted demos using your own scenarios, score against a weighted scorecard, check references and vendor viability, optionally run a proof of concept, then negotiate and decide. The discipline is that each stage narrows the field on evidence tied to your requirements, rather than on the strength of a sales pitch.

An RFP (request for proposal) is a structured document you send to candidate TMS vendors setting out your requirements and asking each to describe how they meet them, along with pricing, implementation approach and company information. Its purpose is to gather comparable, evidence-based responses so you can evaluate vendors against your needs on a common basis, rather than on marketing. A good RFP is anchored on prioritized requirements, not a generic feature checklist.

How do you avoid choosing the wrong TMS?

Anchor the whole process on your own prioritized requirements, and evaluate vendors against those — not against whoever demos best. Use scripted demos built on your real scenarios so you see the system do your work, not a polished canned flow; score with a weighted scorecard completed by the whole evaluation team; check references with real customers; and weigh implementation cost, total cost of ownership and vendor viability, not just features. The most common mistake is buying the best demo instead of the best fit.

How to Run a TMS Selection Process

A TMS selection process is the structured path from "we need a system" to "we chose the right one" — requirements, RFP, scripted demos, scorecard, references, negotiation. Its entire purpose is to make the decision on evidence tied to your needs, rather than on which vendor gives the best sales pitch. Run it well and you buy the right system for the right reasons, with your eyes open. Run it as a beauty parade — a few slick demos and a gut call — and you buy the best-presented product, which is a very different thing from the best-fitting one.

Why a structured process

Buying a TMS is a long, expensive, hard-to-reverse commitment. Vendors are good at selling; their demos are rehearsed to look effortless. Without a structure that forces the comparison onto your requirements, the decision drifts toward whoever performed best in the room — and the gaps only surface in implementation or, worse, after go-live. The process exists to keep the decision honest.

The purpose of a selection process isn't procurement box-ticking. It's to make sure you're comparing systems on how well they do your job — not on how well their salesperson does theirs.

The stages

A sound selection narrows the field, stage by stage, always on evidence:

Requirements. Define and prioritize what you actually need — the foundation everything else rests on.
Longlist. Identify the candidate vendors worth approaching.
RFP. Issue a structured request against your requirements; gather comparable responses.
Shortlist. Narrow to two or three real contenders on the RFP evidence.
Scripted demos. Have each shortlisted vendor run your scenarios.
Score. Evaluate against a weighted scorecard, as a team.
References & due diligence. Talk to real customers; check viability and roadmap.
(Proof of concept) — for higher-risk or complex needs, a hands-on trial.
Negotiate & decide. Terms, price, implementation — then choose, on the evidence.

Requirements come first

Everything hinges on this: a selection anchored on a clear, prioritized requirements set evaluates vendors against your needs. A selection without one evaluates them against their features — and every vendor's features look great in their own demo. Prioritize must-have versus nice-to-have now, because that weighting is what makes the later scoring mean anything.

The RFP

The RFP turns your requirements into structured questions and asks each vendor how they meet them, plus pricing, implementation approach and company background. Done well it produces comparable answers you can line up side by side. The trap is the generic feature checklist that every vendor ticks "yes" to — ask instead how they meet the requirement, and weight the answers by your priorities.

Scripted demos, not canned ones

The single highest-value stage. Don't watch the vendor's polished standard demo — give each shortlisted vendor your scenarios (your month-end, your payment run, your awkward intercompany case) and watch them do it live. That's where the difference between "we support that" and "here's it working on your problem" appears. This is exactly what the demo questions and scorecard are for.

References and due diligence

Talk to real customers — ideally ones like you, and ideally not only the references the vendor hand-picks. Ask what went wrong in their implementation, what support is really like, what they'd do differently. And check the vendor itself: financial viability, product roadmap, how upgrades and support actually work. You're buying a multi-year relationship, not a one-off product.

Scoring and deciding

Score against a weighted scorecard completed by the whole evaluation team — treasury, IT, and the people who'll use it — so the decision reflects prioritized evidence, not the loudest voice or the last good demo. And weigh the things that aren't features: implementation risk and cost, total cost of ownership, and deployment model. The best-fitting system on paper is a poor choice if it's ruinous to implement or run.

What usually goes wrong

Buying the demo. Choosing the best presentation instead of the best fit — the classic and most expensive error.
No requirements baseline. Evaluating on vendor features because you never defined your own priorities.
Feature-checklist tyranny. A yes/no matrix everyone passes, revealing nothing about how well each fits.
Ignoring implementation and TCO. Picking on licence price and features, then being blindsided by the cost and risk of actually deploying and running it.
Decision by loudest voice. No weighted, team-based scoring, so the choice reflects politics rather than evidence.

Anchor on prioritized requirements, gather comparable RFP evidence, make vendors run your scenarios, score as a team, check real references, and weigh cost and risk alongside features — and TMS selection becomes a decision you can defend and won't regret. The goal isn't the best system; it's the best system for you, chosen for reasons you can name.

Part of the Treasury Management Systems guide. See also the requirements checklist and vendor demo questions and scorecard. The newsletter sends one finance-systems pattern every two weeks.