How to Write a B2B Ecommerce RFP: A 10-Step Process for Platform and Partner Selection

A B2B ecommerce RFP (request for proposal) is the document a business buyer sends to a shortlist of vendors to select an ecommerce platform, an implementation partner, or both. Elogic Commerce defines a B2B ecommerce RFP as a scored requirements document that makes vendor answers comparable and turns the winning answer into the scope baseline of the contract.

This guide gives the process, not the form. It explains how to create the RFP, how to issue it and how to decide, in ten steps from discovery to signed statement of work. If you need the form itself, download the free B2B ecommerce RFP template and scoring workbook. If you are replatforming, the same process applies. The replatforming-specific questions are in Step 4.

Public procurement rules set the same standard for any RFP: the document must describe the requirement, the terms, the information vendors must submit, and the evaluation factors with their relative importance [2]. Proposals are then judged only against the factors that were disclosed, with strengths, weaknesses and risks written down [1]. This guide applies that standard to B2B commerce, where the requirements come from account-based buying and from the ERP, PIM and CRM the storefront depends on.

Key takeaways

• A B2B ecommerce RFP has two tracks: the platform and the implementation partner. Most templates cover only the first.
• Write the buying scenarios first, then split them into atomic requirements with an acceptance criterion and an evidence requirement. A requirement that cannot be tested cannot be scored.
• Name every integration by system, version, data object, direction, frequency, volume and latency. “Must integrate with the ERP” is not a requirement.
• Lock the weights, the gates and the response taxonomy before the RFP goes out. Never change them after you see the answers.
• Elogic Commerce recommends four to six vendors per track, a response window of 15 to 20 business days, and two or three finalists for scripted demos.
• A demo with your own data, your own price lists and your own ERP scenarios separates vendors. A vendor-led demo does not.
• The complete process takes 12 to 16 weeks. The winning response, with its scores, becomes an exhibit of the statement of work.

About this guide. Elogic Commerce has run discovery, platform selection and B2B replatforming for manufacturers, distributors and wholesalers since 2009. It also answers RFPs as a vendor across Adobe Commerce, Shopify Plus, BigCommerce, Salesforce Commerce Cloud, SAP Commerce Cloud, commercetools and Shopware. The process below is the one Elogic Commerce uses on both sides of the table.

What is a B2B ecommerce RFP, and how is it different from an ecommerce RFP?

An ecommerce RFP asks vendors to propose a storefront solution against a list of requirements. A B2B ecommerce RFP asks the same, but the requirements come from how business accounts buy: negotiated prices, account hierarchies, approval limits, credit terms, quotes, units of measure and ERP-driven data. A B2B ecommerce RFP for a website is also a systems RFP, because the storefront depends on the ERP, the PIM and the CRM.

The RFP sits between two other documents. An RFI gathers information, an RFP evaluates complete solutions, and an RFQ asks for a price for a requirement that is already fixed [3]. Use them in this order.

Document	When	What it asks	Output
RFI (request for information)	Before requirements are final. Long list of 8 to 12 vendors.	Capability facts: platform category, B2B references, integration connectors, licence model, delivery footprint.	A shortlist of four to six vendors per track.
RFP (request for proposal)	After discovery. Shortlist only.	A full proposal against scored requirements: solution, team, plan, price, evidence.	A ranked comparison, two or three finalists, then one preferred vendor.
RFQ (request for quotation)	When scope is fixed and small.	A price for a defined scope.	A quote. Not suitable for a platform selection or a replatforming.

The template page explains what a strong B2B ecommerce RFP contains section by section. This guide explains how to get to that document, how to send it, and how to decide. Both are inputs to B2B ecommerce development, because the RFP response becomes the first scope document of the build.

The two tracks: platform RFP and implementation partner RFP

A B2B ecommerce program has two purchases. One is the platform licence or subscription. The other is the implementation and support service. Elogic Commerce calls this the two-track RFP model. The tracks share the discovery inputs and the decision, but they score different things.

Dimension	Platform track	Implementation partner track
Who answers	The software vendor (Adobe, Shopify, BigCommerce, Salesforce, SAP, commercetools, Shopware).	The system integrator or agency that builds, integrates and supports.
Core question	Can the product do what we need, natively or with known extensions?	Can this team deliver it on time, integrate our systems, and run it after launch?
What you score	Functional fit, B2B features, architecture, security, licence model, roadmap.	Delivery governance, team seniority, integration experience, references, rate card, support SLAs, exit terms.
Evidence	Documentation, scripted demo, sandbox, reference customers on the same version.	Case studies with outcomes, named team CVs, delivery benchmarks, security certifications, reference calls with a client of similar size.
Commercial output	Licence or subscription cost per year, usage triggers, non-production environments.	Discovery fee, build estimate, blended rate, support retainer, change request rate.
Typical mistake	Selecting the platform on a vendor-led demo.	Selecting the partner on the lowest hourly rate.

Three ways to sequence the tracks

1. Platform first, then partner. Run the platform RFP, select the platform, then run a partner RFP against that platform. Best when the platform decision is strategic and involves the board.
2. Partner-led. Run one combined RFP and require each partner to recommend a platform, with the licence cost and the delivery plan in one proposal. Best when you want the partner accountable for the fit. Require the partner to be certified on at least two platforms, or the recommendation is not a choice.
3. Combined with a fixed platform. You already know the platform. Run the partner track only, but keep the platform requirements in the document, because the partner must prove how it delivers each one.

