# How to Run a TMS Selection Process

Source: https://gravam.com/blog/how-to-run-a-tms-selection-process
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-08-02
Reviewed: 2026-09-01
Summary: 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.

**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 — though [which category of TMS you're choosing between](https://gravam.com/blog/best-treasury-management-system) is the step before this one. 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](https://gravam.com/blog/treasury-management-system-implementation-guide) 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:

1. **Requirements.** Define and prioritize what you actually need — the foundation everything else rests on.
2. **Longlist.** Identify the candidate vendors worth approaching — and don't wait for [a Magic Quadrant to hand you the list](https://gravam.com/blog/gartner-magic-quadrant-treasury-management-systems), because there isn't one for TMS.
3. **[RFP](https://gravam.com/blog/how-to-write-a-tms-rfp).** Issue a structured request against your requirements; gather comparable responses.
4. **Shortlist.** Narrow to two or three real contenders on the RFP evidence.
5. **Scripted demos.** Have each shortlisted vendor run _your_ scenarios.
6. **Score.** Evaluate against a weighted scorecard, as a team.
7. **References & due diligence.** Talk to real customers; check viability and roadmap.
8. **(Proof of concept)** — for higher-risk or complex needs, a hands-on trial.
9. **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](https://gravam.com/blog/treasury-management-system-requirements-checklist) 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. If you'd rather start from a structure than a blank page, there's a [ready-made TMS RFP template](https://gravam.com/tools/tms-rfp-template) you can adapt.

## 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](https://gravam.com/blog/tms-vendor-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](https://gravam.com/blog/treasury-management-system-total-cost-of-ownership), and [deployment model](https://gravam.com/blog/saas-vs-on-premise-treasury-management-system). 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. With an AI product there is a second cost on your side of the line — the queue of everything it gets wrong — and [pricing that residue](https://gravam.com/blog/evaluating-enterprise-ai-vendor-claims) is part of the evaluation.
- **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. To score the shortlist as a team on weighted criteria, use the free [TMS Vendor Scorecard](https://gravam.com/tools/tms-vendor-scorecard).

***

_See also the [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist) and [vendor demo questions and scorecard](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard)._

## Primary sources

- AFP — Standardized Treasury Management System Request for Proposal — accessed 2026-07-29 — https://www.financialprofessionals.org/home/standardized-treasury-management-system-request-for-proposal
- AFP — How to Evaluate a Treasury Management System Provider — accessed 2026-07-29 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/how-to-evaluate-a-treasury-management-system-provider
- AFP — How to Conduct a Successful RFP for a Financial Service Provider — accessed 2026-07-29 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/how-to-conduct-a-successful-rfp-for-a-financial-service-provider
- Treasury Today — Choosing a treasury management system — accessed 2026-07-29 — https://treasurytoday.com/banking/choosing-a-treasury-management-system/
- The Global Treasurer — Picking Treasury Vendors That Pay Off — accessed 2026-07-29 — https://www.theglobaltreasurer.com/2025/06/04/treasury-implementation-vendor-selection/

## Questions this article answers

**Q: 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.

**Q: Where does the RFP fit in a TMS selection process?**

In the sequence set out here, the RFP sits between the longlist and the shortlist. You send candidate vendors a structured document setting out your prioritized requirements and asking each to describe how they meet them, along with pricing, implementation approach and company information. Because the responses come back against the same requirements, they are comparable and evidence-based rather than marketing — and that is what lets you narrow the longlist to the shortlist that goes on to scripted demos and weighted scoring. Practice varies on the exact placement: many teams send a lighter RFI to the longlist first and reserve the full RFP for the shortlist that survives it.

**Q: 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.