1. About your organisation
Enough for a provider to judge whether they understand your context. Two or three sentences plus the facts that constrain the work: learner population, regulatory context, existing platforms and the languages you need.
2. The problem and the outcome
Describe the performance problem, not the solution you have already chosen. A provider who can tell you the solution is wrong for your context is more valuable than one who agrees with everything.
3. Audience and learning objectives
Be specific about learner profile, prior knowledge, context, and what each learner should be able to do afterwards. Objectives written as behaviours, not topics, save a full round of design rework.
4. Scope and deliverables
State what you know and mark the rest as open. Give module count and rough length if you know it, and say so plainly if you do not. A provider can price a shape; they cannot price a guess presented as a fact.
5. Source material and content ownership
Say what you will supply, in what condition, by when, and who owns the intellectual property in it. Ask the respondent to confirm their assumptions about intellectual property, source file handover and third-party asset licensing. The answers vary widely and you need them in writing before signature, not after.
6. Technical and accessibility requirements
Name the standard, the package format, the delivery platform, the browser and device support, and the accessibility conformance level. Ask for a conformance report as a deliverable rather than a promise.
7. Process, review and governance
Define the sign-off gates, who signs off on your side, and what happens when a review round overruns. Ask the respondent to describe their process and name the people who would be involved.
8. Commercial terms
Ask for a fixed quotation against this scope, the quotation basis, milestone payment schedule, what is excluded, revision limits, change-order rates, and annual maintenance as a stated amount. Ask them to flag anything they consider unclear in their response, which reveals how they handle ambiguity.
9. Security, data and AI use
Ask directly whether AI tooling will be used, what data leaves your environment, what is retained, whether a private deployment option exists, and what human review happens before release. Also ask for security certifications and where our data will be stored.
10. Timetable and programme management
State your required go-live date and any immovable external dates, such a regulator deadline. Ask for a milestone plan and a critical path that shows where your own input is required and by when.
11. References and evidence
Ask for two references comparable to us in sector, scale and language coverage, and for permission to contact them. Ask for the one project they would least like to discuss, which produces a far more informative answer than a standard case study.
12. How to respond
Give a real deadline, state the format you want, say who to contact, and tell them what happens next. A clear closing section measurably improves response quality.
Next step
Once responses arrive, the comparison worksheet scores them consistently against your own weighted criteria.