Choosing a vendor

Any ERP

How-toIntermediate12 min read

In short. Write down the need and the must-haves before you talk to anyone, then make every vendor prove the same scenarios with your own data. Score finalists against weights you agreed in advance, check references without the vendor present and record why you chose so the decision survives the people who made it.

Written for Leaders, finance and operations, administrators.

Choosing a vendor well means deciding what you need before anyone sells to you, then making every candidate prove the same things on the same terms. The process below works for a freight carrier, a tax engine, an ERP add-on or a payroll provider. Only the depth changes. Most bad vendor choices we see trace back to a polished demo, a skipped reference call or a contract signed before anyone asked how to leave.

The selection process at a glance

Scale each step to the size of the decision. A $3,000 a year shipping-label tool does not need a proof of concept, but a new warehouse management system does. The table shows what each step produces for a small and a large purchase (the dollar thresholds are invented).

Step	Output	Small (under $10,000 a year)	Large (over $100,000 a year or hard to replace)
1. Define the need	Problem statement, must-haves, nice-to-haves, budget range	One page, one afternoon	Workshops with each affected team
2. Long list	6 to 12 candidates	Web search and two peer calls	Peers, trade associations, analysts, your ERP publisher's partner list
3. RFI or RFP	Comparable written answers	Short email questionnaire	Formal RFP with a response template and deadline
4. Scripted demos	Scores per scenario	One demo, your script	Two or three finalists, your script and your data
5. Reference calls	Notes from three or more customers	Two calls	Three to five calls, one site visit
6. Proof of concept	Evidence the hard parts work	Free trial	Paid, time-boxed pilot with exit criteria
7. Weighted scoring	A ranked shortlist with reasons	Simple score sheet	Independent scoring by each evaluator, then a calibration meeting
8. Negotiation	Signed order form and contract	Standard terms, a few edits	Redlines on the master agreement, data terms and exit terms
9. Decision record	One page that says why	A paragraph in the vendor register	A memo filed with the contract

Step 1: define the need and the must-haves

Start with the problem, not the product category. "We need a transportation management system" is a solution. "We spend 11 hours a week rating LTL shipments by hand and overpay on about one shipment in five" is a need (invented figures), and it tells you what to measure at the end.

Sort every requirement into one of three buckets, and keep the first bucket short.

Bucket	Meaning	How it is used	Example for a shipping tool (invented)
Must-have	Without it the vendor is out, whatever else it does	Pass or fail before any scoring	Rates our three main LTL carriers, posts freight cost back to the ERP order
Important	Strongly affects value	Scored and weighted	Address validation, batch label printing
Nice-to-have	Would be pleasant	Tie-breaker only	Branded tracking emails

Also write down, before any vendor call:

The budget range and cost shape: one-time cost, annual fees and who inside pays. See Build, buy or partner for comparing total cost.
Who owns the decision: one accountable person, plus the people who score.
The data involved: what the vendor will hold or touch, and whether any of it is regulated (customer card data, health data, personal data of EU or California residents).
The integration points: which systems it must exchange data with, and in which direction.
Your exit expectation: how you would get your data back and how long a switch would take. Asking now costs nothing, while asking after signature costs bargaining power.

The 2023 interagency guidance on third-party risk issued by the Federal Reserve, FDIC and OCC frames this as the planning stage of a relationship life cycle, before due diligence and contracting. It is written for banks, but the sequence suits any company that depends on outside providers.

Step 2: build a long list

Aim for 6 to 12 candidates, then cut to 3 to 5 for the RFP. With fewer than three you have no comparison, and with more than five nobody reads the answers carefully. The table lists where candidates come from.

Source	Good for	Watch for
Peers at similar companies	Honest experience, including failures	Their needs may differ from yours in scale or process
Trade and buying group contacts	Industry-specific tools	Programs where the group earns a fee from the vendor
Your ERP publisher's partner or add-on directory	Products that already integrate	A listing is not an endorsement of quality or support
Analyst and review sites	Breadth of the market	Paid placement, paywalled research you cannot verify
Consultants and implementers	Knowing which products hold up	Referral fees or resale margins (ask directly)

Cut the list with the must-haves. A five-minute call or a pricing page rules out about half.

Step 3: send an RFI or RFP

An RFI (request for information) is a short questionnaire to learn who can do what. An RFP (request for proposal) asks for a priced, specific offer against your requirements. For most mid-market purchases, one combined document is enough.

A good RFP makes answers comparable. The table lists what to include.

