It seems to me that eCommerce Platform RFPs are starting to open up again for 2025, so I thought it would be a good idea to talk about the elements of a great RFP process.

While I think the basics are well understood, some of the nuances of running a great RFP are not well understood at all.

No particular order:

- A clear picture of who your customers are and how they make decisions.

- A clear picture of your internal users and how they will interact with the software.

- A current and future state technical architecture diagram.

- A defined decisionmaking process and committee. A known signatory.

- Up-front involvement of a procurement and legal representative, if there is one available.

- An agreement with procurement for who is making the decision. Procurement as architect is to be avoided.

- A clear philosophy for the decision, outside of the exact technical requirements.

- A commitment to not make a decision based on a feature checklist response, but instead look at the entirety of the proposal.

- A prioritized list of business and technology pains. Quantified, if at all possible.

- A clear strategy for where your business growth is going to come from, that does not include the words: "we expect the new platform to grow our revenue, or increase our conversion" or any other such nonsense. Sure it might, but it also might not. For reasons outside of the control of the platform itself.

- A budget in mind, if not written down in your RFP document. It will become what people bid to, but that's OK. Good vendors will correct you if you are far off.

- Design inspiration for the new site.

- Whoever is running the RFP process should have minimal other commitments.

- A system integrator should not run your RFP. (Almost 100% of) System Integrators are beholden to specific platforms. This bears repeating.

- You should choose your platform and system integrator in rapid succession as part of your selection process. But you should be talking to both at the same time.

- Know that most system integrators will respond to any request, even if it's not their expertise. This is often not to your benefit. Beware of internally created software.

- A clear timeline and down-selection process.

- Thorough reference checks, amazingly this is not done often and you might think they are not useful because they are provided by the vendor. I assure you this is not the case. I can't tell you how many times the reference has given up things like: "we never even implemented the software." (true story) or "we got shares in the company to implement this".

There's more but this is a good start.