Decide what you are actually buying
Most failed RFPs are not caused by weak suppliers. They are caused by a buyer who has not decided, before going to market, whether the requirement is a course, a curriculum, a content framework, a production capability, or a combination. Suppliers then answer different questions and the responses cannot be compared.
Write a short definition of intent at the top of the document. State the performance or compliance need, the audience and its size, the channels available to you, the timeline, and what happens to the content afterwards.
This is not the specification. It is the context that lets a supplier tell you whether it is the right fit, and a good supplier will tell you early if it is not.
If you are not ready to write that paragraph, consider a shorter two-stage process. Publish a lightweight supplier qualification or market sounding first, then issue the full RFP once you understand the range of possible solutions and their real cost drivers.
Separate requirements from preferences
Buyers who list everything as mandatory get uninformative responses, because suppliers either answer yes to everything or disqualify themselves. Mark each requirement as must have, should have, or nice to have, and be honest about which of these are genuinely non-negotiable for your organisation.
Accessibility requirements, for example, are usually a genuine must have for public-sector or regulated buyers and a should have with a documented plan elsewhere. Requirements for a specific authoring tool are usually a should have, because tool familiarity matters less than the ability to deliver maintainable content in a standard format.
State the non-negotiables early and in a way a supplier can quote against. This is also where you protect yourself: the more precisely a must have is written, the more likely it is to be delivered and tested.
Write an itemised scope, not a narrative
The single biggest improvement to most RFPs is a table of deliverables. Courses and modules with estimated durations, video minutes, interaction types, number of assessments, language versions, and required output formats. Everything else in the document can then support a common denominator.
Include what is out of scope in a separate section. Subject matter expert time, workspace and tool licences, travel, voice talent, and post-launch content updates are the items most often assumed on one side and forgotten on the other, and they are frequently larger than the disputed content fee itself.
Where you genuinely do not know the scope, say so and specify a discovery or analysis phase with a defined deliverable and a defined cap. This protects both sides and gives you something to evaluate in the proposal rather than just a number.
Require a consistent response structure
Proposals that free-form their content are painful to compare and easy to game. Require a fixed structure: an executive summary, a restatement of your scope, a delivery approach, a sample or work plan, a named team with roles and availability, a milestone schedule, a line-by-line pricing table against your itemised scope, and a response to your evaluation criteria.
Ask for the pricing table to be structured by deliverable and by phase rather than as a single figure. It lets you compare cost drivers across suppliers and opens sensible conversations about trade-offs. If you want to allow alternate approaches, require the supplier to present them separately with a clear explanation, so you can judge the base proposal and the alternatives independently.
Also state the submission rules: length limits, page limits, file format, whether pricing must be valid for a stated period, and how any clarifications will be handled. Inconsistency in submissions is a symptom of a process that has not been designed.
Define evaluation criteria and weights in advance
Write your scoring criteria before you read a single proposal, and weight them. A common weighting for a custom content requirement places the largest share on demonstrated capability and quality of approach, with meaningful weight on team and delivery method, and a smaller but non-zero share on price.
Make each criterion specific enough to be scored by more than one person. Quality of approach, for example, becomes far more useful when broken into how the supplier would scope the work, how they would involve your subject matter experts, and how they would test the finished product.
Require a response to a short list of compliance questions, such as accessibility conformance, data handling and residency, security certifications, intellectual property terms, and business continuity. These are pass or fail, and it is better to surface a disqualification early than late.
Plan the process you will actually run
An RFP document is not a process. Decide how many stages you will run, who scores, how you will moderate, and how you will conduct the demonstrations and clarifications. Most buyers add a demo stage and a reference check stage because the written proposal alone rarely separates close candidates.
Set out the timeline with realistic slack, and decide what happens if no response meets your must-have criteria. The most common procurement failure is forcing a selection because a submission deadline arrived, which is exactly the moment a weaker vendor is most likely to be signed off.
Finally, plan the transition. Even a well-run RFP ends with a contract and a handover, and the quality of that handover determines whether the first month of production goes well. Our guide on how to compare enterprise content production proposals covers the evaluation stage in detail, and our guide on questions to ask a courseware development vendor for the question set itself.
Commonly overlooked pitfalls
- Publishing a narrative brief instead of an itemised scope, which makes responses incomparable and pricing unanchored.
- Treating every requirement as mandatory, which produces blanket compliance answers and self-disqualification.
- Failing to define the evaluation criteria and weights before proposals arrive, which lets presentation quality drive the decision.
- Omitting out-of-scope items, so subject matter expert time, licences, and post-launch updates become disputed costs.
- Not allowing enough time for a demo and reference stage, and ending up choosing on documentation alone.
Next steps
- Write a one-page definition of intent covering need, audience, channel, timeline, and post-launch use.
- Build an itemised scope table and a separate out-of-scope list, and mark requirements as must, should, or nice to have.
- Define a fixed response structure, page limits, and a line-by-line pricing table keyed to your scope items.
- Publish evaluation criteria with weights and pass or fail compliance questions before the deadline.
- Schedule a demonstration stage and a reference-check stage, and reserve a decision window rather than a hard decision date.
Related guides
Put this into practice
The vendor evaluation checklist and the RFP template turn a guide into a process you can run this week.