What to put in an enterprise platform implementation services RFP

An enterprise platform implementation services RFP needs six things stated precisely: the business processes in scope, the systems to integrate, the data to migrate, the cutover and rollback approach, the acceptance criteria that define done, and the support cover after go-live. Everything else is useful context. Bids only become comparable once those six are fixed.

What follows is the section order we would use if we were writing the document rather than answering it, with the sentence each section has to contain and the consequence of leaving it vague. The aim is not a longer RFP. A tight fifteen-page document with those six sections answered beats an eighty-page template every time.

Why most implementation RFPs produce quotes that do not hold

A quote is a bet on an assumption set. When an RFP describes what the business wants but not what the vendor must connect to, migrate and prove, the vendor fills the gaps with optimistic assumptions and prices those. The bid looks competitive. The variation orders arrive in month three, and by then the comparison you ran at tender is meaningless because you are no longer buying what you compared.

Comparable bids need a shared denominator. That denominator is not a feature list, because packaged platforms have broadly similar features. It is the fit work: configuration, integration, migration, cutover and adoption. Write the RFP around that fit work and the price differences between bidders start telling you something real.

We answer these documents regularly for enterprise platform implementation programmes, and the strongest ones share a shape. Microsoft makes a similar argument in its own Dynamics 365 implementation guidance, which puts solution blueprint and integration design ahead of configuration detail.

Section by section: what to state and why

The scope section: processes, not features

Describe order to cash, procure to pay, hire to retire or whatever your equivalents are, end to end, with the person accountable for each and the volume that runs through it in a normal month and a peak month. Mark each process as in scope for phase one, later, or out. A bidder who can see volumes can size infrastructure and support honestly; a bidder who cannot will either pad or guess.

Rank rather than weight. A list of two hundred requirements where everything is marked high priority tells the vendor nothing. Fifteen ranked processes with named owners tells them where the configuration effort sits.

The acceptance section: how does a phase become payable?

State the test, the data set and the threshold. Good acceptance criteria read like measurements: month-end close completes within the existing window, the migrated open-order value reconciles to the legacy ledger to the rupee, ninety per cent of purchase orders are raised in the platform by week eight of the phase. Bad ones read like opinions: the system is stable, users are trained, performance is acceptable.

Tie payment milestones to those measurements rather than to dates. A milestone that pays on a date rewards a vendor for arriving; a milestone that pays on a reconciliation rewards a vendor for being right. We work this way on fixed-price, fixed-date programmes, and it is the clause that makes fixed price survivable for both sides.

The data section deserves its own budget line

Ask bidders to price cleansing and reconciliation separately from loading. Give them the record counts, the known duplicates, the fields your teams have repurposed over the years, and the single number finance will use to decide whether the migration worked. If you do not know that number yet, say so and ask them to propose it. Data migration for platform implementations explains why cleansing precedes movement.

The support section: cover, not goodwill

Specify hours of cover, response time, resolution target, monthly change hours and what happens on a Sunday during month-end. Then compare bids on that basis rather than on the word support. Our published Care Plans give you a reference scale: Essential at $1,000 or ₹68,000 per month with business-hours IST cover and an eight-hour response, Standard at $2,500 or ₹1,60,000 with 24x5 cover, a four-hour response and 25 hours of change work, and Enterprise at $5,250 or ₹3,40,000 with 24x7 cover, a one-hour response, 60 hours and a named engineer. The distinction between response and resolution is covered in SLAs that mean something.

What to put in the commercial section

• The pricing model you want. Fixed price per phase, time and materials, or a pod. Say which, and let bidders argue if they disagree.
• Payment milestones tied to acceptance. Name the measurement that releases each payment.
• A change-request rate card. A day rate agreed at tender is cheaper than a day rate agreed in month four.
• The support contract alongside the build. Price them together; a cheap build with expensive support is not a cheap programme.
• Ownership terms. Code, configuration, prompts, documentation and data, with an exit clause. Ours are standard: you own all of it.
• Named team and continuity. Who works on this, what proportion of their time, and what happens if they leave.
• A realistic budget band. Withholding it wastes a month. Our implementation programmes run $28,000 to $140,000, or ₹18,40,000 to ₹1 crore, and saying so early filters the field honestly.

If you want to sanity-check a band before you issue the document, the estimate tool and the pricing page give published starting figures for each programme type.

How to score the responses you get back

Score the fit work, not the presentation. Give the heaviest weight to the sections where bidders can differ most: the integration approach, the migration and reconciliation plan, the cutover and rollback design, and the named team. Platform feature coverage should carry almost no weight, because every serious bidder will meet it and the vendor did not write the product.

Read the assumptions register before the price. A bid with twenty explicit assumptions is more honest than one with none, and the assumptions tell you what the vendor expects you to do. Where two bids differ sharply on price, the gap is almost always hiding in migration effort, integration adapters or the length of hypercare, so normalise those three before comparing totals.

Ask every shortlisted bidder to walk through one failed project. A vendor who cannot describe a programme that went wrong, what the signal was and what they changed afterwards, has either not shipped enough of these or is not going to tell you the truth in month four either.

A worked example of a well-scoped tender

A university issued a document that did almost all of this. It listed four processes in scope for phase one, gave record counts per domain, named the registrar and the finance controller as process owners, stated that the academic calendar ruled out any cutover between May and July, and asked bidders to price cleansing separately from loading. It also said plainly that a full replacement in one summer was not acceptable.

That last sentence changed every bid it received. Instead of six replacement proposals, it got incremental proposals it could compare on migration method and phase sequencing. The programme that followed is described in the university ERP modernisation case study, and the constraint written into the RFP is the reason it was deliverable at all.

When an RFP is the wrong instrument

If you cannot yet answer the six sections, an RFP will produce six incomparable guesses and burn two months of everyone's time. In that case buy the answer instead: a short paid discovery with one or two vendors produces the process maps, the integration inventory and the migration plan, and then the RFP is worth running. A ten-day discovery sprint at $3,250 or ₹2,00,000, credited to the build, is cheaper than a failed tender.

An RFP is also the wrong instrument when the work is genuinely exploratory, when the platform choice itself is undecided, or when the scope is small enough that the tender process costs more than the variance it protects against. Under roughly $25,000 or ₹16 lakh, a scoped proposal from two known vendors is usually the better trade.

Related reading

Questions to ask an implementation vendor before you sign covers the conversation after the bids arrive, the hidden costs that quotes leave out lists what to make bidders price explicitly, and our maintenance and support service page sets out what a care contract covers from $1,000 or ₹68,000 per month.

A good RFP is not a longer document; it is a shorter one that leaves the vendor nowhere honest to hide an assumption.