
Written for choosing a partner, on any platform
Free RFP Template
A vendor-neutral request for proposal for hiring the team that builds, migrates or rescues your store. Sixteen sections, 51 numbered questions every vendor answers in the same order, and a weighted scorecard your committee can use as it is. Word and Excel, free to adapt.
Download the TemplateWhy it is built this way
16 sections51 vendor questions9 weighted criteria
Most free ecommerce RFP templates are published by a platform or an agency, and it shows. The questions lean toward what the author sells, the scoring rewards the way the author works, and the structure quietly assumes the answer. A buyer who sends it out ends up comparing vendors on the author's terms.
A fair RFP does the opposite. It describes your business, your stack and your goals in your words, asks every vendor the same numbered questions, and says in advance how the answers will be weighed. That is what lets a buying committee compare five proposals line by line instead of five sales decks.
This one is written for choosing an implementation partner, not a platform. It works on Magento, Shopify, BigCommerce and WooCommerce, and it asks what buyers usually learn to ask the hard way: who owns the code, who answers after launch, and what happens if you part ways. Each of those questions is in here because a project went wrong without it.
Where selections go wrong
Each one is cheap to prevent in the RFP and expensive to fix six months into the project.

When the vendor writes the scope, the proposal describes what they want to build. Whatever they left out comes back later as a change request.

Five vendors, five formats, five ways of counting effort. The decision ends up resting on whichever pitch felt best in the room.

The repository, the hosting account and the admin owner login sit with the agency. You find out the day you try to leave.

Without written acceptance criteria, launch day turns into a negotiation about what was promised and what was meant.

Integrations, data migration and redirects stay vague in the brief, so they stay out of the estimate and return as extras.

The team that built the store moves on, and the first critical bug lands with people who have never seen the code.
Inside the template
Sixteen sections in six groups. Each one opens with why it matters, gives you the prompts to fill in and ends with the questions every vendor must answer. The evaluation weights and the submission timeline close the document.

Who you are, why now, the KPIs that define success, and an honest inventory of the platform, extensions and custom code you run today.

Requirements ranked must, should, could and won't, and every system the store talks to, with the direction and frequency of the data.

What moves, how it is validated, who owns the 301 redirect map, and what gets watched in Search Console after launch.

The design scope, WCAG 2.2 AA as the accessibility target, and Core Web Vitals written as numbers that can be tested.

Patching, PCI DSS scope, who has production access, the release process, and the acceptance criteria that define done.

Code and accounts in your name from day one, support times by severity, and a pricing format every vendor has to follow.
Write, shortlist, score
The timeline in the template runs six weeks from sending the RFP to a decision.
The scorecard
Nine criteria, weighted to add up to 100%. Change the weights to fit your priorities before the proposals arrive, never after.
| Criterion and Weight | What Scores a 5 | What Scores a 1 |
|---|---|---|
| Understanding of Your Goals and Scope (15%) | Restates your goals in their own words, challenges a weak assumption and ties the plan to your KPIs. | Generic proposal that misses requirements or answers questions you did not ask. |
| Relevant Experience and References (15%) | Two or more comparable projects on the same platform, with references you were able to call. | No comparable work, or references that were offered and never materialized. |
| Platform and Technical Expertise (15%) | Senior certified engineers on your platform, and specific answers to the platform questions. | Vague on the platform, or recommends a stack change without a reason that fits you. |
| Delivery Approach, Plan and Timeline (15%) | A phased plan with named milestones, the risks called out and a realistic timeline. | A timeline with no plan behind it, or a date chosen to win the deal. |
| Quality, Testing and Accessibility (10%) | Automated and manual testing, a WCAG 2.2 AA process and written launch criteria. | Testing is "included" with no description of how it is done. |
| Team Seniority and Continuity (10%) | Named people, their roles and allocation, one accountable lead, no surprise subcontracting. | No team named, or the team you meet in the pitch is not the team that builds. |
| Security, Ownership and Handover (10%) | You own the code and accounts from day one, patching is defined and handover is documented. | Code or accounts held by the vendor, or ownership questions dodged. |
| Support After Launch (5%) | Response times by severity, the same team supporting the store and upgrades planned. | Support is an afterthought or handed to an unknown third party. |
| Commercial Clarity (5%) | Pricing model, inclusions, exclusions, change requests and third-party costs all stated. | A single number with no breakdown, or key costs left out. |
Keep reading



Trusted by 100+ companies
FAQ
Tell us about your store and we will come back with straight answers.
Ask Your QuestionA request for proposal is the document a business sends to several ecommerce agencies or development teams to ask how each would deliver a project, on what timeline and on what terms. It describes your goals, your current stack and your requirements, and asks every vendor the same questions so their answers can be compared.
Your company and goals, your current stack, the scope as ranked requirements, every integration, data migration and SEO preservation, design and accessibility, performance targets, security and compliance, hosting and releases, testing and acceptance, ownership and handover, support after launch, the commercial format you want, your evaluation criteria and the submission timeline. This template has a section for each.
As short as accuracy allows. The template is about a dozen pages before you fill it in, and most of what you add goes into the requirements and integrations tables. Set a page limit on the responses as well, so your committee can read every proposal properly.
Three to five. Fewer and you have nothing to compare against. More and nobody on the committee reads every proposal carefully, which defeats the purpose of asking.
Two to three weeks, with one round of written questions in the first week. Share every question and answer with all the vendors, without naming who asked, so everyone prices the same scope.
Yes. The RFP in Word and the scorecard in Excel are free to use and adapt for your own selection. We ask for your name and email before the download so we know who is using it, and nothing else arrives unless you ask for it.
Yes. The core questions apply to any platform, and the questions that only make sense on one are tagged with it, such as extension compatibility on Magento and app audits on Shopify. Delete the tags that do not apply to you.
It is written for choosing an implementation partner. If your platform is still open, say so in the current stack section and ask each vendor to recommend one and justify it. A pure platform selection also needs licensing and product roadmap questions that this template leaves out.
If you can, as a range. Vendors then propose what fits it instead of guessing, and you avoid proposals that are either padded or impossible. The commercials section has an optional field for it.
Either works if every vendor uses the same one. Fixed price suits a scope you can describe completely; time and materials suits work you cannot. Many buyers ask for a fixed discovery phase first and decide the model after it. The template asks each vendor to state the model and break the estimate down by phase and by RFP section.
Agree the criteria and weights before the proposals open, then have every reviewer score every vendor from 1 to 5 on each criterion, alone. The scorecard turns the scores into a weighted total and a ranking. Use the totals to choose finalists, and the presentations and reference calls to choose the partner.
Answers that ignore your numbering, no named team, code or hosting held by the vendor, a single price with no breakdown, no questions asked before the proposal, a timeline far shorter than everyone else's, and testing or accessibility answered with one word. The scorecard has a sheet listing them, with what to ask instead.
One owner, usually the head of ecommerce or digital, with input from IT, finance and operations. Each of them owns a few sections: IT the stack and integrations, finance the commercials, operations the fulfillment and support requirements.
Usually not for the RFP itself, unless it contains sensitive figures. Require one before any vendor sees code, data or admin access. The submission section of the template says so for you.
Yes, if you would like us on your shortlist. Send it through our contact page and we answer the numbered questions in order, like every other vendor should.
Free to use and adapt
The RFP in Word and the weighted scorecard in Excel. Tell us who you are and both files are yours, free to use and adapt for your own selection.