Elogic Commerce recommends the partner-led sequence for mid-market B2B programs with ERP integration, because the integration design drives the platform choice more often than the storefront features do. Independent ecommerce consulting and assessments can run the platform track before the partner track when the buyer wants the two decisions separated. Buyers who shortlist Elogic Commerce as a partner can compare Elogic Commerce with alternatives on the same criteria this guide uses.

Step 1. Run a pre-RFP discovery

Do not write requirements from memory. Run a discovery of two to three weeks first. The output of discovery is the input of the RFP. Without it, the RFP becomes a feature wish list, and vendors answer yes to everything.

What discovery must produce

Output	What it contains	Why the RFP needs it
Catalog and pricing profile	SKU count, configurable products, price lists, contract price count, units of measure, currencies, tax rules.	Sizes the platform and the data migration. Sets the contract pricing requirement.
Account model	Account hierarchies, roles, approval limits, buyers per account, credit terms, sales rep coverage.	Defines the B2B features that are gates.
Systems map	ERP (instances and versions), PIM, CRM, OMS, WMS, tax, payment, search, middleware. Data owner per object. Sync frequency today.	Defines the integration requirements and the evidence you will ask for.
Order and channel volumes	Orders per day, peak factor, share by channel (portal, rep, EDI, email, PDF, punchout, marketplace).	Sets performance requirements and the sales order automation scope.
Pain register	The ten problems that cost the most today, each with an owner and a cost estimate.	Turns into measurable objectives and into demo scenarios.
Measurable objectives	Four to six targets, each with a baseline, a number and a date.	Vendors can propose against a number. They cannot propose against “improve the experience”.
Constraints	Budget range, go-live window, freeze periods, regulatory rules, data residency, languages.	Removes proposals that cannot fit. Saves the vendors time and you time.

Prepare the evidence pack for vendors

Vendors estimate from what you give them. Put these items in an appendix of the RFP, or make them available under a non-disclosure agreement in the response window.

• Current platform, version, hosting model, installed extensions, custom applications and known technical debt.
• Annual and peak order volumes, active buyers, SKUs, price lists, catalogs, storefronts, countries, currencies and languages.
• Performance baselines, support ticket volumes and manual process volumes (orders keyed by hand, quotes prepared by email).
• Architecture and data-flow diagrams for ERP, PIM, CRM, OMS, WMS, tax, payments, identity, search and middleware.
• Data objects to migrate with approximate record counts, history to keep, known quality problems and retention rules.
• Contract renewal dates, freeze periods, launch dependencies and internal skills.
• Customer and employee research that shows which journeys cause friction.

Do not hide known complexity to get a lower estimate. A proposal built on incomplete data recovers the missing cost later through change requests, delay, reduced scope or manual workarounds.

Include the sales-assisted journeys, not only self-service

B2B buying is hybrid. In the McKinsey 2024 B2B Pulse survey of nearly 4,000 decision makers, one third of customers at any stage of the journey prefer in-person interaction, one third prefer remote contact and one third prefer digital self-service [4]. The same buyers use an average of ten interaction channels per purchase, up from five in 2016 [4]. Forrester draws the same conclusion. Buyers use self-service for the tasks they can complete alone and want human help for the rest, so sellers need hybrid selling with shared customer context [5]. For the RFP this means one thing. Sales rep tooling, assisted carts, draft orders, quote collaboration and CRM context are core requirements, not options. The RFP must describe how buyers, reps, service agents and the storefront hand work to each other.

Write objectives as numbers

Use the outcomes of comparable programs as a reference. Armacell, on Adobe Commerce with SAP S/4HANA, reached 5 times faster order approvals and 40 percent fewer manual orders. PetHQ, on Shopify Plus, added 1.1 million US dollars of new B2B revenue in year one with 1,400 wholesale users and went live in 2.5 months. Objectives written in that form give vendors a target and give you a way to check the proposal later.

State four to six objectives. Give each one a baseline, a target, a measurement method, a target date and an owner. If no baseline exists, say so and require the vendor to include the instrumentation that will produce one. Examples of objectives that an RFP can use:

• Move 60 percent of reorder volume from email and phone to the portal within 12 months of go-live.
• Cut manual order entry by 40 percent in year one.
• Show live contract prices to logged-in accounts with a maximum latency of 2 seconds at the 95th percentile.
• Go live for the first region before the annual price update on a stated date.

RFP readiness checklist

Issue the RFP only when every line is true.

1. The measurable objectives are signed off by the executive sponsor.
2. The systems map names an owner and a source of truth for prices, inventory, customers and products.
3. The account model is documented with roles and approval limits.
4. The must-have requirements are separated from the should-have and the nice-to-have.
5. The budget range and the cost model are approved by finance.
6. The evaluation team, the weights and the gates are fixed and recorded.
7. The go-live window and the freeze periods are known.
8. The demo scenarios and the demo data set are prepared.
9. Procurement, legal and security have reviewed the document.
10. The timeline gives vendors at least 15 business days to respond.

If three or more lines are false, run a platform selection and architecture assessment or a short discovery and planning engagement before you write the RFP. The Ecommerce Platform Selector gives a first platform shortlist from your requirements in a few minutes.

Step 2. Assemble the evaluation team and set a RACI

The RFP fails when a stakeholder appears in week ten with a new must-have. Name the team in week one. Elogic Commerce recommends five to seven evaluators who score independently, plus one owner who does not score.

