Short answerA good RFP for PLM, PIM, DAM or PXM describes business scenarios, prioritises requirements with MoSCoW, forces vendors into scripted demos on the buyer's own data and scores responses against weights agreed in advance. Scripted demos reveal fit far better than written answers, so they should carry the largest share of the score.
Key takeaways
- An effective RFP limits requirements to an estimated 80 to 150 testable statements, with no more than about 30% classed as Must.
- Scripted demo scenarios run on the buyer's own sample data typically deserve 30 to 40% of the total score, more than written responses.
- Scoring weights and the evaluation team should be fixed before the RFP is issued, so vendor presentations cannot shift the criteria.
An RFP should test fit, and most only test feature lists
The purpose of an RFP is to find the platform and partner that fit specific business processes. Most RFPs instead send 400 generic feature questions, receive "yes" to nearly all of them and learn little. Vendors answer what is asked, so the quality of the selection depends on the quality of the questions. A shorter document built around scenarios produces sharper differences between vendors and saves weeks of evaluation. The wider selection steps are covered in the PIM selection guide and the PLM selection process.
Use a fixed structure vendors can answer consistently
A consistent structure makes responses comparable. A practical RFP has seven parts:
- Company context: products, SKU counts, languages, channels, regions and growth plans.
- Current architecture: PLM, ERP, DAM, e-commerce and syndication systems, with volumes and update frequencies.
- Business scenarios: five to eight end-to-end processes, such as new product introduction or seasonal launch.
- Requirements list: functional and non-functional, prioritised with MoSCoW.
- Commercial questions: licence model, price drivers, five-year cost and contract terms.
- Implementation approach: method, team, timeline, partner ecosystem and references in the same industry.
- Response format and timeline: templates, deadlines, demo dates and decision date.
State volumes precisely. Licence and performance depend on SKU count, attribute count, asset volume, users and channels, and vague numbers produce incomparable prices.
Write requirements that can be tested
Each requirement should describe an outcome that a demo or reference can confirm. "The system supports workflows" earns a yes from every vendor. "A new article created in ERP appears in PIM within 15 minutes, routed to the category manager for enrichment, with completeness tracked per channel" separates them.
Apply MoSCoW consistently:
- Must: without it the solution is rejected. Keep this to roughly 30% of requirements.
- Should: important, and a workaround is acceptable.
- Could: valuable if available at no significant extra cost.
- Won't (this phase): out of scope now, recorded for roadmap discussion.
As an estimate, 80 to 150 well-written requirements cover a PIM or DAM selection. PLM selections often need more because of BOM, change management and supplier processes. Ask vendors to classify each answer as standard, configuration, custom development, partner product or roadmap, since a plain yes hides most of the cost.
Scripted demos reveal more than written answers
Scripted demos are the strongest evidence in any selection. Send each shortlisted vendor the same scenarios and a sample dataset two to three weeks in advance: perhaps 200 products with real attributes, variants, images and two languages. Ask them to show the process live, in the standard product, and to state where configuration was needed.
Typical scenarios include onboarding a supplier file with errors, enriching a product for three channels, handling a regulatory attribute change across a range, linking assets and publishing to a marketplace. Have business users score each scenario immediately, using the same scale, before discussing it as a group.
Agree the scoring model before vendors respond
Weights fixed in advance protect the decision from presentation effects. A typical model looks like this:
| Criterion | Weight (example) | Evidence |
|---|---|---|
| Scripted demo performance | 35% | Scenario scores by business users |
| Functional fit (MoSCoW) | 20% | Written responses, verified in demo |
| Architecture and integration | 15% | API documentation, technical session |
| Five-year total cost | 15% | Normalised commercial model |
| Implementation partner and references | 10% | Reference calls in the same industry |
| Vendor viability and roadmap | 5% | Financials, product strategy |
Score on a 0 to 5 scale with written definitions for each level. Any Must scored zero eliminates the vendor regardless of total. Normalise cost over five years using the method in total cost of ownership for PXM.
Avoid the pitfalls that distort selections
The same mistakes recur across selections:
- Copying a generic template, which produces generic answers.
- Shortlisting more than four vendors for demos, which exhausts the evaluation team.
- Letting vendors run their own standard demo instead of the script.
- Evaluating the software and ignoring the implementation partner.
- Skipping reference calls with customers of similar size and complexity.
For additional selection checklists, pimselection.com offers further guidance on running a PIM selection.
Frequently asked questions
How long should a PIM or DAM RFP process take?
A focused process typically takes 10 to 16 weeks as an estimate: three to four weeks to prepare requirements and scenarios, three weeks for vendor responses, three to four weeks for scripted demos and reference calls, and two to three weeks for negotiation and decision.
How many vendors should receive the RFP?
Send the RFP to five to eight vendors after a desk-based longlist review, then invite three or four to scripted demos. More than four demo candidates overloads the evaluation team and reduces scoring quality, because business users cannot compare that many sessions reliably.
What is MoSCoW prioritisation?
MoSCoW classifies each requirement as Must, Should, Could or Won't for the current phase. Must items are knock-out criteria, Should items are important with acceptable workarounds, Could items are desirable extras and Won't items are deferred. It keeps vendors and evaluators focused on what decides fit.