RFP for PIM: How to Create a Request for Proposal for a Product Information Management System

This article was reviewed and updated on June 26th, 2023

Are you considering implementing a PIM system and preparing a Request for Proposal (RFP)? Our free guide and ready-to-use editable template will help you create it!

Download the Template

We suggest downloading the file now and analyzing it as you read this article.

Let's discuss each part individually.

1. Introduction and Basic Information

The introduction is a summary of the entire RFP. It should explain:

• The subject of the inquiry.
• The scope of the project.
• The purpose of the project.
• General information about your company.

First, describe the subject of the inquiry: what the request is about, the purpose of this request, and your expectations for the supplier. Explain your business's key desired areas of impact – e.g. consolidating data, reducing the time it takes to introduce new products to your catalog, getting a single place to edit information, or some other final effect.

Include the time frame (if any) and general information about the scale and nature of the project, e.g.:

• How many data objects (e.g. products, categories) and attributes (i.e. product features such as dimensions, color, material) the system will cover. 
• Which PIM system functions are crucial. 
• Who will use the system (i.e. departments, roles, etc.).
• Your current technology stack.
• Whether you have systems that will be the data sources for the PIM and whether they provide integration interfaces.

Remember that the scope of the project and the scope of the PIM offering do not necessarily coincide. Sometimes the PIM implementation is just one part of building an e-commerce system. In that case, informing the vendor so they know the broader context might be helpful.

You should also include general information about your company. Focus on issues relevant to the project and include data that suppliers cannot find independently. This may include:

• The number (and list) of markets in which the company operates.
• Your company’s key challenges and goals.
• International or foreign teams.
• Remote or hybrid work model.

This stage is where you include information about your company's culture. The alignment of working styles and shared values between the business and the supplier will also influence the project's outcome.

2. Bidding Procedure and Supplier Selection Criteria

In this section, describe how you will select a supplier. Create a framework schedule and specify what conditions the supplier should meet. Include the stages of the selection process along with the dates and who will evaluate RFP responses (i.e. what positions are involved). It will also help the suppliers prepare the answers.

Then outline your requirements for the supplier. We will explain more about this in Part II.

Openly indicate the selection criteria, particularly which requirements are critical and which are less important (e.g. whether price or experience is more important). It’s helpful to decide this hierarchy internally before you prepare the RFP. Determining the importance ratios between criteria will help the supplier prepare an offer that better matches your real needs and resources.

List in detail what the bid should contain and what attachments are required (e.g. references, relevant documents). Decide in which language the bid should be prepared and whether it should include the following:

• A technology stack proposal. 
• Proposed project methodology. 
• Description of the implementation team.
• Proposed project schedule.
• License terms and copyright information.
• Warranty and post-implementation care terms.
• Detailed pricing.

3. Current Processes and Those to be Supported by the PIM System

In this section, describe how the company currently manages product information.

When describing existing processes, present how they work. Focus on problems or areas for optimization. This will help the potential suppliers understand the context for the requirements presented next.

Provide, preferably in an attachment, a complete list of product attributes that will be used by all involved (e.g. which department is responsible for each of them).

To plan the implementation with synchronization and data migration in mind, the vendor should know the data sources and integration architecture by module, component, and integration methods. Note that the PIM system should have standard APIs and connectors connecting to flat files (i.e. xls or .csv). to the e-commerce database view, and to the API from the data bus that provides data from the ERP.

4. Functional Requirements

Functional requirements can sometimes be divided into two parts: technical and business. Write them down in a table so the supplier can comment on how they intend to implement them. This will give you a better understanding of a particular contractor's approach.

5. Non-Functional Requirements

Non-functional requirements refer to the broader, more general features of the system. This should include all your expectations that are not related to specific functionalities. They mainly concern architecture, security, performance, monitoring, and UX.

We present functional and non-functional requirements you should include in List the Requirements.

6. Budget

If you already have one, inform the potential suppliers of the planned or existing budget for the project.

Typically, companies do not share the project budget. They want to use the RFP to determine how suppliers will estimate their prices first. However, if you don't provide a budget, the supplier may assume that it is much higher than it actually is. They will then focus on covering all the requirements.

On the other hand, if the supplier knows how much the project is expected to cost, they will offer a more realistic quote and a scope of work closer to your actual needs. They’ll focus on how to meet your business goals within the indicated budget.

This practice is also a great start to a business relationship based on trust and transparency.

7. Contact Person

Designate a single contact person. One contact will help streamline the bidding process.

Part II. Stages of RFP Creation

Disclaimer: In the following sections, we’re only discussing the process of RFP creation. We are not including legal issues (e.g. signing an NDA), the distribution of the RFP, or the process of collecting and evaluating responses. Nor do we touch on the issue of choosing the optimal system.

Above, we described what should be included in a request for proposal and in what order. This doesn’t mean it's also the order of preparing the document parts. Where to start gathering information and how to write a comprehensive, precise RFP?

1. Gather a Team

Start by assembling a team that will be involved in creating the RFP and – later – in evaluating the proposals. The team should include:

