RFP Questions to Ask Vendors
Questions to put to vendors at the proposal stage, when you are asking for commitments rather than information: cost across three years, named staffing, service levels and remedies, change rates, liability, and exit terms.
The questions
Open any question for the note
For each requirement, are you meeting it with configuration, with custom development, or not at all?
Why ask it
Configuration and custom code have very different cost and upgrade profiles, and custom work is what breaks at the vendor's next release. Proposals routinely blend the two, so require the split line by line.
What is the total three-year cost, including licenses, implementation, training, and support?
Why ask it
Year one is the number vendors compete on and the number that misleads. Three years puts renewal increases, support tiers, and training that stops being free after month three onto a single page.
What is your annual price escalation, and is it capped?
Why ask it
An uncapped escalation clause is how a competitive bid becomes expensive in year three. Ask for a written cap, because most vendors have room to give one and very few offer it unprompted.
Which of your quoted line items are fixed price, and which are estimates?
Why ask it
Estimates in a proposal become change orders in a project. Make the vendor mark each line, and treat any large estimated item as a risk sitting on your side of the table rather than theirs.
Who exactly would work on this, by name and percentage of their time, and who is a subcontractor?
Why ask it
Names with time allocations force a real staffing answer instead of a capability statement. Subcontractors are not disqualifying, but they change who you can escalate to, and they often surface only after signature.
How experienced are the people who would actually do the work, as opposed to the people presenting today?
Why ask it
The team in the room is usually the strongest one available, and the team on the project frequently is not. Ask for years of relevant experience per named person, and put the names in the contract if the answer matters.
What do you need from us, and by when, for your timeline to hold?
Why ask it
Every vendor timeline rests on assumptions about your side: data, decisions, environments, people. Getting that list in writing is what keeps a delay from turning into an argument about whose fault it was.
Walk us through the first ninety days week by week.
Why ask it
Weekly granularity separates vendors who have done this before from vendors working off a template. Look for named deliverables and decision points rather than phases with marketing names attached.
What service levels are you committing to, and what is the remedy when you miss one?
Why ask it
A target with no remedy is a preference. Ask what the credit is and how it is triggered, because service credits that must be formally claimed are the ones nobody ever collects.
What counts as a severity one issue, and what response and resolution times apply to it?
Why ask it
Severity definitions decide whether your outage is treated as urgent, and vendors draft them narrowly. Read theirs and confirm that your worst realistic failure lands in the top tier rather than the second.
How would a change request work, and what is your rate card by role?
Why ask it
Change is certain, so the rate card matters nearly as much as the base price. Ask whether travel is billable and whether changes are quoted before work starts or invoiced after it finishes.
What is your acceptance testing process, and what happens if we reject a deliverable?
Why ask it
Without a defined acceptance step you have no leverage over quality. Ask how long you get to test, what counts as a defect, and whether payment is tied to acceptance rather than to delivery.
Where would our data live, who inside your company can access it, and which subprocessors are involved?
Why ask it
Any vendor selling to businesses should have a documented answer ready. If what comes back is marketing language about bank-level security, route it to their security team before you score the response.
What liability do you accept for a breach or data loss, and what does your insurance cover?
Why ask it
Most vendor contracts cap liability at fees paid, which will not come close to covering a serious incident. Ask for the certificate of insurance and the policy limits rather than a reassuring sentence.
What are your termination rights and ours, and what would we owe for leaving early?
Why ask it
Read both sides of the exit before you sign. Automatic renewal, narrow notice windows, and termination-for-convenience fees are what turn a disappointing relationship into an expensive one.
At the end of the contract, how do we get our data and configuration out, and at what cost?
Why ask it
Ask while you still have leverage. You want the format, the timeline, whether configuration comes out along with the data, and the fee, all written into the agreement rather than described as cooperation.
Which two clients most like us can we speak with, including one where the project ran into trouble?
Why ask it
Every vendor can supply a happy reference. Asking for a difficult one tests whether they have relationships candid enough to survive the request, and those calls produce the most useful detail you will get.
What is the biggest risk to this project, and who owns it in your plan?
Why ask it
Watch whether they name a real risk or a token one, and where the mitigation sits. A proposal that assigns every risk to the customer is telling you in advance how the project will be run.
What have you assumed in this proposal that, if wrong, would change the price or the date?
Why ask it
Unwritten assumptions are the ones you pay for later. Getting them listed converts optimism into a set of conditions you can check against reality before award rather than during month four.
What are you not proposing that we should have asked for?
Why ask it
This invites the vendor to point at the gap in your own specification, which is far better heard now than after signature. A vendor with nothing to add either does not know your domain or is unwilling to complicate their bid.
Evaluating Vendor Proposals
Practical guidance for the conversation itself
Comparing proposals fairly
- 1Build one scoring sheet with fixed weights before any response arrives. Weights invented after you have read the bids become a way of justifying the vendor you already liked.
- 2Normalize the pricing yourself into three-year totals using identical assumptions about volume and headcount. Vendors structure quotes to look inexpensive in different places.
- 3Score written responses before you watch any demonstration. A polished demo changes how people read a document they have not yet scored.
- 4Have the same two people score every bid, so the scoring is at least consistent rather than varying by reviewer.
- 5Write down the decision and the reasons at the time and keep the file. Eighteen months later, when something has gone wrong, it is the only record of what was promised.
Where proposals hide cost
The first-year discount
A steep opening discount that quietly expires at renewal is standard practice. Compare renewal pricing rather than initial pricing, and ask for the renewal increase to be capped in the contract.
Implementation quoted as an estimate
A fixed license fee beside an estimated implementation is an open-ended bid. Ask for a fixed price, or a not-to-exceed figure with the assumptions written down beside it.
Support tiers
The response times you assumed were standard often belong to a premium tier. Check which tier the proposal quotes, then read what the standard tier actually commits to.
Environments, users, and connectors
Sandbox environments, test accounts, and integration connectors are frequently priced separately. List everything you intend to use and ask for written confirmation that each item is included.
Verify before you award
- Two reference calls per finalist, at least one at your scale, and ideally one with a customer who left or nearly did.
- The named team's availability, confirmed by whoever manages them rather than by the salesperson.
- Certificates instead of claims: insurance limits, security attestations, and any accreditation with its scope and expiry date.
- The contract read by the person who would have to enforce it, with attention to liability caps, indemnities, and termination.
- A short paid pilot for anything you cannot verify from documents, scoped and priced before the award rather than after.
Answers that belong in the contract, not the meeting
- Named key personnel, with a clause requiring notice and your approval before they are swapped out.
- Service levels with defined severity tiers, response and resolution targets, and credits applied automatically rather than on request.
- A rate card for change requests, valid for the contract term, with any annual increase capped.
- Data export on termination: format, timeline, cost, and written confirmation of deletion afterward.
- Acceptance criteria for each deliverable, with payment milestones tied to acceptance rather than to delivery.