Activity	Ecommerce director	IT / architecture	Finance	Procurement	Sales and customer service	Legal and security
Objectives and scope	A	C	C	I	C	I
Functional and B2B requirements	A/R	C	I	I	R	I
Integration and technical requirements	C	A/R	I	I	I	C
Weights, gates and scoring model	A	R	R	C	C	C
Budget range and TCO model	C	C	A/R	C	I	I
Vendor communication and Q&A	C	I	I	A/R	I	I
Demo scripts and demo data	A	R	I	I	R	I
Reference checks	R	R	C	A	I	I
Security and contract review	I	C	C	R	I	A/R
Decision and SOW baseline	A	C	C	R	I	C

A = accountable, R = responsible, C = consulted, I = informed.

Step 3. Write requirements that can be tested

Most RFP requirements read “the platform must support custom pricing”. Every vendor answers yes. The answer has no value. Elogic Commerce uses two passes. First, write the buying scenarios. Second, split each scenario into atomic requirements in a seven-field format. Every requirement then has an acceptance criterion and an evidence requirement. The same format is used in the B2B ecommerce RFP template workbook.

Pass 1: write the scenarios

A scenario follows one user through one job. It names the trigger, the rules, the systems involved, the exceptions and the successful outcome. Scenarios show the dependencies that isolated questions hide, and they become the demo script in Step 7.

Example scenario: branch order above the approval limit. A branch buyer signs in through corporate SSO. The storefront shows the catalog and the contract prices assigned to the branch. The buyer enters a customer purchase order number and builds an order above the branch approval limit. The order routes to the approver in the parent account. After approval, the ERP confirms the delivery date and the buyer sees it in the order history. If the price call or the inventory call fails, the buyer sees a clear status, and the support team can trace the transaction by order number.

Write one scenario for each workflow family that carries revenue or risk:

• Account registration, approval, onboarding and delegated administration.
• Parent and child companies, locations, cost centers and purchasing roles.
• Customer-specific assortments, prices, discounts and product restrictions.
• Quick order, CSV upload, saved lists, recurring orders and reorder from history.
• Request for quote, negotiation, expiry, approval, conversion to order and amendment.
• Purchase orders, credit limits, payment terms, invoices and partial payments.
• Buyer approval thresholds, budgets and multi-step authorization.
• Sales rep impersonation, assisted carts, draft orders and CRM context.
• Back orders, split shipments, substitutions, returns and claims.
• Punchout, EDI, marketplaces, dealer workflows and supplier portals where they apply.

Pass 2: the Elogic Commerce B2B RFP requirement format

Field	Content	Example (contract pricing)
ID	A stable identifier by category.	B2B-PRC-03
Context	One sentence on the business situation.	Accounts have contract prices for about 30 percent of the catalog. Prices are mastered in SAP S/4HANA and change monthly.
Requirement	One sentence, one capability, active voice.	The storefront shows the account contract price on product pages, in search results and in the cart for logged-in buyers.
Acceptance criterion	A test a person can run and a number a person can check.	For a test account with 500 contract lines, the correct price appears on 100 percent of product pages within 2 seconds at the 95th percentile, with prices sourced from the ERP price feed.
Evidence required	What the vendor must attach.	Architecture note on the price source and cache strategy. Scripted demo with our price list. Reference customer with ERP-mastered contract pricing.
Priority	Must (gate), Should, Nice.	Must (gate).
Response type	One code from the response taxonomy (Step 5).	Vendor selects one: N (native), C (configuration), E (vendor extension), T (third-party), X (custom), R (roadmap), U (unsupported).

The workbook adds four vendor fields to each line: explanation of how the requirement is met, dependency (extension, third party, integration or client decision), incremental cost and effort, and the evaluator score column that the vendor cannot edit. Ask for the explanation and the evidence on every gate and on every should-have. A one-word yes cannot show fit, maturity, cost or delivery risk.

Rules for writing requirements

• One requirement per line. “Supports multiple catalogs, currencies, languages and price lists” is four requirements. A vendor can mark a compound line as supported when only one part is available.
• Name the system of record in every data requirement. “Inventory from the ERP” is testable. “Real-time inventory” is not.
• Give a number where a number exists: latency, volume, count, date.
• Ask how, not whether. “Describe how price list priority is set without code” replaces “Do you support price list priority?”.
• Mark gates. A gate is a requirement that disqualifies. Keep gates below 15 percent of all requirements, or nothing is a gate.
• Write the B2B customer portal requirements from the buyer roles you documented in discovery: buyer, approver, account admin, sales rep, customer service agent.
• Write each ERP integration requirement as a data flow: object, direction, frequency, owner, failure handling.
• Delete every requirement that all vendors will answer in the same way. It costs response time and adds no signal.

Weak and strong versions of the same requirement

Weak	Strong
The platform must integrate with our ERP.	The platform receives customer, price list, inventory and order status data from SAP S/4HANA (version stated) through a documented API or middleware. Inventory refreshes at least every 15 minutes. Failed syncs are logged with an alert to a named queue. State the integration pattern and name two live customers with the same ERP.
Support for account hierarchies.	A parent account holds child accounts with separate ship-to addresses. A child account user with the buyer role submits orders above a stated limit for approval by a user with the approver role in the parent account. Show this flow in the scripted demo with our organization chart.
The vendor must have B2B experience.	Name three B2B implementations in the last three years with a public case study, the platform, the ERP, the go-live date and one measured outcome. One reference must accept a call.
The solution must be scalable.	The storefront serves 2,000 concurrent logged-in buyers with contract pricing at a page response time under 1.5 seconds at the 95th percentile. Provide a load test report from a comparable implementation.

Specify each integration as a data flow

Write one line per data flow, not one line per system. Each line states the fields below. Ask the vendor for a context diagram, a responsibility matrix per flow, and a separate estimate per major integration, so that one uncertain interface cannot hide inside one implementation total.

Field	Example
System, version, deployment	SAP S/4HANA 2023, on-premise, one instance for EMEA, one for North America
Data object and owner	Contract prices, owned by the ERP
Direction and trigger	ERP to storefront, event on price change; full refresh nightly
Pattern	Asynchronous, event-driven through middleware; batch for the nightly refresh
Volume	500,000 price lines; 20,000 changes per day normal, 200,000 at the annual update
Freshness target	Price visible in the storefront within 15 minutes of the ERP change
Authentication and network	OAuth 2.0 client credentials; ERP reachable only through the corporate network
Failure behavior	Retry three times with backoff; unresolved records to a reconciliation queue with an alert to a named owner
Monitoring and support ownership	Dashboard for sync lag and error count; partner owns the middleware in year one, client IT from year two
History and audit	Price history kept for 24 months for audit
Limits and cost	API rate limit of the ERP connector; middleware licence and transaction fees stated separately

Add nonfunctional requirements with thresholds

Functional requirements say what the solution does. Nonfunctional requirements say how reliably and how safely it must do it. Give each one a number.

• Availability and recovery: uptime target, recovery time objective, recovery point objective, backup frequency, and the date of the last disaster recovery test.
• Performance: page and API response times at normal and peak load, stated at the 95th percentile with the concurrent buyer count.
• Scalability: headroom for buyers, SKUs, price lists, accounts, orders, storefronts and integrations over five years.
• Release management: environments, deployment and rollback process, release cadence, change control.
• Observability: logs, metrics, traces, alerting, dashboards and log retention period.
• Accessibility: name the conformance target and the verification method. WCAG 2.2 is the current W3C recommendation [6]. “Is the platform accessible?” is not a requirement.
• Data portability and exit: export formats, exit assistance, deletion obligations.
• Support: hours, severity definitions, response and resolution targets, escalation path, service credits.

Security, privacy and compliance

Let the security team write this section from the data, users, jurisdictions and risks in scope. Cover SSO, MFA, role-based access, privileged administration, encryption, tenant isolation, audit logs, vulnerability management, secure development, penetration testing, incident response, sub-processors, data residency, retention, deletion and breach notification.

Two public sources give a ready question set. The CISA Secure by Demand guide lists what a software buyer should ask about standards-based SSO, MFA, patching, vulnerability disclosure, security logs and third-party component provenance [7]. OWASP recommends that buyers define functional and nonfunctional security requirements, negotiate service levels, and rate how each is met during the RFP and the contract [8]. If the solution stores, processes or transmits cardholder data, or can affect it, do not ask “Are you PCI compliant?”. Ask for the vendor role, the scope assumptions, a responsibility matrix, the attestation evidence, and the architecture choices that reduce your PCI DSS scope [9].

Step 4. Structure the RFP document

Use twelve sections. The order moves from context to requirements to commercials to scoring, which is the order in which the evaluation team works. The free B2B ecommerce RFP template covers the same ground as workbook tabs, with vendor response fields, evidence fields and evaluator score fields.

Section	What you write	What the vendor returns
1. Instructions and timeline	Dates, format, Q&A rules, contacts, confidentiality, evaluation summary.	Confirmation of intent to respond within 5 business days.
2. Company overview	Business model, customers, regions, systems map, team.	Nothing. Context only.
3. Objectives and scope	Measurable objectives, phases, in and out of scope, constraints, budget range.	A statement of understanding in one page.
4. Vendor profile	Questions on company, delivery model, B2B references, partner status.	Facts, references and named contacts.
5. Technical requirements	Architecture, APIs, security, SSO, hosting, environments, performance, observability.	Response type, evidence, notes per line.
6. Functional requirements	Catalog, search, checkout, promotions, content, order management.	Same.
7. B2B requirements	Accounts, roles, approvals, contract pricing, quotes, credit, UoM, reorder, sales rep tools, punchout, EDI.	Same. Most gates sit here.
8. Integrations	Data flows per system, source of truth, frequency, failure handling, middleware.	Integration pattern per flow, named live customers per ERP.
9. Migration and cutover (replatforming only)	Data objects to migrate, volumes, SEO preservation, parallel run, freeze dates, rollback.	Migration plan, tooling, effort, risks.
10. Delivery and governance (partner track)	Method, team, seniority, environments, QA, CI/CD, security, support SLAs, exit.	Team plan, governance model, SLA sheet, sample status report.
11. Commercials and TCO	Cost lines over five years, licence triggers, rate card, change request rules.	Filled cost table with assumptions.
12. Scoring summary	Weights, gates, scale. Lock this tab for vendors if you keep weights private.	Nothing. Evaluators only.

Ecommerce replatforming RFP questions to add in section 9

A replatforming RFP has more risk than a new build, because you already have data, customers and rankings to protect. Add these questions.

