The Problem with the Prescription
A Request for Proposal is a tool from the world of procurement, designed to create a level playing field for comparing vendors of commoditised goods. It enforces process, demands transparency on pricing, and creates an auditable trail for selection. For buying stationery or a new fleet of vans, this makes perfect sense. But a complex B2B commerce replatform is not a commodity. It is a bespoke piece of enterprise software, deeply integrated into your specific operational and commercial models. Applying a commodity procurement tool to a complex systems integration project is the first, and most critical, mistake a business can make.
The central flaw of the RFP is that it forces the client to be the expert. You write a detailed specification, often running to hundreds of functional requirements, a solution architecture diagram, and a list of technologies. You then ask agencies to respond, scoring them on their compliance. This process codifies your current understanding of the problem and its solution before a single external expert has been engaged. The result is a 'sea of green' where every agency says they can deliver every feature. The process rewards the agencies best at RFP-writing, not the ones best at engineering. It actively filters out partners who might challenge your assumptions, because the format provides no room for 'we would not do it that way'.
From Feature List to Wish List
The heart of most replatforming RFPs is a giant spreadsheet of functional requirements. This list is usually compiled by committee, gathering requests from across marketing, sales, IT, and finance. It quickly expands from a set of core needs into a sprawling wish list of features seen on other sites, in competitor platforms, or requested by the sales team years ago. The agency is then asked to estimate the effort for each line item. This atomises the project and obscures the big picture. It encourages a focus on quantity of features over quality of implementation. You are not buying features; you are buying capabilities that deliver specific business outcomes. The RFP format makes it nearly impossible to have that conversation.
This feature-first approach almost guarantees a 'like-for-like' build with some added chrome, which is the biggest missed opportunity in replatforming. The goal should not be to replicate your old, failing platform on new technology. The goal is to solve the business problems that led you to the replatform decision in the first place. For a builders merchant, that is not just 'show trade-account pricing'. It is 'how do we reduce the load on our branches by improving self-service for complex orders with call-off scheduling?'. The RFP asks for the former, but the business needs the latter. A good partner will force this conversation, while a standard RFP process prevents it.
"An RFP asks agencies to price the features you think you need. A 'Request for Partner' asks experts how to achieve the outcomes your business demands. One leads to rescue projects; the other to success."
The Iceberg of Non-Functional Requirements
What truly determines the success or failure of an enterprise commerce site is everything the RFP struggles to articulate: the non-functional requirements. Performance under peak load, data integrity with the ERP, extensibility for future needs, security against ever-present threats, and the total cost of ownership. These are not features you can list in a spreadsheet. They are emergent properties of a well-architected system, delivered by a senior engineering team making thousands of correct decisions during the build. An RFP might say 'the site must be fast', but it cannot specify the architectural choices that ensure search latency stays below 200ms with a catalogue of two million SKUs and 500 concurrent users. This is where experience counts.
We see the consequences of this in our rescue projects. They almost always suffer from failures in non-functional areas. The site is slow, it falls over during marketing promotions, the ERP integration is flaky, or adding a new feature requires a six-month project. The original partner, often chosen through a price-focused RFP, delivered the required feature list. But they failed to build a robust, scalable platform. As Forrester Wave reports consistently highlight for B2B commerce, architecture and the ability to integrate are primary determinants of long-term success. Your selection process must be optimised to find a partner who sweats these details, not one who just ticks the boxes.
The Request for a Partner
The alternative is to discard the traditional RFP and issue a 'Request for Partner' instead. This is a much shorter document. It details the business context, the strategic objectives, the commercial goals, and the operational problems you need to solve. It defines the 'why' and the 'what', but not the 'how'. It might state: 'We need to grow our B2B online revenue from £20m to £50m in three years', or 'We need to automate 80% of our trade-account setup and credit management processes'. It sets the parameters for success and invites a small number of carefully selected agencies to propose a solution.
This approach shifts the evaluation from ticking feature boxes to assessing an agency's thinking. You are buying their expertise, not just their keyboard time. The process encourages dialogue. It allows the agency to perform discovery, challenge assumptions, and co-create a solution with you. This often involves a paid, time-boxed discovery phase before you commit to the full build. It puts the real experts, the architects and principal engineers, at the centre of the conversation from day one. This is how we work at iWeb and is precisely the process we followed for the successful Adobe Commerce replatform for Bradfords. It ensures alignment and dramatically de-risks the main project investment.