• A manager who will oversee the entire process, ensure that all key stakeholders are kept in the loop, and keep an eye on deadlines.
• Contributors, i.e. representatives of all stakeholder groups and current/future users of the system.
• Experts from the sales, marketing, product management, and IT teams, who will give their opinion on the document and the target system.

This will mean that you will have to coordinate the efforts of multiple employees. According to a Raconteur survey, technology purchases can involve more than 16 people. Starting the process by determining who should be included in the team will ensure that you gather essential requirements from all actors and give them enough time to provide feedback on all stages.

2. List the Requirements

It’s a good idea to write down the requirements in a spreadsheet, independent of the RFP. This will allow the stakeholders to navigate through the document comfortably, filter its contents, and find the requirements they are responsible for. You can also create a space in the file for vendor comments.

We can divide the requirements into functional (related to the system's functions) and non-functional (what properties the system is supposed to have and what should characterize it).

The list of functional requirements is based on what processes the PIM is supposed to support, modify, or create. These may include, for example:

• Initiation of the product concept.
• Acceptance of the project proposal.
• Registration of the concept in PIM.
• Verification of the concept.
• Implementation proposal.
• Creation of technical documentation.
• Product data completion.
• Searching: full-text, by attributes, sorting.
• Editing and viewing products.
• Tagging and categorizing products.
• Editing permissions.
• Data import and export.
• Product analytics (e.g. sales by channel).
• Language versions.

You should also consider what product information (attributes) are to be included in the PIM system:

• Primary product data: SKU, name, description.
• Categories, tags, variants.
• Technical specifications: materials, components, warranties.
• Digital materials: images, videos, documents, animations, models,
• Keywords.
• Reviews, customer feedback.
• Information dedicated to specific channels (e.g. mobile, distributors).
• Translations and content dedicated to particular markets.

Keep in mind non-functional requirements. These may include:

• Architecture and technology: Your company’s current competencies and technologies and your preferred tools and systems/software for the project. You can also decide whether the system should be open source. 
• Security: e.g. compliance with Top 10 OWASP, NIST, etc.
• Performance: How many concurrent administrators should it support? When should data synchronization take place? How many calls per second will be handled by the API issuing data, etc.
• Monitoring: Whether active monitoring is required or passive monitoring will be sufficient.
• Scalability and redundancy: Whether the system is required to be built in HA (High-Availability).
• Service and maintenance: Is the system business critical? Is a 24/7 SLA required? What is the estimated number of users?
• Hosting and administration: Whether a hosting maintenance time is specified and your preferred model (i.e. Cloud, on-premise, off-premise, hybrid). What level of security is needed? Will the scalability of the computing environment be provided for? 
• Documentation: Remember to get the rights to documents created within the project team – e.g. instructions, description of design patterns, description of information architecture, details of integration with external systems, etc.
• UX: Determine who will be the system's main users and consider their needs. What can be done to make the admin panel user-friendly and intuitive?

3. Choose the Suppliers You’ll Invite

The requirements you have for the system are one thing. Separately, consider what your company expects from the supplier regarding team competencies, organizational culture, industry knowledge, and experience.

Think about some less-obvious qualifications, such as:

Include these requirements in the Bidding Procedure and Supplier Selection Criteria section. Internally, it might be helpful to first specify what you need from a vendor and your "deal-breakers": characteristics or practices that you consider a red flag. These may include:

• Lack of experience in international projects.
• Use of subcontractors.
• Inability to finish the project on time or within the established budget.

These deal-breakers do not have to be explicitly included in the RFP, but it's good to be aware of them; this will help you send the request to the right companies.

4. Edit the Document

At this stage:

• All stakeholders are aware of objectives, KPIs, budgets, and scope.
• You have established the hierarchy of needs.
• You know which companies you want to approach.

Now it’s time to edit the RFP document. Above all, focus on the clarity and transparency of the RFP. The more detailed and precise your description of your needs, requirements, and challenges, the better responses you will get.

Consider the document an invitation for dialogue and provide space for suppliers to comment. Avoid questions that are too narrow (you won't allow the supplier to show the complete picture of solutions) or too broad (because the answers will be too general). For example, instead of asking about the supplier’s approach to project management, ask:

• What methodologies and tools they use. 
• What the first weeks of working with them will look like.

Consider presenting the processes or system environment in more than just descriptive terms. A simple diagram often allows you to convey information much more effectively.

Experienced RFP document writers often write the beginning (Basic Information) last. When you have gathered detailed requirements from all stakeholders and can get a bird's eye view of the planned project, you’ll know what is most important and what to draw potential suppliers' attention to.

Finally, include the document's table of contents at the top of the document. This will help keep everything in order.

Why Is Creating an RFP So Important?

A well-written, precise RFP makes finding the right tech partner easier. You’ll have a better chance of selecting one that will create a solution, actively support your company in achieving its goals, and fit into your organization's culture.

The effort put into thoroughly analyzing the requirements (both for the system and the contractor) will help you avoid haphazard vendor choices and mitigate project risks that could result in later losses.

Finally, don’t think of an RFP as a single document. Think of it as a process in which key stakeholders ask questions, prioritize needs, and compare offers from different vendors. The final result should be a list of clear, specific criteria of what is crucial to your company.