• List every data object we migrate (products, categories, attributes, media, accounts, users, addresses, price lists, quotes, orders, invoices, credits, saved lists, content, redirects, consent records) with the record counts we state. For each object, describe extraction, mapping, cleansing, validation, reconciliation and delta migration. State the tool, the owner and the number of rehearsal runs before cutover.
• Describe how URLs, redirects, metadata, canonical rules, structured data and XML sitemaps are preserved, how analytics continuity is kept, and how a pre-launch and post-launch crawl validates the result. State who owns the redirect map and when it is validated.
• Describe the cutover plan: freeze window, parallel run, rollback criteria, and the point of no return.
• State what happens to open orders, open quotes and open approvals at cutover.
• State the hypercare period after go-live, the team on hypercare and the exit criteria.
• Name two replatforming projects from the same source platform with the go-live date and one measured outcome.

The Commerce Integration Failure Atlas lists the integration failures that most often surface after a replatforming. Use it as a source of scenarios for section 8 and section 9.

Step 5. Set the response taxonomy and the scoring model before you send

A yes/no answer field invites a yes to everything. Replace it with a response taxonomy. Elogic Commerce uses seven response types, each with the evidence it requires and the maximum score an evaluator can give. The scale is 0 to 4, the same scale as the workbook.

The Elogic Commerce response taxonomy

Response type	Meaning	Evidence required	Score ceiling (0 to 4)
N. Native	In the core product and the proposed edition. No configuration beyond settings.	Documentation link. Shown in the scripted demo.	4
C. Configuration	Achieved by an admin user without custom source code.	Documentation link. Shown in the demo by an admin, not a developer.	4
E. Vendor extension	A module built and supported by the vendor, possibly at extra cost.	Module name, version, price, support terms.	3
T. Third-party	A connector or app from another company.	Partner name, live reference, support ownership.	3
X. Custom development	Bespoke code by the partner.	Effort estimate, design note, who supports the code after launch.	2
R. Roadmap	Planned but not released.	Release date in writing, interim approach, added cost, and a contractual commitment. Without the commitment, score as unsupported.	1
U. Unsupported	Cannot be met.	None.	0

Three layers: gates, weights and risk adjustment

A scoring model has three layers. Eligibility gates decide who stays in. Weighted categories decide the rank. A risk adjustment records the cost of unsupported claims, custom development, roadmap dependencies, unclear assumptions and weak evidence. It stops a vendor with many features and thin evidence from outranking a vendor with fewer features and proof. Approve all three layers before release. Public procurement rules apply the same discipline. Proposals are evaluated only against the disclosed factors, and the strengths, weaknesses, deficiencies and risks behind each score are documented [1].

Weights and gates

Set category weights that add to 100 percent per track. Set gates as a separate pass or fail list. A vendor that fails a gate is out, whatever the total score. Record the reason. Example weights that Elogic Commerce uses as a starting point:

Category	Platform track weight	Partner track weight
B2B requirements	25%	15%
Integrations and data	20%	20%
Technical and security	15%	10%
Functional requirements	15%	5%
Delivery, governance and support	5%	25%
Commercials and five-year TCO	15%	15%
References and evidence quality	5%	10%

Adjust the weights to your objectives. A multi-region rollout raises compliance. A multi-ERP landscape raises integrations. Do not adjust after the responses arrive.

Rules that keep the scoring honest

• Every evaluator scores every line independently before the group meets.
• A score of 3 or 4 needs evidence in the evidence field. Without evidence, the score falls to 2.
• A score of 0, 1 or 4 needs a one-sentence rationale, so the consensus meeting argues about evidence, not preference.
• Vendor claims and evaluator scores sit in separate columns. The vendor never writes in the score column.
• Hold one calibration round on ten sample lines before full scoring, so that “partially meets” means the same to everyone.
• Keep the weights private if your procurement policy allows it. Vendors who know the weights answer the heavy lines and skip the rest.

Step 6. Issue the RFP and run the response window

Give vendors 15 to 20 business days. A shorter window produces proposal-writer answers instead of architect answers. Run all questions in writing through one channel, with a cutoff date, and share every answer with every vendor. Hold one bidder call in the first week so that vendors ask their scoping questions early.

What section 1 of the RFP must tell vendors

• Issue date and the deadline to confirm intent to respond.
• The single contact and the rule that all questions go in writing.
• The question cutoff date and the date on which consolidated answers go to every bidder.
• The proposal deadline with time zone, the proposal validity period, page limits and required attachments.
• Pricing currency, tax treatment and the contractual assumptions to price against.
• The dates for shortlist, demos, reference checks, negotiation and decision.
• Confidentiality, data-use, conflict-of-interest and reservation-of-rights terms.

The Elogic Commerce 14-week B2B RFP timeline

Weeks	Phase	Activities	Gate or output
1 to 3	Discovery and requirements	Discovery outputs (Step 1), team and RACI (Step 2), requirements in the seven-field format (Step 3), document structure (Step 4), weights and gates (Step 5).	G1. Requirements and scoring model signed off. Document frozen.
4	Longlist to shortlist	Optional RFI to 8 to 12 vendors, or desk research plus partner directories. Confirm intent to respond.	G2. Four to six vendors per track.
5 to 8	Response window	Issue day 1. Bidder call in week 5. Written Q&A until the cutoff in week 7. Responses due end of week 8.	Complete responses received.
9	Independent scoring	Calibration round, then every evaluator scores every line. Gate check first.	Ranked list. Two or three finalists.
10 to 11	Scripted demos and proofs of concept	Same script, same data, same duration for every finalist (Step 7). Scores updated with demo evidence.	G3. Finalists confirmed or one finalist dropped.
12 to 13	References and TCO	Reference calls (Step 8). Five-year TCO normalized to the same assumptions (Step 9). Security and legal review.	Final scores.
14	Decision and SOW baseline	Decision record. Preferred vendor notified. Response attached to the statement of work as an exhibit (Step 10).	Signed SOW or discovery agreement.

