Buyer guide

An RFP built from better questions

Most ERP RFPs are a feature checklist, and every serious vendor answers yes to nearly all of it. The questions worth asking are the ones with a number, a name, or a document behind the answer — because those are the ones marketing cannot cover.

Building an RFP?

Send us your draft. We will tell you which questions will not distinguish anyone.

1 / 3
Questions with verifiable answersIncludes what most omitAnd when to skip the RFP

Buyer guide

Six sections an RFP should contain.

Roughly in order of how much the answers will actually differentiate the responses.

1. Your context, honestly

Size, entities, volumes, systems, and data condition — including what is wrong with it. Vendors who know your duplicate rate quote more accurately, and a quote built on optimism becomes a change order.

2. Scenarios, not features

Three to five real situations from your own transactions. "Describe how you would handle this" separates responses in a way a feature matrix cannot.

3. Commercial, in three-year form

Licence, implementation, integration, and expected year-three cost at projected headcount. Ask for the three-year total explicitly or you will receive year one.

4. Delivery team and track record

Named people, their availability, deployments completed last year for companies your size, and median variance to original quote.

5. Security, compliance, and exit

Certifications held and not held, subprocessors, incident notification, and what the export contains. Ask for a sample export.

6. Limitations, asked directly

Where would this product be a poor fit for a business like ours? A vendor who answers substantively is more accurate about everything else.

Twelve questions that actually distinguish

Each of these has a verifiable answer, and the refusal to answer is itself informative.

  1. What was your median variance to original implementation quote across projects completed last year?
  2. Name the specific people who would be assigned to us, and what else they are committed to during our timeline.
  3. Give us two references whose implementations overran or who subsequently left.
  4. What is the three-year total cost at our projected headcount, including year-two and year-three uplift?
  5. What does your AI do without a person clicking approve, and what is recorded when it acts?
  6. What is your published per-workflow accuracy, and what is the spread across your customer base?
  7. What happens to a release that regresses accuracy on your evaluation set?
  8. What is required to change a vendor’s bank details in your system?
  9. Can we run a full data export today, without a support ticket, and what does it contain?
  10. Which certifications do you hold, and which do you not hold?
  11. List your subprocessors and where each processes data.
  12. Describe a customer for whom this product was the wrong choice, and why.
Ask what happens to a release that scores worse on their own evaluation set. Most vendors cannot answer it, and the answer separates measured products from confident ones.

What to leave out

  • Long feature checklists. Every serious vendor answers yes. You will spend a week reading three near-identical spreadsheets.
  • Questions with an obvious right answer. “Do you support multi-currency?” distinguishes nobody.
  • Requirements you cannot trace to a transaction. If it came from a template rather than your data, it will not survive configuration anyway.
  • Anything you would not actually walk away over. Padding a must-have list makes the scoring meaningless.

When to skip the RFP entirely

For most mid-market buyers, a well-run scenario demo process tells you more than an RFP response will, and takes less of everyone’s time. An RFP is worth running where you are regulated, where procurement policy requires it, or where you genuinely need written commitments on record for a board or a lender.

Where you do skip it, keep three things from this page: the twelve questions, asked in the demo and answered in writing afterwards; the scenarios built from your own transactions; and the reference requests, including the difficult ones.

Scoring the responses

Agree your weighting before responses arrive and write it down. Our own published weighting — functional fit 30%, total cost 20%, time to value 15%, implementation risk 15%, extensibility 10%, support and ecosystem 10% — is a starting point that encodes our view that implementation risk is underweighted by most buyers.

Score independently before discussing as a group. Groups converge quickly on whoever spoke first, and independent scoring surfaces genuine disagreement that is worth having.

If you send us one

We answer RFPs, and we answer the awkward questions substantively — including which certifications we do not hold, which industries we are wrong for, and what our published accuracy spread looks like at the bottom quartile. If a question reveals that we are not a fit, we will say so in the response rather than hedging and hoping to address it in a demo.

Questions

Common follow-ups.

Do we need an RFP at all?
For most mid-market buyers, no. Scenario demos on your own data tell you more in less time. An RFP is worth it if you are regulated, bound by procurement policy, or need written commitments on record.
How long should it be?
Short enough that vendors answer substantively. A hundred-question feature matrix produces three near-identical spreadsheets and a wasted week.
What if a vendor will not answer a question?
Note it and weight it. Refusal to state historical quote variance or to provide difficult references is itself an answer.
Should we send the same RFP to everyone?
Yes, including the scenarios. Comparability is the entire point, and tailoring per vendor destroys it.
How do we score fairly?
Weight before responses arrive, score independently before discussing, then reconcile. Groups converge on whoever speaks first.

Twelve questions beat a hundred checkboxes.

Each has a verifiable answer, and the refusal to answer tells you as much as the answer would.