Include	Detail
A response template	A spreadsheet with one row per requirement, fixed answer choices (Standard, Configuration, Add-on, Custom development, Not available) and a comment column
Pricing in your format	One-time fees, annual fees by year for five years, price increase terms and every item priced separately
Standard security questions	The Shared Assessments SIG or Cloud Security Alliance CAIQ, plus a current SOC 2 report under an NDA
Exit questions	Export format, export cost, how long data is kept after termination and transition help
A deadline and one contact	Answers to bidder questions shared with all bidders

Vendors who will not price in your format are telling you something. Many vendors already maintain answers to the SIG or the CAIQ, both industry questionnaires, so accept those instead of inventing your own 300 questions.

Step 4: run scripted demos with your own data

A vendor's standard demo shows the product at its best on data built to flatter it. A scripted demo shows your work on your data.

Write 8 to 15 scenarios from real life. Pick the hard, frequent ones. For a tax engine, that might be a customer with a partial exemption shipping to two states. For a carrier platform, a multi-stop LTL shipment with a liftgate.
Send the script and a sample data set two weeks ahead. Strip or mask anything sensitive. Every finalist gets the same script and the same data.
Have your own staff drive at least one scenario. Ten minutes of your customer service rep using the screens tells you more than an hour of watching an expert.
Ask "how was that done?" for every step. Standard, configured, add-on, custom or a workaround. Only standard and configured come with the price you were quoted.
Score each scenario before discussing it. Each evaluator writes a 1 to 5 score in the room. If discussion comes first, the loudest voice sets everyone's score.

Step 5: call references without the vendor present

Ask for three references similar to you in size and industry, live for at least a year. Ask the vendor to include one customer who had problems, and note how they respond to that request. Then call without the vendor on the line. The table pairs each question with what the answer tells you.

Question to ask a reference	What the answer tells you
What did you buy it to fix, and did it fix it?	Whether the value was real
How long from signature to real use, compared with the plan?	Implementation realism
What surprised you on the first invoice after year one?	Hidden fees and increase habits
When something broke, how long until a person who could fix it was working on it?	Support as delivered
What would you do differently in the selection or the contract?	The lessons you can skip learning
Has the vendor changed ownership, pricing model or support team since you signed?	Stability
Have you tried to export your data? How did it go?	Exit risk
Would you choose them again today? What would make you leave?	The overall verdict

Listen for hedges. "They are getting better" and "once you learn the workarounds" count as answers.

Step 6: prove the hard parts with a proof of concept

A proof of concept (POC) or paid pilot tests the one or two things a demo cannot: your data volumes, your integration, your edge cases. Use one when the purchase is large or hard to reverse, or when the demo left a doubt. The table lists the practices that keep a POC useful.

Good POC practice	Why
Time-box it: two to six weeks	Open-ended pilots drift into unpaid implementations
Write pass or fail criteria before it starts	"Rates 500 test shipments within 2% of our carrier invoices" can be judged, but "works well" cannot
Use real data, masked where needed	Clean sample data hides the problems you are testing for
Agree who pays and what happens to the work	A paid POC that rolls into the project is a reasonable deal for both sides
Keep it out of production	A pilot that drifts into production skips the contract protections

Step 7: score the finalists with agreed weights

Weighted scoring turns a pile of impressions into a comparison you can explain. Set the criteria and weights before the demos, so the most recent presentation cannot reshape them. Must-haves are pass or fail and come first, and only vendors that pass all of them get scored. U.S. federal buyers use the same idea. FAR Part 15 describes a tradeoff process in which stated evaluation factors, weighed against price, decide the award rather than lowest price alone.

Each evaluator scores each criterion from 1 (poor) to 5 (excellent). Multiply each score by its weight, add the results and divide by 100. With weights that total 100, the result is a weighted average on the same 1 to 5 scale. A higher total wins, but treat totals within about 0.2 of each other as a tie and let the references and the contract decide. That band is a rule of thumb, because scores from a few evaluators are not that precise.

The table lists default criteria and weights.

Criterion	Default weight	What a 5 looks like
Fit to requirements	30	Runs every scripted scenario with standard features or configuration
Total cost	20	Lowest five-year cost, with capped increases
Vendor stability	15	Profitable or well funded, stable ownership, low staff turnover in your account team
Security and compliance	15	Current SOC 2 Type 2 report with no significant exceptions, clear breach terms, meets your regulatory needs
Support and service	10	References confirm fast, competent help, with named contacts
Exit and data portability	10	Full export in a documented format at no extra cost, transition help in the contract

Change the weights to suit the purchase. A payment processor might put security at 30, and a label printer might put cost at 40. Score up to three vendors below.

Tool

Vendor scorecard

