LMS RFP Template & Requirements Checklist

Most LMS procurements don't fail because the team asked too few questions. They fail because the team asked too many. Some templates run to hundreds of questions, and the result is predictable: vendors answer with copy-paste boilerplate, your team drowns in responses nobody can compare, and the decision ends up being made on gut feeling anyway.

This page is a tool, not another guide. You get a downloadable RFP template with around 50 questions that separate one vendor from another, and a weighted evaluation matrix so you can score the answers fairly. If you're earlier in the process and still figuring out what you need, start with our guide on how to choose the right LMS for your company or, for larger organisations, how to choose an enterprise LMS. Then come back here when it's time to send your questions to vendors.

Download the LMS RFP template

Download the LMS RFP template (docx). It contains everything you need to run a structured LMS procurement:

• A cover page and instructions you can adapt in minutes
• Two sections you fill in yourself: your organisation's background and your goals and use cases
• Eight question sections covering functionality, technology, security, implementation, support, pricing, exit terms and vendor background
• A weighted evaluation matrix with suggested default weights, ready to score three vendors side by side

It's a docx on purpose. Delete the questions that don't apply to you, add the ones that do, and make it yours. A shorter, sharper RFP gets you better answers than a longer one. Every question you remove is reading time you get back, times the number of vendors you ask.

What's the difference between an RFP, an RFI and a requirements specification?

A requirements specification is your internal document: what the platform must do, for whom, and why. An RFI (request for information) is an early, informal scan you send to a broad list of vendors to understand the market and build a shortlist. An RFP (request for proposal) is the formal document you send to that shortlist, with specific questions, a deadline and a structured way to compare responses.

You don't always need all three. For a smaller purchase, a solid requirements checklist and a couple of well-prepared demos often get you there. The formal RFP earns its keep when several stakeholders need to agree, when procurement rules apply, or when the contract is big enough that a wrong choice hurts for years. If you're still working out what an LMS should do for you in the first place, nail down the fundamentals before you write a single requirement.

Start with your LMS requirements, not the question list

Define your own requirements before you write a single question to a vendor. Most teams skip this step, and it's the one that decides whether the RFP works at all.

Do it in two columns. Must-have means the platform is disqualified without it. Nice-to-have means it earns points in the matrix but doesn't knock anyone out. Be honest about which is which. When everything is a must-have, nothing is, and you'll end up comparing vendors on features nobody will use after month two.

A few things that help:

• Tie every requirement to a real use case. "SSO via our identity provider because IT requires it" is a requirement. "AI features" is not, until you can say what problem they should solve.
• Ask the people who'll actually live in the platform: the administrators who build courses and the participants who take them. Their daily friction matters more than a feature comparison chart.
• Cap your must-haves. If the list grows past ten or so, some of them are nice-to-haves in disguise.

Your must-haves decide which vendors make it into the matrix at all. How well each one meets them, together with your nice-to-haves, is what you score. That's all there is to it.

LMS selection criteria: how the weighted evaluation matrix works

Weight your criteria before the responses arrive. Give everything equal weight and the committee drifts toward the platform with the longest feature list rather than the one people will use. The weighted matrix fixes that, as long as you agree on the weights before vendor responses arrive. Set them afterwards and they tend to end up wherever someone's favourite wins.

How it works:

1. Agree on your criteria and give each a percentage weight. The weights must sum to 100%.
2. When responses come in, score each vendor 1 to 5 on each criterion.
3. Multiply each score by its weight and sum the column. The maximum weighted total is 5.0.

The matrix ships with suggested default weights: ease of use and functional fit weigh heaviest, followed by integrations and security, then support, pricing, implementation and exit terms. Treat the defaults as a starting point, not a verdict. A heavily regulated organisation will push security up. A lean L&D team of one might weight ease of use even harder. The exact numbers matter less than the fact that you argued about them openly, once, before the answers could bias you.

What's inside the RFP template?

Ten sections, plus the evaluation matrix. The first two are yours to fill in; the rest are questions for the vendor.

