How to run a software selection (RFP) without losing a season
A structured selection process finds the right system and protects the selling calendar. A step-by-step guide for fashion businesses running a request for proposal.
KEY TAKEAWAYS Summary by the editors
- A software selection should start from business outcomes and processes, not from a feature wish list.
- A focused shortlist and scripted demos using the brand's own products and scenarios reveal far more than generic presentations.
- Requirements should be prioritised into must-haves and nice-to-haves, with fashion specifics such as size matrices, seasons and delivery windows tested explicitly.
- The timeline must work backwards from the selling calendar so go-live does not collide with order-writing or peak delivery periods.
- Reference checks, total cost over several years and the vendor's implementation approach matter as much as the product itself.
A fashion brand decides it needs a new B2B ordering system. The project starts in spring, the request for proposal grows to hundreds of questions, demos drag on through summer, and the contract is signed just as the next order-writing period begins. Nobody has time to implement it, and go-live slips by a full season. Software selection does not need to work this way.
What is an RFP, and when is it worth running one?
A request for proposal is a structured process in which a company describes its needs, invites selected vendors to respond, and compares their proposals on consistent criteria. It is worth the effort for systems that are expensive, hard to replace or central to operations, such as an ERP, PLM, PIM or wholesale selling platform. For smaller tools, a lighter process with a short requirement list and trials is often enough.
How should the process be structured?
A well-run selection has clear stages, each with a decision at the end. A typical sequence looks like this:
- Define outcomes and scope. Describe what must improve, for example faster re-order processing or fewer order errors, and which processes and channels are in scope.
- Map current and target processes. Document how work happens today and how it should work, including exceptions.
- Write prioritised requirements. Separate must-haves from nice-to-haves. Keep the list focused on what differentiates options.
- Scan the market and shortlist. Use initial conversations or a request for information to narrow the field to a small number of serious candidates.
- Issue the RFP. Share context, requirements, integration needs, timeline and evaluation criteria.
- Run scripted demos. Ask each vendor to show the same scenarios using the brand's own data.
- Check references and negotiate. Speak to comparable customers, compare total cost and agree implementation terms.
- Decide and plan implementation, with dates fixed against the season calendar.
Which fashion-specific requirements should be tested?
Generic requirements lists rarely capture what makes fashion difficult. The selection should test these points explicitly, ideally in demos rather than written answers:
- Handling of styles, colourways and size runs, including size scales by market, prepacks and ratio packs.
- Seasons, collections, carry-over styles and multiple delivery windows on one order.
- Customer-specific assortments, price lists, currencies and payment terms.
- Pre-order, re-order and replenishment processes, including order minimums.
- Integration with the existing ERP, PIM and, where needed, EDI with retailers.
- Usability for the actual users, such as buyers, agents, merchandisers or customer service.
How should vendors be evaluated?
| Criterion | What to assess | How to assess it |
|---|---|---|
| Functional fit | Coverage of must-have scenarios | Scripted demos, scored by users |
| Integration | Fit with ERP, PIM and partner connections | Technical sessions, documentation review |
| Usability and adoption | Ease of use for daily users | Hands-on trials with key users |
| Vendor and partner | Industry experience, implementation approach, support | Reference calls with comparable brands |
| Total cost | Licences, implementation, integration, internal effort over several years | Structured cost comparison |
Scores should come from the people who watched the scenarios, recorded independently before any group discussion. That reduces the influence of the most persuasive presenter in the room and makes it easier to explain the final decision to the wider business.
Weighting the criteria before demos begin keeps the evaluation honest. Agreeing in advance that functional fit and integration together outweigh price, for example, prevents last-minute decisions driven by a discount.
How do you protect the selling calendar?
The most important scheduling rule is to work backwards from the season. Identify the periods when the business cannot absorb change, typically the main order-writing windows, trade fairs and peak delivery months. Then plan go-live for a quieter window and calculate when the contract must be signed to make that date realistic, including data migration, integration, testing and training.
Implementation capacity deserves the same honesty. Key users who must test, migrate data and train colleagues are usually the same people running the season. Reserving their time in the plan, and backfilling routine tasks where possible, is often the difference between a go-live that holds and one that slips.
It also helps to limit the size of the RFP. Long questionnaires slow vendors and evaluators alike and often produce answers that all say yes. A focused document, with scenarios that matter, leads to faster and more meaningful responses.
Finally, involve the people who will use the system from the start. Sales operations, agents, key account managers and, where possible, a few trusted retail partners can judge usability in ways project teams cannot. A selection that the business owns is far more likely to be implemented on time, and to deliver the improvements that justified it.
Frequently asked questions
How many vendors should be on an RFP shortlist?
A small shortlist, often around three, allows each vendor to be evaluated properly with scripted demos and reference checks. Longer lists increase effort without improving the decision.
Should we use a consultant for software selection?
A consultant can help with market knowledge, structure and negotiation, especially for large systems such as an ERP. The brand should still own the requirements and the final decision, because it will live with the outcome.
What is the difference between an RFI and an RFP?
A request for information gathers general information about vendors and products to build a shortlist. A request for proposal asks shortlisted vendors for detailed responses, pricing and implementation plans against specific requirements.
One edition every weekday morning. Read in five minutes. Free for industry professionals.