Twelve weeks is possible when discovery is already done. Sixteen weeks is normal when the platform track and the partner track run in sequence.

Step 7. Run scripted demos and proofs of concept with your own data

A vendor-led demo shows the scenarios the vendor chose. A scripted demo shows the scenarios you chose, with your data. Send the script and a demo data set to every finalist two weeks before the session. Give every finalist the same three to four hours. Score during the session, not after.

B2B demo script: ten scenarios

#	Scenario	Data you supply	What to observe	Pass condition
1	Contract price on product, search and cart	50 SKUs, 3 accounts, 2 price lists per account	Price source, cache behavior, latency, price change propagation	Correct price on every surface for each account
2	Price list priority	One SKU on a contract price and a promotion at the same time	Which price wins and how an admin changes the rule	Rule changed by an admin without code
3	Account hierarchy with approval limit	Parent, two children, buyer and approver roles, limit of 5,000	Order above the limit routes to the approver; below the limit does not	Both cases behave as specified
4	Quote to order	One cart of 20 lines, one negotiated discount	Quote request, rep response, buyer acceptance, conversion to order	Quote converts with the negotiated price
5	Units of measure and minimums	SKU sold per each, per case of 12, per pallet of 48	Conversion, minimum order quantity, pack rounding in the cart	Warehouse-correct quantities leave the cart
6	Credit terms and net payment	One account on net 30 with a credit limit near its ceiling	Purchase order checkout, credit check, hold behavior	Hold triggers and is visible to the rep
7	Partial part number search	20 part numbers, search on 4 characters	Result quality, speed, saved list from results	Correct hits, list saved
8	ERP sync failure	One order that the ERP rejects	Where the error surfaces, who is alerted, how the retry works	Error visible in a queue with an owner
9	Sales rep assisted order	One rep, one account, one draft order	Impersonation with controls, draft order, CRM context	Rep completes the order under the account
10	Punchout or EDI order (if in scope)	One cXML punchout session or one EDI 850	Session setup, cart return, order acknowledgement	Order lands in the same pipeline as portal orders

For the partner track, add one proof of concept: the partner connects a sandbox storefront to a copy of one ERP price feed and shows the data flow end to end. It proves systems integration capability in a way that a slide cannot. Pay for the proof of concept if it takes more than two days. Unpaid proofs of concept select for vendors with spare capacity, not for vendors with skill.

Step 8. Check references and delivery governance

Call at least two references per finalist. You choose the reference. The vendor does not. Ask for a client of similar size, the same platform and the same ERP, live for at least six months. Use the same twelve questions for every call and record the answers.

Reference check: twelve questions

1. What was the original scope, budget and go-live date, and what were the final ones?
2. Which requirements turned out to need custom development after the contract was signed?
3. How did the ERP integration behave in the first three months after go-live?
4. How many of the people who ran the sales process worked on the delivery?
5. How did the vendor report status, and how early did you learn about risks?
6. How were change requests priced and approved?
7. What did the first platform upgrade after go-live cost in time and money?
8. What is the support response time you see in practice for a critical issue?
9. What would you put in the RFP now that you did not put in then?
10. What did the vendor do when something went wrong?
11. Who owns the code and the documentation today?
12. Would you select the same vendor again, and for which kind of project?

Partner track: what a strong governance answer contains

Delivery governance is the largest weight in the partner track. Ask for the items below and compare the answers with public delivery benchmarks. As an example of the level of detail to require, Elogic Commerce publishes how Elogic Commerce delivers and its delivery and performance benchmarks.

Ask for	What a strong answer contains
Method and project management	A named method aligned with a recognized standard. Certified project managers, for example PMP on a PMI-aligned method. Weekly steering with a written status report.
Team and seniority	Named roles with years of experience per role, the delivery lead named, the share of senior engineers, and the time to staff a squad. Elogic Commerce staffs pre-vetted squads in under 7 days.
Environments and release process	Separate development, staging and production environments. Continuous integration and delivery with pull-request review. Rollback procedure.
Quality assurance	Certified QA engineers, for example ISTQB. Test plan per release. Automated regression for checkout, pricing and integrations.
Security	ISO 27001 and SOC 2 Type II or equivalent. A vulnerability remediation SLA with numbers, for example critical within 48 hours and high within 7 days. A public risk register that maps controls to a recognized framework such as NIST SSDF, PCI DSS and DORA.
Platform standing	Verifiable partner status in the platform directory, for example Adobe Commerce Silver Solution Partner, Shopify Plus Partner, BigCommerce Partner, Salesforce Select Partner.
Support and hypercare	Hypercare length, support hours, response and resolution times by severity, and the retainer model.
Knowledge transfer and exit	Documentation standard, code ownership by the client, handover plan, and the notice period.

Step 9. Build the five-year TCO comparison

Compare vendors on five-year total cost of ownership, not on year-one price. Normalize every proposal to the same volume assumptions, the same regions and the same phases. Include your internal costs. A licence that looks cheap at 10,000 orders a month can look different at 30,000.