Set a weight for each criterion, then score each vendor from 1 (poor) to 5 (excellent). Rename the criteria and vendors to your own. Weights are scaled to 100 if they do not already add up to it. Nothing leaves your browser.

Criterion	Weight






Weighted score (out of 5)

A scorecard ranks the options you already believe are viable. Treat any must-have a vendor fails as a knockout before you score, and check the result against your gut: if the winner surprises the team, find out which weight or score caused it.

Worked example: three finalists

In this invented example, a mid-sized electrical distributor is choosing a warehouse scanning add-on and has three finalists after demos and reference calls. The scores are the consensus after each evaluator scored alone.

Criterion	Weight	Vendor A	Vendor B	Vendor C
Fit to requirements	30	4	3	5
Total cost	20	3	5	2
Vendor stability	15	4	3	4
Security and compliance	15	4	2	4
Support and service	10	3	4	3
Exit and data portability	10	3	2	4
Weighted score (out of 5)	100	3.60	3.25	3.80

Vendor C wins on fit despite costing the most. A 5 on the heaviest criterion is worth 150 weighted points (5 × 30), against 90 for Vendor B. C also scores best on exit terms.

Vendor B is the cheapest but the weakest on security and exit. Its 5 on cost cannot make up for a 2 on security and a 2 on data portability, so price alone would have picked the riskiest option.

Vendor A is a credible second. At 3.60 it sits 0.20 behind C, at the edge of the tie band, so it stays in the negotiation as an alternative.

Check how sensitive the result is. If the team had moved 10 points from fit to cost (fit 20, cost 30), A and C would tie at 3.50 and B would reach 3.45. When a reasonable change in weights flips the answer, the decision rests on the argument about weights, so have that argument openly.

Step 8: negotiate before you are committed

Your bargaining power is highest before you tell a vendor they have won. Keep at least two finalists in play until the contract terms and the price are both agreed. The table lists the usual asks.

Term	Typical ask
Price increase cap	Annual increases capped at a fixed percentage or an index, for the whole term and renewals
Term and renewal	Shorter first term, or a longer term only for a real discount, with renewal notice windows you can meet
Implementation	Fixed fee or not-to-exceed amount for defined scope
Service levels	Measured uptime and support response targets with credits, and a right to exit for repeated misses
Data rights and exit	Your data, exportable in a stated format, returned within a stated time, then deleted with written confirmation
Ramp	Paying for users or volume as you go live, not from day one

The clauses worth reading are covered in Contracts, SLAs and data rights.

Step 9: write the decision record

A decision record is a one-page memo that explains the choice to someone who was not in the room, including your own team two years from now at renewal. File it with the contract. The table lists its sections.

Section	Contents
Need	The problem statement and must-haves from Step 1
Options considered	Every finalist, and why the others were cut
Scores	The weighted table and the sensitivity check
Decision and reasons	Who decided, when and the two or three reasons that mattered
Risks accepted	What worried you about the winner and how you plan to manage it
Success measures	How you will know in 6 to 12 months that it worked
Exit plan summary	Notice period, data export route, likely replacement

Red flags during selection

These signs during selection predict trouble after signature.

Red flag	Why it matters
The vendor will not run your script, only their standard demo	They may not be able to do your scenarios
Pricing only as a bundle, or "call us" for every component	You cannot compare or control future costs
No references in your industry or size, or only new customers	Nobody like you has lived with it for long
A deep discount that expires in days	Pressure replaces evaluation, and the discount tends to vanish at renewal
No SOC report, or refusal to answer standard security questionnaires	You will carry risk you cannot see
Data export described as "available through professional services"	Leaving will cost money and time
The salesperson answers every technical question	You have not met the people you will work with
Contract terms introduced only after you announce the choice	Bargaining power has already moved to the vendor

Questions to ask every finalist

Which of our scenarios need configuration, add-ons or custom work, and who does that work?
What will we pay in each of the next five years, and what can change that number?
Who, by name, supports us after go-live, and what are your actual response times this quarter?
What is your most recent SOC 2 report period, and what exceptions did it note?
Which subcontractors or cloud providers handle our data?
If we leave, what do we get back, in what format, how fast and at what cost?
What changed in your ownership, pricing or product direction in the last two years?

Next steps

Write the one-page need statement first: the problem, the must-haves, the budget range and the data involved. Share it with the people who will score, and agree the weights before any vendor calls. The RFP, the demo script, the scorecard and the decision record are all built from that page.

When you get to the due diligence stage, the vendor due diligence checklist covers what to verify, and for ERP selection specifically see Choosing an ERP for distribution.