RFP to choose an iPaaS platform: technical and business requirements you should not leave out

When a company has already decided it needs an integration platform, the next step is not choosing a supplier by recommendation or by the flashiest demo. It is building an RFP, a formal request for proposal, that forces every supplier to answer by the same standard on the points that really matter to the business.

This guide reviews which technical and business requirements should not be missing from an iPaaS RFP, how to write questions that discriminate between proposals, and how to structure the evaluation of the answers.

Quick summary

• A demo shows the ideal scenario; an RFP forces written answers about the business’s real scenarios.
• Business requirements, support, SLA, pricing model, portability, weigh as much as the technical ones and are the ones most often left out.
• The questions that discriminate best are the ones asking you to describe a behaviour in the face of a failure, not the ones answered with a yes or a no.
• The evaluation needs a weighted matrix defined before receiving proposals, not after.

Why an RFP prevents decisions based on the demo

A demo shows the best of each platform, in controlled conditions, with prepared data. A well-built RFP forces the supplier to answer in writing about concrete scenarios: how many connectors the business needs, what happens if a connected system goes down, how errors are managed, what level of support is guaranteed. That documented comparison is what sustains the decision in front of the rest of the organisation.

There is an additional, internal benefit: building the RFP forces the team to define what it needs. Many organisations discover during that process that they did not agree on the project’s scope.

Technical requirements the RFP should include

• Available connectors for the systems the company already uses and the ones it plans to add, with detail of which operations each one covers. A connector existing does not mean it supports the flow you need.
• Integration modes: real time and batch, depending on the use case, and the ability to combine them.
• Error handling: automatic retries with progressive back-off, message queues, alerts on failures, and what happens to a transaction that fails definitively.
• Idempotency: how the platform avoids duplicating an operation when it is retried.
• Scalability: behaviour during volume peaks, platform limits and what happens when they are exceeded.
• Security: encryption in transit and at rest, access and credential management, and compliance with regulations relevant to the sector.
• Monitoring and traceability: visibility of the status of each integration in production and the ability to trace a specific transaction.
• Environment management: existence of separate test and production environments, and how changes are promoted between them.
• Version control: how flows are versioned and how a change is rolled back.

Business requirements that usually get left out

Requirement	What to ask specifically
Support	Response times for a critical incident, language, time zone, channel
SLA	Availability guaranteed by contract and compensation if it is not met
Pricing model	How cost scales with volume, connectors and users
Data governance	Who is responsible for which data and how flows are documented
Adoption curve	What technical knowledge the internal team needs to operate without the supplier
Portability	How integrations are exported if you change supplier
Roadmap	What is planned and how breaking changes are communicated
References	Customers of comparable size and industry, contactable

The pricing model deserves special attention. A platform that charges per transaction can be cheap at the start and expensive in high season, exactly when the business needs it most. It is worth requesting a three-year cost projection based on your own volumes, not on a generic case. As a reference for a volume-based model, Weavee’s plans are defined by the entities processed per month.

How to write questions that discriminate

The difference between a useful RFP and a decorative one is in the phrasing. Direct comparison:

• Weak: Does the platform handle errors? Everyone answers yes.
• Strong: Describe the system’s behaviour if the ERP does not respond for 30 minutes in the middle of an order peak, including what is queued, what is retried, what is discarded and what is notified.
• Weak: Do you offer support?
• Strong: State the committed response time for an incident that halts invoicing, at night and at the weekend, and the escalation procedure.
• Weak: Is it scalable?
• Strong: State the maximum volume processed by a current customer on a peak day and what limits apply in the proposed plan.

The questions that ask you to describe a behaviour, a procedure or a concrete number are the ones that separate proposals. The ones answered with a yes add no information.

How to structure the evaluation of the answers

Once the proposals are received, it is advisable to evaluate them with a weighted criteria matrix defined before receiving them, to avoid adjusting the weights to the preferred proposal.

Criterion	Suggested weight	What it evaluates
Functional coverage	25%	Required connectors and flows
Resilience and error handling	20%	Behaviour in the face of failures
Security and compliance	15%	Controls and regulations
Support and SLA	15%	Response to incidents
Total 3-year cost	15%	Projected TCO, not list price
Portability and governance	10%	Dependency risk

The weights are a starting point and should be adjusted to each business: an operation with complex tax requirements will weight compliance more heavily; one with strong seasonal peaks, scalability.

Two final recommendations for the evaluation: do not let price be the only tiebreaker, and consider the total cost of ownership instead of the licence price. A cheaper platform that does not cover the security or support requirements usually turns out more expensive in the medium term.

A narrow proof of concept is worth more than ten pages of answers

When two or three finalists remain, the most efficient way to decide is to request a proof of concept on a real, narrow and representative flow: for example, syncing stock between the ERP and a channel, with your own data.

The evaluation criteria have to be defined beforehand: how long it takes to implement, which part the internal team can do, how it behaves in the face of an induced error, and what visibility it offers during execution. A two-week proof of concept answers questions no written answer can.

Frequently asked questions

How long should the RFP process take? It depends on the organisation, but a reasonable process allows time to define requirements internally, a response window for suppliers, a round of clarifications and a proof of concept with the finalists. Compressing it too much usually ends in deciding by demo.

How many suppliers should be invited? Between three and five. Fewer limits the comparison; more generates an evaluation volume that is hard to sustain with quality. To build the shortlist, the integration platform comparisons, such as Weavee vs. MuleSoft, help sort out the differences in pricing model, support and maintenance.

Is a formal RFP necessary in a mid-sized company? Not necessarily with the full formality, but the exercise is: define requirements in writing, ask everyone the same questions and evaluate with agreed criteria. That is what prevents deciding by affinity with the salesperson.

What do I do if no supplier meets all the requirements? That is the most common scenario. That is why the weighted matrix matters: it makes it possible to decide which shortfalls are tolerable and which are disqualifying, instead of looking for a perfect solution that does not exist.

Should price be included in the initial RFP? Yes, but by asking for a three-year projection based on your own volumes, not a list price. And it is advisable to evaluate the technical answers before looking at the numbers, so price does not condition the reading of the rest.

Checklist to build your iPaaS RFP

• Does the RFP ask for concrete evidence of connectors for the critical systems, with detail of supported operations?
• Does it include questions about error handling, retries and idempotency?
• Does it ask about behaviour when a connected system goes down?
• Does it ask for detail on SLA, support and incident response times?
• Does it consider how the pricing model scales with the business’s growth?
• Does it evaluate how easy it would be to migrate supplier in the future?
• Are the evaluation matrix and its weights defined before receiving proposals?
• Is a proof of concept with the finalists planned?

You may also be interested in reading:

• “MuleSoft, Boomi, Workato, Celigo or Azure Logic Apps: how to compare enterprise integration platforms” • “Enterprise iPaaS vs standalone connectors: criteria to decide based on volume, risk and governance” • “Adobe Commerce experts: how to choose a partner to integrate your ecommerce with ERP, CRM and stock” Weavee helps structure your iPaaS RFP with the right technical and business criteria, and validate the finalists with a proof of concept on a real flow, so you compare on evidence and not on a demo.