An integration RFP template is a structured request for proposal that describes the systems you need connected, the data that has to move between them and the standards the result has to meet – in enough detail that vendors can price the work, and you can compare what they send back. It’s a narrower document than a general software RFP. You aren’t using it to pick a platform. You’re using it to pick the people who will build, test and often run the layer between your platforms, and that layer is where most enterprise projects find their surprises.
This article goes with a free Word template that you can download and fill in. I’ll explain why integration RFPs so often produce answers that can’t be compared, walk through each section of the template and the reason it’s there, and finish with a weighted scoring model for evaluating the responses. The aim throughout is a document that makes vendors commit to specifics, because an RFP that allows vague answers will get them.
Get the Integration RFP Template (Word)
Why integration RFPs usually fail
The typical integration RFP is a platform RFP with a paragraph tacked on at the end. It says something like “the solution must integrate with our ERP, CRM and data warehouse,” lists the systems by name, and asks vendors to describe their approach. Every vendor then answers with a confident description of its methodology, a list of connectors and a price that bears no relation to anyone else’s. The buyer is left comparing three numbers that were worked out against three different imagined projects.
Three omissions do most of the damage. The first is vague scope. “Integrate with the ERP” might mean a nightly file of invoices, or it might mean twenty real-time flows covering customers, orders, inventory, pricing and payments. Unless the RFP lists each integration as a separate item, vendors will scope whichever version they can win with, and the gap between that version and reality turns into a change request after the contract is signed.
The second is missing data volumes. A flow that moves five hundred records a day and one that moves five hundred a second are different engineering problems, with different architectures, licensing costs and ways of failing. Volumes also decide whether a vendor’s favorite tool is suitable at all. An RFP that leaves them out invites every vendor to assume whatever volumes suit its product.
The third, and the one with the biggest consequences, is the absence of system-of-record decisions. When customer data can change in both the CRM and the ERP, someone has to decide which system wins, field by field, and what happens when both change at once. If the RFP doesn’t say, each vendor makes a private assumption, and those assumptions rarely make it into the proposal. The question then comes back during testing, when it’s expensive to answer – and it usually turns out to be a business decision that IT can’t make on its own.
What the template covers
The template is organized so the buyer does most of the thinking before any vendor sees it. Every hour you spend clarifying scope before release saves several hours of clarification calls later on.
| Section | What it captures | The failure it prevents |
|---|---|---|
| Instructions and timeline | Submission rules, dates, contacts, confidentiality | Late questions, and vendors working from unequal information |
| Company and project background | The business outcome, drivers and constraints | Proposals that solve some other problem |
| Current systems | Every system, with its version, hosting, owner and API availability | Assumptions about access that turn out to be false |
| Integration inventory | One row per flow: source, target, objects, direction, frequency, volumes | Vague scope and prices that can’t be compared |
| Data ownership and system of record | The owning system for each object and each contested field | Conflict-resolution decisions made silently |
| Non-functional requirements | Security, monitoring, error handling, performance, SLAs | Acceptance on the grounds that “it works in the demo” |
| Migration, testing and cutover | Historical data, test environments, rehearsals, go-live | An underpriced migration and an unplanned cutover weekend |
| Support and operations | Hypercare, run support, response targets, handover | A production integration nobody owns |
| Vendor questions | Specific, answerable questions, with evidence requested | Essays where there should be commitments |
| Commercial response format | A fixed pricing structure, rate card and assumptions | Prices that can’t be compared |
| Evaluation criteria | A weighted scoring model, published in advance | Decisions made on the quality of the presentation |
Walking through the sections
Background and the systems involved
The background section should state the business outcome in plain terms – orders flowing from the commerce platform to the ERP without anyone re-keying them, say, or finance closing the month without a manual reconciliation. Vendors who understand the outcome make better design choices than vendors who only understand the list of systems, and a clear outcome gives you something concrete to test their proposals against.
The systems table then lists every system involved, with its version or edition, its hosting model, its business owner and – this is the critical one – whether it offers a documented API for the objects in question. A lot of integration budgets come apart on a single discovery: the system everyone assumed had an API exposes only part of what’s needed, or exposes it only in a more expensive edition. If you don’t know the answer for a system, say so in the table. An honest “unknown” lets vendors price discovery for that system separately, which is far better than each of them guessing.
The integration inventory
This table is the heart of the document. Each row describes one flow: the source system, the target system, the business objects it carries, the direction, the trigger or frequency, and the expected daily and peak volumes. If the same pair of systems exchanges different objects on different schedules, those are separate rows. A row you can’t complete is a sign that the flow needs discovery before anyone can put a fixed price on it, and the template asks vendors to price rows like that separately.
Peak volume deserves particular attention. Integrations rarely fail on an average day. They fail at month-end close, during a promotion or after an outage, when there’s a backlog to clear. A vendor who knows the peak can size queues, retries and licensing for it, and a vendor who doesn’t will size for the average.
Data ownership and system of record
For each object, the template asks you to name the system of record, the systems that receive it, any fields owned by some other system, and the business owner who has agreed to the decision. That last column matters more than it looks. System-of-record decisions made by the project team on its own have a way of being reopened by finance or operations late in testing. Getting the business owner’s name on the decision before the RFP goes out turns what would have been an argument into a requirement.
Non-functional requirements
This is the section most RFPs skip, and the one most failed integrations regret skipping. It covers security (authentication, credential storage, encryption, access to personal data), monitoring and alerting, error handling, performance and service levels. The template sets out error handling as a table of conditions and the behavior each one requires – what happens when the target system is unavailable, when a record is rejected, when the same message arrives twice, or when a reference value can’t be mapped. Vendors are asked to confirm or propose a behavior for each condition, which forces them to give a design answer where they’d otherwise offer reassurance.
Migration, testing and cutover
Migrating historical data is a separate piece of work from building live interfaces, and it should have its own price. The template asks for the objects to be migrated, their approximate volumes, how much history is included and how the migrated data will be validated. It also asks who provides the test environments, what data they contain, how many full rehearsals are planned before cutover, and what the rollback plan is for each interface. A vendor who proposes no rehearsals at all is telling you something about how the go-live weekend is going to go.
Support and operations
Integrations run for years, and the RFP should ask how the vendor will support them after go-live: the hypercare period, the run-support model, response and resolution targets by severity, and what the handover includes if your own team or another vendor takes over. Asking for this in the RFP means it gets priced alongside the build, instead of turning up later as a separate negotiation, held at a point when your leverage is gone.
Vendor questions and commercial format
The vendor questions in the template are written so they can be answered with specifics. Where a typical RFP says “describe your approach to error handling,” the template asks how the vendor makes sure a message processed twice doesn’t create a duplicate record, and asks for an example from previous work. Where it would say “describe your team,” the template asks for the named roles who will work on the engagement, and how much of their time each will give it. Specific questions produce answers you can score.
The commercial section prescribes a format: a price per integration or work package, discovery priced separately wherever the scope is uncertain, migration and support priced as their own lines, a rate card for changes, and a list of every assumption the price depends on. When every vendor fills in the same structure, the differences between their prices become visible – and so do the assumptions hiding behind a low number.
How to score responses
Publish the evaluation criteria and their weights in the RFP itself. Vendors write better proposals when they know what matters, and a published model protects the evaluation team from being swayed by whoever gives the most polished presentation. The weights below are a reasonable starting point for a project that’s heavy on integration. Adjust them to your situation, by all means, but settle them before the responses arrive.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Understanding of scope and requirements | 20% | Engages with each row of the inventory, flags gaps and risks, and asks sharp clarifying questions |
| Technical approach and architecture | 20% | A design that fits the volumes and the system-of-record rules, and explains its choices |
| Error handling, monitoring and data integrity | 15% | Concrete behavior for each failure condition, plus reconciliation, idempotency and alerting |
| Relevant experience and evidence | 15% | Comparable systems and volumes, with references you can actually call |
| Delivery plan, team and testing | 10% | Named roles, a realistic timeline, rehearsals and a rollback plan |
| Support and operations model | 10% | Clear response targets, a handover, and documentation |
| Commercials and clarity of assumptions | 10% | Complete pricing in the required format, with explicit and reasonable assumptions |
Score each criterion on a simple scale (0 to 5, for example), with a short written definition of what each level means, and have every evaluator score on their own before the group sits down to discuss. Multiply by the weights and add up the total. The total won’t make the decision for you, but it disciplines the conversation, and it makes it harder for one strong impression to outweigh a weak answer on error handling.
Price deserves a note of its own. Giving commercials a low weight doesn’t make price unimportant – it reflects the fact that a price only means something once you know what you’re comparing. A response that’s far cheaper than the others usually reflects a narrower reading of the scope, a missing migration line, or an assumption that quietly shifts work back to you. So read the assumptions list of the cheapest bid first. It’s often the most informative page in the whole evaluation.
Finally, treat the shortlist stage as a real part of the evaluation, and resist treating it as a formality. Ask the two or three leading vendors to walk you through how they’d handle your two hardest integrations, using your own volumes and system-of-record rules. The quality of that conversation is the closest thing to a preview of the engagement you’re going to get.
A client example. A mid-market distributor sent us an RFP for connecting a new ERP to Salesforce and its e-commerce site, and it listed three integrations: customers, orders and inventory. When we mapped the actual business events in discovery, those three nouns turned into eleven flows – customer creation and updates, ship-to locations, the product catalog, contract pricing, inventory availability, sales orders, order amendments, shipments and tracking, invoices, and credit status. Pricing was the biggest gap. Sales wanted contract prices pushed from Salesforce into the ERP, finance regarded the ERP’s price lists and customer agreements as the authority, and the RFP said nothing about it (or about returns, historical backfill, or who owned records rejected for missing master data). We separated a short paid discovery phase from the build and priced each of the eleven flows by its complexity. The plan moved from an optimistic 12 weeks to a phased program of 20 to 24, and every commitment in it was testable.
Before you send it
A short check before release saves weeks afterward. Confirm that every integration has its own row in the inventory, and that every row has volumes, even if some of them are estimates and marked as such. Confirm that each object has a named system of record that a business owner has agreed to. Make sure the non-functional requirements cover failure behavior as well as uptime, and that migration, testing and support are requested as separately priced items. Check that the commercial format is prescribed and the scoring model is published. Then give vendors enough time to ask their questions, and share every answer with all of them.
The template is a Word document with bracketed fields to replace, and it’s free to use and adapt. Tell us where to send it, and the download link will appear as soon as you submit.
Related reading
- How to scope integration work in a statement of work
- Free integration SOW template (Word)
- Integration reconciliation reports: proving two systems agree
How we approach it at eProxim
eProxim has been engineering integrations since 1997, and from where we sit, on the delivery side, the difference between a scope that leads to a good project and one that leads to a dispute is usually visible on the first page. The good ones share the qualities I’ve described here: a complete inventory, honest volumes, agreed systems of record, and a clear statement of what happens when things fail. When we respond to an RFP, we answer each row specifically, price discovery separately where the scope is genuinely unknown, and write our assumptions down so you can see exactly what the price depends on.
If you’re preparing an integration RFP and would like a second opinion on its scope before it goes out, or you want to see how we approach enterprise integration, get in touch with our team.