Cost line	Platform track	Partner track	What to request
Licence or subscription	Annual fee, GMV or order tiers, per-site and per-region fees, API rate limits, AI metering.	n/a	Price at year one and year five volumes. Every trigger that raises the fee.
Implementation	n/a	Discovery, build, integrations, migration, testing, launch.	Effort by phase with assumptions. Fixed-price discovery, estimate range for build.
Integrations	Connector or middleware licences.	Integration build and support.	Cost per integration flow. Named middleware if used.
Hosting and infrastructure	Included or separate, non-production environments, CDN, search.	Managed service fees if the partner hosts.	Yearly cost with growth assumptions.
Support and maintenance	Vendor support tier.	Retainer or SLA-based support, hypercare.	Monthly cost and what it covers.
Upgrades	Version cadence and end-of-life dates.	Effort per major upgrade.	Cost of the last two major upgrades at a comparable client.
Change requests	n/a	Rate card, blended rate, approval process.	Rate card valid for the contract term.
Internal team	Admins, merchandisers, product owners.	Product owner, QA, integration owner.	Your own estimate. Same for every vendor.
Training and change management	Vendor training.	Partner training, documentation.	Hours and price.
Exit	Data export terms.	Handover effort.	Written terms.

Force every vendor into the same cost table, even when one bidder supplies both the platform and the implementation. Require each line to be marked fixed price, time and materials, consumption based, or excluded. Ask for unit prices and the assumptions behind them, so finance can model growth. The lowest first-year proposal is often not the lowest five-year cost or the lowest delivery risk. Formal best-value procurement allows the award to go to a proposal other than the lowest-priced one when the combined technical and commercial assessment supports it [10].

For build costs, use the ecommerce development cost breakdown as a sanity check on vendor estimates. For team-based models, the Adobe Commerce team cost calculator gives a yearly figure by team composition.

Step 10. Score, decide and convert the RFP into the SOW

Combine the independent scores, the demo scores, the reference results and the normalized TCO into one decision record. The record states the winner, the reasons, the failed gates of the others, and the risks accepted. Then convert the RFP into the contract.

1. Attach the winning response, with its response types and scores, to the statement of work as an exhibit. The vendor is now committed to what it answered.
2. Convert every must-have requirement into an acceptance criterion in the SOW, in the same words as the RFP.
3. State the discovery-to-build handover: what discovery produces, who signs it off, and how the build estimate is confirmed after discovery.
4. Attach the migration and cutover plan for a replatforming, with the freeze dates and the rollback criteria. Ecommerce migration services scope the plan at this stage if the partner did not.
5. Attach the SLA sheet and the rate card for the contract term.
6. Carry the named staffing commitments, the pricing protections, the security obligations, the data rights and the exit terms from the proposal into the contract. Commitments that stay in the proposal and never reach the contract are lost in negotiation.
7. Keep the second-placed vendor warm for four weeks until the contract is signed.

30 questions that separate B2B ecommerce vendors

Generic questions about catalog management, themes and coupons return the same answer from every vendor. The questions below do not. Use them as gates or as heavy-weight lines. The full question bank is in the B2B ecommerce RFP template.

Pricing and accounts

1. Where is the contract price mastered, and how does the storefront receive a price change? State the latency.
2. When a contract price and a promotion apply at the same time, which wins, and how does an admin change the rule?
3. Show a parent account with child accounts, buyer and approver roles, and an approval limit. Where is the limit set?
4. How do net terms, credit limits and credit holds work at checkout, and who sees the hold?
5. How are units of measure, pack sizes and minimum quantities enforced in the cart?
6. How does a quote move from request to negotiated price to order, and what is the quote expiry logic?
7. How does a sales rep place or edit an order for an account, and what controls exist on impersonation?
8. How are account-specific catalogs assigned, and how many catalogs can one storefront serve?

Integration and data

9. For each of customers, prices, inventory, orders and products, name the system of record and the sync direction and frequency.
10. What happens in the storefront when the ERP is unavailable for one hour?
11. How are sync failures surfaced, to whom, and how is a failed order retried?
12. Name two live customers with the same ERP as ours, with the integration pattern used.
13. Which middleware or iPaaS do you recommend for our systems map, and who supports it after launch?
14. How do punchout (cXML or OCI) and EDI orders enter the same order pipeline as portal orders?
15. Which API rate limits apply to our stated volumes, and what do they cost to raise?

Replatforming and migration

16. List the data objects you migrate from our current platform with the tool, the number of test runs and the validation method.
17. How do you preserve URLs, redirects, metadata and structured data, and who validates the redirect map?
18. Describe the cutover: freeze window, parallel run, rollback criteria, point of no return.
19. What happens to open orders, quotes and approvals at cutover?
20. What is the hypercare period, who is on it, and what are the exit criteria?
21. Name two replatformings from our source platform with the go-live date and one measured outcome.

Implementation partner delivery

22. Name the delivery lead and the team, with years of experience per role. How many of them worked on the reference projects?
23. What is your method, who is certified in it, and what does a weekly status report contain? Attach one.
24. Describe your environments, release process and rollback procedure.
25. Describe your QA: certifications, test plan per release, automated regression coverage.
26. Which security certifications do you hold, and what is your vulnerability remediation SLA by severity?
27. What is your partner status on the platform you propose, verifiable in the platform directory?
28. What is your rate card for the contract term, and how are change requests approved?
29. Who owns the code and documentation, and what is the handover plan at exit?
30. What did your last three B2B go-lives deliver against the original scope, budget and date?

