An eCommerce RFP can be a fickle beast. Some retailers swear by them, others refuse to write them on principle, but if you’ve made the decision to write an RFP, it’s important to understand that there is no ‘one-size-fits-all’ approach. Many retailers fall into common pitfalls and end up flooded with responses that barely answer the basic questions, let alone provide a meaningful way to assess a future partner.

What to include in your RFP

Introduction and project overview

From your opening paragraph, your introduction should set both the goal of the project and your expectations from respondents. Keep the description of your project at a high level without going into detail. By the end of the introduction, the reader should be able to define the basic requirements of the project, its aim and the point of contact. It’s important that they understand the overarching objectives so they can then work backwards.

What should be in the introduction:

  • Detailed overview of the project
  • Details of the goals / objectives behind the project
  • A brief overview of what you’re looking for from applicants (e.g. a pro-active partner etc)
  • An intro to your company (doesn’t need to be too long, just an intro)

Company profile

Although your RFP respondents should / will conduct research around your company as part of their application, most RFPs include a brief company history, outlining how the project is intended to fit with your overall business strategy etc. As well as ensuring that applicants have the full context of the project, it also gives them the opportunity to suggest or make recommendations that could benefit your business beyond one project.

It’s also good to include details around the company’s values – this is good background for the applicants and you’ll generally receive the same from them as part of their response.

What should be in the company profile:

  • Brief history of your company
  • Details of how the project fits with wider business/growth strategy
  • Company values etc

Response guidelines

RFP response formats can vary, so I’d recommend that you provide details of your preferred format upfront. If you or your team do not have the time or inclination to read through hugely detailed documents – you’ll probably want to provide a suggested length / amount of detail.

You should also clarify whether you are running a Q&A style RFP where applicants are required to respond to each question with the appropriate information, or whether you want to include open questions for free-form answers. Some of the most effective RFPs we have seen provide detailed guidance around focal areas, making it a lot easier to respond to.

If you need responses in a certain document format or style, this should be specified here as well. For example, most merchants ask for a Word or PDF document, but I’ve also seen occasions where they’ve asked for a slide deck presentation. Although perhaps odd in a digital age, some procurement teams still insist on a hard copy delivered, alongside a digital version. If you or another part of your business needs this, specify this clearly, as respondents will need to act accordingly.

Include details on exactly who should receive the responses and where they should be sent. Most merchants tend to ask you to send it to multiple people, but provide details of a primary person to approach with questions etc. This primary contact should also be available for any questions and clarifications during the RFP period. A fixed deadline for submitting questions can be useful to ensure all participants have a fair chance to review and raise any issues with the RFP.

Finally, ensure your response deadline is included, formatted so that the applicant can clearly see by what time, as well as what day, a response is due.

Key things to include around guidelines:

  • State a preferred style of response (Q&A, free-form etc)
  • Specify a preferred format of response (PDF, Word doc, presentation etc)
  • State where and to whom the response should be sent
  • Clearly state the final deadline for responses

Current platform overview

Although your future partner will definitely need to assess your systems in greater detail once the project / the discovery phase is underway, it is helpful for applicants to have some background around your existing platform so they can roughly gauge the size of the project etc. By showing your platform’s existing limitations, responders will also be able to broadly detail their related experience early in the process.

Expect many of your responders to share your RFP with their technical consultants. If you have particular aspects of your system that represent a potential risk to the project, make sure these are detailed here. For instance, if you’re using a legacy stock management system that is prone to breaking, offering more technical detail around the issues will ensure applicants can include details of experience / solutions etc.

What should be included around the existing platform:

  • Explain in simple terms the problem you need to fix/move away from
  • Provide sufficient technical background for a respondent to accurately reply
  • Introduce any known risk in the project

New platform requirements

This section is where many retailers fall into a common trap. Although it’s tempting to push a list of required features, it’s more important for applicants to understand what you are looking for at a basic level without getting confused.

A good way to structure this section is to consider your required, preferred, and desired functionality. For example, if the required functionality was support for international stores, preferred functionality could be that it integrates with the new CRM system you are looking into. Desired functionality might be that it allows users to build wish lists or compare products.

At this stage, it is also integral to note requirements outside of the technology itself. For instance, will the successful applicant be expected to work with your existing third parties or to deliver development services on site? Must the successful applicant work with an in-house team and deliver the work using specific project management methodologies? The more context you can provide here the better.

It’s also important to detail your reasoning for choosing the technology you’ve selected (or provide reasons for looking at more than one solutions).

Key areas for the requirements section:

  • Requirements for the most important functionality
  • Details for any third party involvement
  • Any working or delivery requirements, such as Agile

The response

Whether using a Q&A or free-form format, it’s important to consider the questions you need answered by your suppliers. While many will appear obvious, it’s a good opportunity to consult with your stakeholders and define what is most important to you in a partner, and reflect your questions accordingly.

Although your exact questions will depend heavily on your specific project, below are some of the most typical requests we receive in an RFP:

  • Provide a company profile and brief history
  • Provide a financial/staff break down for your company
  • Provide an overview of why your company is best suited for this project
  • Describe your relevant experience for this project
  • How will you ensure we reach our project goal?
  • Describe your relevant working practices for this project
  • How do you assess project risk in a project of this size?
  • What is your approach to project and account management?
  • What are your deployment procedures? How frequent are delivery releases?
  • How do you measure quality in a project such as this?
  • Explain and demonstrate your ability to work with third parties
  • How do you manage security during development?
  • What supplementary services do you provide?
  • Provide client references to support your application

This is just a small selection of questions you could put to a potential supplier. Decide what is most important to you as a brand and a team and apply prioritisation to your questions.

Budget and pricing

Although not all retailers like to include pricing discussions within an RFP (and in many cases, this discussion may already have taken place), a pricing section can be useful. Wherever possible, provide guidance on what format you expect. For instance, if you need pricing per role, per day etc, and whether you wish to work to a fixed time and materials budget, or use a more agile approach.

However much guidance you include, all applicants will provide something different. For clarity, it can be useful to include a grid of pricing for respondents to complete. Not only will this be easier on the responders, but also provide a more simple point of comparison when you come to review each proposal.

Key things to include in this section:

  • The budget section includes guidance on what you expect from respondents
  • The budget section includes guidelines on the pricing unit you need
  • The budget section includes guidelines on whether you expect this project to be fixed price or managed in a more agile way

Other considerations

Watch your language

If the applicants cannot understand exactly what you need, your responses won’t match your requirements, which may not actually reflect the quality of the vendors / agencies. Keep your language clear and concise as the RFP needs to explain the complexities of your existing systems, but not at the risk of confusing the respondents. It’s a common tactic for respondents to reflect the tone and language from an RFP. For example, if you’re looking for a technical-focused response, make sure your language is applicable for a technical readership.  

Stay focused

Keep your RFP focused on your project and its goal. The RFP doesn’t, and shouldn’t be intended to, detail every piece of information about your project requirements. In many cases, the RFP is just one part of a long procurement process – and always remember that a good proposal response does not guarantee a good project.

Draft your assessment criteria as you write

As you break down your goals and requirements, it’s a good opportunity to decide how you will measure each response. In doing so, you may find you need to rephrase a question or have missed some vital information.

When you draft is near complete, open it for peer review with relevant teams to ensure nothing obvious has been missed. RFPs are often time intensive and after constructing one for hours, it can be hard to see any areas you might have forgotten.

Above all, remember that the RFP is as much a chance for potential suppliers to review you as it is for you to assess them. By sharing as much of your company values, personality and working style as you can, you’re more likely to end up working with a partner who shares what is important to your brand.

Other useful articles: