How to Write an ERP RFP That Produces Comparable Bids

Three proposals land in the same week. One is forty pages with a phased plan and a named team. One is nine pages with a single number at the bottom. One is a hundred and twenty pages, of which ninety are the vendor's methodology and client logos. The prices differ by a factor of three, and after two hours in a room nobody can say whether that reflects a difference in the work or a difference in what each bidder decided the work was.

This is the normal outcome, and it is not the bidders' fault. They responded to what you sent. If the document did not define the work, each of them defined it — differently, and in each case in the shape they are best placed to win with.

An RFP that produces comparable bids does one thing: it removes the bidder's freedom to choose the scope, and leaves them free only to choose the approach. Everything below is a way of doing that.

Why proposals come back incomparable

Four mechanisms do almost all of the damage, and all four are curable in the document.

The RFP asked for capabilities rather than work. "Full inventory management" is ticked by every product on earth and priced by none of them. The bidder cannot size it, so they size their assumption of it, and their assumption is the cheap version, because the cheap version wins.

No volumes were given. Effort in an ERP project is driven by transaction volume, master data volume and exception rate. Without those, three bidders invent three different companies and price those instead.

The entity structure was described by trading name. Groups describe themselves the way they go to market. Bidders price the way legal entities work. One bidder assumes one company, another reads between the lines and assumes four, and the difference is most of the price gap.

Each bidder used their own response format. Even where the scope matched, the packaging did not. One included a year of support, one excluded data migration beyond a record count buried on page thirty-one, one priced services and licence in a single figure. There is nothing dishonest in any of that, and it makes a comparison impossible.

The fix for all four is the same. Specify the work, supply the facts, and dictate the format of the answer.

Specify the facts, leave the method open

The most common failure in an RFP is specifying the wrong half. Buyers write pages of desired system behaviour and almost nothing about their own company, when the reverse produces better bids.

Specify precisely	Leave deliberately open
Legal entity list, including dormant ones, with jurisdiction (mainland, each free zone), functional currency and financial year end	Which modules or product editions are proposed
Transaction volumes per month for the six to ten processes that matter, with exception rates	How the requirement is met — configuration, standard function or code — provided the answer is stated
Master data counts: customers, suppliers, items, bills of material or cost codes, open documents, and your honest assessment of their quality	The phasing, provided each phase has a testable outcome
The processes themselves, written as observed sequences with the actor at each step	The technical architecture, provided the constraints are met
Every integration, with the far-end system, who owns it, and whether that owner has done this before	The project methodology, which is theirs and not your business
Non-negotiable compliance: VAT return that reconciles to the ledger, bilingual documents, e-invoicing seam, WPS payroll, end-of-service accrual	Team composition, provided the names and the availability are stated
History requirement: how many years of transactions must come across, and in what form	Training delivery format, provided coverage and volume are specified
Your own resource commitment: which of your people, for how many days per week	Tooling, environments and internal process

The right-hand column is not laziness. It is where a good bidder differentiates themselves, and an RFP that closes it down receives four identical answers and learns nothing.

There is one more thing worth specifying that buyers almost never do: your constraints as facts rather than preferences. If the group's audit runs in February and nobody in finance is available that month, say so. If the factory cannot stop for two days, say so. If the board has already decided the first phase must include the joinery division, say so. Constraints that surface after contract are change orders. Constraints in the RFP are just planning.

The ten processes, written as work

The heart of a good ERP RFP is not a requirements list. It is a set of process descriptions, each written the way the work actually happens, with numbers attached.

Six to ten is the right count. Fewer and you have not described the business; more and nobody reads them, including you. For each one, write the sequence of steps in your own vocabulary, name the actor at each step, state the monthly volume, and state what proportion goes sideways and how.

That last part is the one that separates a useful RFP from a decorative one. Two hundred supplier invoices a month is a fact about size. Two hundred supplier invoices a month of which a meaningful share are part deliveries against open orders, a handful relate to a prior period, and some settle in a currency other than the invoice currency is a fact about difficulty, and difficulty is what you are asking people to price.

Write each process so that a stranger could follow it and so that a bidder can be held to it later. The test: could this description be turned into an acceptance test after contract without a further conversation? If not, it will become a negotiation in month six instead.

For a contractor, that set will include measurement through to interim payment certificate, retention held and released, and advance recovery — the specifics of what a UAE contractor's system has to do before it is worth buying. For a manufacturer it will include a work order that consumes more than the bill of material specified, a subcontracted operation, and a costing that reconciles to the ledger rather than sitting beside it, as set out in how manufacturing cost is actually built. Write yours from observation, not from either list.

The response template, which is where comparability actually comes from

You can specify the work perfectly and still receive incomparable documents. The remedy is blunt and works: mandate the format of the answer and state that non-conforming responses will be scored on what conforms.

Require, as separate files:

A requirement response table with one row per requirement and per process step, and a fixed set of allowed answers: standard, configuration, customisation, third-party component, or not met. No prose in that column. The classification is the deliverable, because it is the single best predictor of what your years two to five look like, and bidders answer it differently when it has to be written down rather than said in a room.

A commercial schedule on your template, not theirs, with licence and services separated, day rates listed by role, and five years priced — not one. Include rows for the annual uplift mechanism, the cost of twenty additional users, the cost of one additional legal entity, and the change-request day rate with its validity period. Ask for the same table from every bidder and the price comparison becomes arithmetic rather than interpretation. The reasoning behind that five-year schedule is set out in the total cost of ownership model.

An exclusions list, explicitly requested, in a numbered format. This is the most valuable page in any proposal and the one bidders write last. Asking for it directly changes what arrives.