1. About your organisation and scope. Who you are, how many participants and admins, your timeline. Vendors give better answers when they know who's asking.
2. Goals and use cases. What success looks like: onboarding, compliance training, customer training, upskilling.
3. Functional requirements. How courses get built, delivered, automated and reported on.
4. Technical requirements and integrations. API, SSO, HR system sync, e-learning standards like SCORM, xAPI and cmi5.
5. Security and data storage. Where data is stored and who can touch it (more below).
6. Implementation and onboarding. What the road from signature to first live course actually looks like.
7. Support and partnership. Who picks up when something breaks, and how fast.
8. Pricing and total cost of ownership. The full picture, including the costs that don't appear on the pricing page.
9. Exit and data portability. Your terms for leaving, negotiated while you still have leverage.
10. Vendor background and references. Ownership, stability, and customers like you that you can call.

Security and data storage: questions every buyer should ask

You don't need to be a security specialist to run this section. You need a handful of direct questions and the patience to insist on direct answers.

Ask where your data is physically stored and under which jurisdiction the hosting entity operates. For European organisations, EU hosting is a standard question for every vendor on your list, because where data is stored determines which laws apply to it. Ask who owns the data (the answer should be you, unambiguously), which subprocessors are involved and where they process data, and how the vendor handles GDPR obligations in practice: the data processing agreement, data subject requests, deletion.

Then ask for evidence rather than adjectives. Which security frameworks does the vendor follow, and what can they show you: audit reports, penetration test summaries, an incident response process with committed notification timelines? A vendor who answers these questions plainly, in writing, is telling you something valuable about how they'll behave as a partner too.

Questions about integrations and technical architecture

Your LMS has to work alongside other systems. It needs to talk to your identity provider, probably your HR system, and possibly your CRM. The template's technical section keeps this focused: is there a documented, open API and what can it do; which SSO standards are supported; how are users provisioned and deprovisioned automatically; and which e-learning standards (SCORM, xAPI, cmi5) can the platform import and export.

One practical tip: ask vendors to describe a real integration with a system like yours, not to confirm that integration is "possible". Almost anything is possible. What you're buying is how much of it works out of the box, and how much becomes a consulting project.

Support and implementation questions

Two platforms with identical feature lists can deliver completely different experiences, and the difference usually shows up here. The template asks vendors to describe a typical implementation timeline from signature to first live course, what's included versus priced separately, who from their team you'll work with, and what training your admins get.

On support, the questions get specific on purpose: which channels and hours, which languages, whether response targets are contractual, and whether you get a named contact person or a ticket queue. At Learnifier we've built our whole model around people you can reach, so we're not neutral here, and we think this section deserves more weight than most buyers give it. Judge every vendor, us included, by what they'll put in writing.

For what happens after you sign, and how to make the rollout stick, see LMS implementation checklist.

Exit clauses and data portability: protect your next migration

Negotiate your exit before you sign, while you still have leverage and goodwill. Nobody plans to leave, which is exactly why the clause gets skipped. Afterwards, you're negotiating with a vendor who has little reason to make leaving easy.

The template asks: which data can you export, in which formats, and can you do it yourself without opening a ticket? What happens to your course content and media at termination? What does offboarding assistance cost? When and how is your data deleted, and how is deletion confirmed? And will the vendor commit to a defined exit process in the contract, not just in the sales call?

If you're reading this because you're in the opposite situation, currently stuck in a platform that makes leaving hard, our guide to switching your LMS walks through how to get out cleanly.

The LMS evaluation checklist: how to send your RFP and compare answers fairly

You've defined requirements, trimmed the question list and set your weights. What's left is process discipline:

1. Send to three to five vendors. Fewer gives you no real comparison. More multiplies your reading load without improving the decision.
2. Same document, same deadline, same information. If one vendor gets a clarifying answer, all of them do.
3. Score independently first. Have each evaluator fill in the matrix alone, then compare. That's how you surface honest disagreement instead of anchoring on the loudest voice.
4. Let demos test your scenarios, not theirs. Give shortlisted vendors two or three of your real use cases and ask them to show, not tell.
5. Use the weighted total to focus the discussion, not to end it. When two vendors land close, the matrix tells you exactly where they differ. That's what your final conversation should be about.

Download the template, book an hour with your team to argue about the weights, and you've done the hardest part before a single vendor replies.