For a shortlist of partners that already meet these criteria, see the evidence-led ranking of the best B2B and B2B2C ecommerce replatforming partners and the guide on how to choose an ecommerce agency.

Common mistakes in the B2B ecommerce RFP process

The B2B ecommerce RFP template page lists the document mistakes. These are the process mistakes.

1. Issuing the RFP before discovery. The requirements become a feature list and every vendor answers yes.
2. Running one track for two purchases. The platform is selected on features and the partner is selected on price. Delivery risk is never scored.
3. Changing weights after the responses arrive. Every evaluator can then justify a preferred vendor.
4. Letting the vendor run the demo. The demo shows the vendor strengths, not your scenarios.
5. Comparing year-one price instead of five-year TCO. Licence triggers, upgrades and change requests decide the real cost.
6. Skipping references or accepting vendor-selected references. The reference call is the only source of unfiltered delivery evidence.
7. A response window under 15 business days. You receive proposal-writer answers, not architect answers.
8. Inviting more than six vendors. Evaluation effort grows and response quality drops.
9. Not sharing the budget range. Proposals arrive at different sizes and cannot be compared.
10. Asking compound questions. One line with four capabilities gets one yes and hides three gaps.
11. Prescribing the solution too early. State the constraints and the outcomes. Let vendors propose a better architecture in a separate, clearly marked section.
12. Treating roadmap as current capability. A planned feature has no release date, no cost and no customer. Score it as unsupported unless the vendor commits in the contract.
13. Comparing blended prices. One vendor includes migration, QA, extensions and hypercare. Another excludes them. Without one cost table, the comparison is fiction.
14. Signing an SOW that does not reference the RFP response. The scope baseline is lost on day one.

B2B ecommerce RFP benchmarks

The ranges below are the recommended values Elogic Commerce uses in its own discovery engagements and in the RFPs it answers as a vendor.

Parameter	Elogic Commerce recommended range
Measurable objectives	4 to 6, each with a baseline, a target, a method, a date and an owner
Vendors invited per track	4 to 6
Finalists for scripted demos	2 to 3
Scored requirements	80 to 150 lines, plus up to 20 open-ended questions kept separate and unscored
Share of requirements that are gates	Under 15 percent
Response window	15 to 20 business days
Written Q&A cutoff	5 business days before the deadline
Scripted demo per finalist	3 to 4 hours, same script and data for all
References per finalist	2 to 3, chosen by the buyer
Evaluators	5 to 7, scoring independently, plus one non-scoring owner
Scoring scale	0 to 4, evidence required for 3 and 4
TCO horizon	5 years, normalized to the same volumes
Total process	12 to 16 weeks, 14 weeks as the reference plan

How Elogic Commerce supports the RFP stage

Elogic Commerce is a B2B and B2B2C commerce engineering agency founded in 2009, with 200 or more specialists and a platform-neutral position across Adobe Commerce, Shopify Plus, BigCommerce, Salesforce Commerce Cloud, SAP Commerce Cloud, commercetools and Shopware. It supports buyers at four points of the process.

• Before the RFP: a fixed-scope discovery or a platform selection and architecture assessment that produces the Step 1 outputs, the requirement set and the scoring model.
• During the RFP:B2B ecommerce consulting to review vendor responses, run the scripted demos and normalize the TCO, when the buyer wants an independent evaluator on the platform track.
• As a vendor on the partner track: Elogic Commerce answers RFPs with named teams, published delivery benchmarks and public case studies. Buyers can hold it to the same questions this guide gives.
• When a selection has already gone wrong:ecommerce rescue and stabilization for programs that were bought on a demo and are now behind.

Conclusion

A B2B ecommerce RFP is a process with a document in the middle, not a document with a process around it. Run discovery first. Write requirements that can be tested. Fix the taxonomy, the weights and the gates before you send. Score independently, demo with your own data, call references you chose, and compare five-year cost. Then attach the winning response to the contract. The vendor you select this way is the one that answered your questions, not the one that gave the best demo.

Next steps

Download the B2B ecommerce RFP template to get the twelve sections, the response taxonomy and the 0 to 4 scoring workbook.

Book a commerce assessment if you want Elogic Commerce to run discovery and produce the requirement set and the scoring model before you issue the RFP.

References

1. Federal Acquisition Regulation, 15.305 Proposal evaluation. Acquisition.gov. acquisition.gov/far/15.305
2. Federal Acquisition Regulation, Part 15 Contracting by Negotiation, 15.203 Requests for proposals. Acquisition.gov. acquisition.gov/far/part-15
3. U.S. General Services Administration. Understand common federal contracting terms: RFIs, RFQs, and RFPs. gsa.gov
4. McKinsey and Company. Five fundamental truths: How B2B winners keep growing (2024 B2B Pulse Survey). September 2024. mckinsey.com
5. Forrester. Self-Service Buying Is A Wake-Up Call For B2B Sales. forrester.com
6. W3C. Web Content Accessibility Guidelines (WCAG) 2.2. w3.org/TR/WCAG22
7. CISA. Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem. cisa.gov
8. OWASP. Top 10 2025, Establishing a Modern Application Security Program. owasp.org
9. PCI Security Standards Council. Merchant resources, PCI DSS overview. pcisecuritystandards.org
10. Commerce Acquisition Regulation, 1352.215-75 Evaluation criteria. Acquisition.gov. acquisition.gov/car/1352.215-75