An assumptions register, one line per assumption, each tied to the estimate it supports. If a services line rests on "up to five thousand item records" or "a maximum of three approval levels", you want that visible next to the number, because it is the boundary at which the price stops being the price.

A team schedule with named individuals, CVs, the percentage of their time committed, and their other current commitments during your project window.

Keep everything else short. State a page limit for the narrative sections and enforce it. A hundred-page methodology chapter is not evidence of capability; it is evidence of a proposals team.

Scoring, published in advance

Publish the weights in the RFP. Two things follow. Bidders put effort where the marks are, which is the effort you wanted. And your own committee cannot re-weight after the fact to justify a preference formed in a demo.

A workable shape for a mid-market ERP selection, adjusted to your own priorities:

Criterion	Indicative weight	What earns the marks
Fit against the process descriptions	30	Standard or configuration answers demonstrated on your data, not asserted in the table
Delivery team and their availability	20	Named individuals, CVs, committed time, a key-personnel clause accepted
Five-year commercials	20	The completed schedule, with a capped uplift and a priced marginal entity
Data migration and integration approach	10	A profiling step before the price is fixed, and named far-end owners
Compliance and local requirements	10	Demonstrated, not claimed
References and comparable work	10	Three named projects with quoted against final figures

Score the technical response before the commercial envelope is opened. This is standard practice in public procurement for a reason: a price seen first anchors every subsequent judgement, and committees are not immune to it.

Score individually and in writing before anyone in the room speaks. A discussion that begins with the loudest opinion produces a consensus that reflects seniority rather than evidence.

Attach the demo script

The RFP should contain the demo script and the data extract, not promise them later. Scripting the demonstration inside the procurement document does two things: it stops the demo becoming a sales meeting with homework, and it gives you a scored artefact that maps directly onto the process descriptions you wrote.

Keep it to your own transactions on a small extract of your own data, with the exception cases first while everyone is fresh, and score the same sheet for every bidder. The mechanics — what to put in the extract, what to insist on seeing, and what a demo genuinely cannot tell you — are covered in how to control the script rather than watch the rehearsal.

The commercial questions that belong in the document

Everything you leave to negotiation is negotiated at the point of least leverage: after you have chosen, after the board has been told, and after the losing bidders have been released. Put these in the RFP and require a position on each in the response.

Term	What to require	The answer that should worry you
Renewal uplift	A stated cap for the full initial term, with the mechanism named	"In line with our then-current list price"
Marginal cost of growth	Priced now: twenty more users, one more entity, one more warehouse or site	"We would scope that at the time"
Key personnel	Named team, your consent required before replacement	A resourcing model and a logo slide
Acceptance	Criteria written as tests against your process descriptions, with payment tied to them	Milestones tied to dates rather than outcomes
Ownership of what is built	You own or hold the source of custom modules, reports, integrations and configuration documentation	Silence, or ownership retained "for reuse across our client base"
Change control	A fixed day rate with a validity period, and a written change process	An hourly rate with no ceiling and no process
Data exit	Full export in a documented format on demand, including attachments and audit trail, within stated days at a stated cost	"Standard export functionality is available"
Support scope	The exclusions, itemised	A percentage of licence and nothing else
Subcontracting	Disclosed, with your consent required	No mention of it
Liability and delay	A stated position, however unwelcome	A clause you have to find in an appendix

Two of those deserve emphasis. The exit clause is the one term that costs nothing to agree at RFP stage and is impossible to obtain later, because the moment you need it is the one moment the vendor has no reason to help. And the ownership clause is the difference between a supplier and a dependency, which becomes the same thing as the difference between a competitive renewal and a renewal you have to accept.

Running it without wasting everyone's time

Three or four bidders is right. Six is a signal that the shortlisting was not done, and it produces a workload that guarantees a shallow evaluation of all of them.

Run clarifications through one written channel with a deadline, and publish every question and answer to every bidder without attribution. This is unfashionable in private-sector procurement and it is the single cheapest fairness mechanism available. It also improves your own document, because the questions reveal what you failed to specify — and the clarification you issue becomes part of the contract.

Give bidders a sensible window. A serious response with a completed requirement table, a five-year schedule and named CVs takes a fortnight of real work. A one-week deadline selects for the bidder with the largest proposals team, not the best one.

Then read the exclusions list, the assumptions register and the requirement classification table first, before the narrative and before the price. Those three documents contain the proposal. The rest is presentation.

What an RFP cannot do

It is worth being clear about the limits, because a well-run procurement produces a confidence that outruns its evidence.

An RFP cannot make requirements true that came from a feature list rather than from watching the work. If the process descriptions were assembled in a meeting room from what people believe happens, the bids will be precise answers to the wrong question, and no scoring model repairs that. The observation stage comes first, and the vendor-neutral method for getting there is the piece to read before you open a document template.

It also cannot substitute for a paid discovery. The most honest sequence in this market is a competitive RFP that selects a partner, followed by a small fixed-price diagnosis that produces the gap list and the data assessment, followed by a build priced against a document that now exists. A bidder who refuses to sell you the first phase separately has told you something about how they intend to make their margin.

And it cannot make a decision for an organisation that cannot make one. The project will move at the speed of your slowest decision-maker, whatever the contract says. If small questions currently take six weeks to settle, no clause in a procurement document changes that, and the bid you accept will be priced against an assumption about your responsiveness that nobody has tested.

If you want the process descriptions and the response template built against your actual work before the document goes out, that is the stage where an independent read is worth most, and it is where our ERP implementation work begins.