A failed LMS requirements document always looks the same: one hundred and twenty lines of features, eight vendors answering yes to everything, and a decision that ends up being made on gut feeling or on the headline price. The problem is not how long the document is. It is what it describes. Here is the full template to copy, section by section, written for teams with no fixed desk and no work email address.
What an LMS requirements document is really for
An LMS requirements document sets out your training needs, your constraints and your selection criteria, so that several vendors answer on a comparable basis. It is neither a contract nor a wish list: it is the tool that makes a tender honest.
It serves three real purposes, often forgotten once drafting starts:
- Aligning internal stakeholders before going to market, so that nothing gets renegotiated at the last minute.
- Allowing an honest comparison of responses, on the same criteria and in the same format.
- Acting as a contractual baseline once the deal is signed, to settle any disagreement about what was promised.
One rule governs everything that follows: an overlong requirements document produces copy-and-paste answers, whereas a document that describes working situations produces answers that genuinely differ. Fifteen ranked requirements beat one hundred and twenty lines of features.
If you are still looking for the upstream method (criteria, stages, trade-offs), our complete guide to choosing the right LMS covers that ground. This article goes straight to the document itself.
The 3 most common mistakes
Three mistakes come up almost every time in the LMS requirements documents vendors receive.
Mistake 1, the never-ending feature list. Result: every vendor answers yes to everything and you can no longer tell them apart. Fix: fifteen ranked requirements beat one hundred and twenty lines.
Mistake 2, failing to describe who will actually use the platform. Result: you buy for the administrator rather than the learner, and adoption collapses within months. Fix: the users and use cases section is the most important part of the document, not a formality to be dashed off in two lines.
Mistake 3, thinking in headline prices. Result: the real cost doubles once integration, content migration and support are added. Fix: ask for a total cost over three years, in a format you impose and that is identical for every vendor.
Yes, cutting a list of one hundred and twenty lines down to fifteen feels daunting the first time. It is also what lets you genuinely separate the responses, rather than receiving the same document reworded eight times.
The complete template, section by section
The template has 10 sections, each with a precise purpose and standard content you can copy straight into your own document. Every section follows the same pattern: a numbered heading, one sentence on what it is for, then the standard content with variables in square brackets [like this] to replace with your own data. Sentences flagged as “wording to copy” should be reused as they stand: they are what constrains the shape of the responses.
- 01Context and scopeFrame the size of the project in one page
- 02Users and use casesDescribe who uses it, and under what conditionsDecisive section
- 03Objectives and metricsMake the project measurable
- 04Functional requirementsRank them, justify them, cap them
- 05Technical, security, dataHosting, compliance, exit terms
- 06Content and volumesMeasure the real migration workload
- 07Budget and total costImpose a single response format
- 08Onboarding and supportFrame what happens after signature
- 09Selection processImpose a demo built on your scenariosDecisive section
- 10Scoring gridDecide on weighted criteria
The four requirements to keep in mind when your teams work in the field: tracked offline mode, sign-in without a work email address, content you can complete in a few minutes, and exportable training records.
1. Context and scope
What it is for: framing the size of the project in one page, so vendors grasp the scale before they answer.
Standard content to copy:
- Company overview: [sector], total headcount [X], headcount to train [Y], of which [Z] have no fixed workstation
- Number of sites and countries involved: [number of sites], [countries], [share of sites with unreliable network coverage]
- How training works today: [who delivers it], [with which tools], [average training time per employee per year]
- Existing system to replace or keep: [current platform and reason for replacement], or [no tool in place]
- Main objective in one sentence: [example, “cut seasonal staff induction time from X days to Y days”]
- Project scope: [what is included] / explicitly excluded: [what is not]
- Target timeline: document issued [date], responses due [date], pilot rollout [date], full rollout [date]
- Single point of contact for the tender: [name], [role], [contact address]
2. Users and use cases
What it is for: this is the section that genuinely separates vendors, the one that forces them out of the generic demo.
Standard content:
- Describe 3 to 5 user profiles (field learner, frontline manager, course designer, compliance lead), each with: the device they actually have [personal smartphone, shared tablet, fixed workstation, none], time available per session [X minutes, between two tasks], where they sign in [site with no network, vehicle, office, home], working language [list], digital confidence [independent, needs support], and what they must be able to do unaided.
- State the volume behind each profile: [number of employees], [annual turnover rate].
- List 3 concrete scenarios vendors will have to demonstrate live (see section 9), written as real situations rather than features: [example, “a new agency worker completes their safety induction on their own phone, with no connection, before starting the shift”], [example, “a frontline manager checks in three taps who in their team is out of date on a certification”], [example, “an in-house trainer updates a sequence and pushes it to 400 people the same day”].
- Wording to copy: “Responses will set out, for each profile, the exact journey from first sign-in to completion of a first sequence.”
3. Objectives and metrics
What it is for: making the project measurable, not merely delivered.
Standard content:
- 4 to 6 dated, quantified objectives, in the form: [objective], [associated metric], [baseline], [target], [deadline]
- Example lines: raise onboarding completion from [X%] to [Y%] by [date]; cut the time between hiring and safety induction sign-off from [X days] to [Y days]; raise the share of field staff active at least once a month from [X%] to [Y%]
- State how each metric will be captured: [platform export], [native dashboard], [automatic feed into the HR system]
- Wording to copy: “Responses will state which metrics are available natively and which require bespoke development.”
To build those metrics, our article on measuring field training effectiveness sets out what to track beyond training hours.
4. Ranked functional requirements
What it is for: avoiding the endless list of mistake 1, by forcing every requirement to justify itself.
Standard content, as a three-column table:
| Requirement | Level | Working situation that justifies it |
|---|---|---|
| [e.g. offline mode with sync] | Essential | [Engineers work in basements, with no network] |
| [e.g. AI-assisted content creation] | Desirable | [The in-house trainer builds modules single-handed] |
| [e.g. gamification badges] | Optional | [No working situation identified] |
The third column is compulsory. It rules out decorative requirements, the ones added because they look good on paper, with no real working situation behind them.
Two drafting rules for this section:
- One requirement, one line, one working situation. If the third column stays empty, the line leaves the document.
- Aim for 15 to 20 lines in total, no more than 8 of them essential. Beyond that, nothing is genuinely essential any more.
- Wording to copy: “Any essential requirement not covered natively must be flagged as such, with the associated lead time and cost.”
5. Technical, security and data requirements
What it is for: protecting the organisation on hosting, compliance and exit terms, before signing.
Standard content:
- Hosting and data location: [required geography]
- UK GDPR compliance: [expected clauses], [retention period after termination]
- Authentication for people with no work email address: [access code, QR code, SSO]
- Expected integrations with the HR system or directory: [name the tools, e.g. SAP, Workday, TalentSoft]
- Supported devices and versions: [personal Android and iOS smartphones, shared tablet, fixed workstation], [minimum versions accepted]
- Accessibility: [expected WCAG conformance level]
- Expected availability: [SLA in %]
- Exit terms and data export at end of contract: [required export format], [lead time], [any cost]
- Wording to copy: “The vendor will state the exact data location, the identity of the hosting sub-processor, and the terms for returning data at end of contract.”
6. Content and volumes
What it is for: giving vendors a realistic picture of the workload, not just of the ambition.
Standard content:
- Existing content to migrate: [number], [formats: SCORM, PDF, video, slide decks], [volume in training hours]
- Who carries out that migration: [the vendor], [our internal team], [a third party], and to what timetable
- Planned annual content production: [number of modules per year], [who produces them in-house]
- Interface and content languages: [list], and expected translation approach [manual, assisted]
- Starting volume and growth over 3 years: [X users today], [Y in 3 years], [any seasonal peak and when it falls]
- Wording to copy: “The vendor will state the import format accepted and the volume of content included in the set-up fee.”
7. Budget and total cost
What it is for: forcing a comparable answer rather than a misleading headline price.
Standard content, response format imposed on vendors:
- Licence: [model, per active or per named user]
- Set-up: [cost]
- Content migration: [cost]
- Integrations: [cost]
- Support: [annual cost]
- Administrator training: [cost]
- Price changes over the term: [indexation clause, annual uplift cap]
- Total over 3 years: [sum]
Also state how high-turnover populations (seasonal and agency staff) are handled in the licence model: charged per named user or on actual usage? The answer changes everything in a three-year budget.
Wording to copy: “Any response that does not follow this cost breakdown will be treated as incomplete.”
8. Onboarding and support
What it is for: making sure you are not left on your own once the contract is signed.
Standard content:
- Launch support: [number of days], [type of contact], [on site or remote]
- Named contact after go-live: [yes, no], [who ensures continuity]
- Support language and hours: [detail], channel [phone, email, messaging]
- Response times by severity: [SLA for blocking incidents], [SLA for non-blocking incidents]
- End-user support: [handled by the vendor], [handled by our internal team]
- Proposed rollout plan: [stages], [milestones], [effort expected from us]
- Handover of skills to the internal team: [administrator training], [documentation], [number of people trained]
- Wording to copy: “The vendor will state the workload expected from our internal teams at each stage of the rollout.”
9. Selection process
What it is for: setting the timetable and, above all, imposing a demo built on your own scenarios rather than a generic one.
Standard content:
- Stages and dates: responses received [date], bidder questions [date], demos [date], decision [date]
- Imposed response format: [document], [grid to complete], [maximum page count]
- Eligibility criteria: [references with comparable workforces], [multi-site networks], [equivalent field headcount]
- List of vendors invited: [number], drawn from [internal research], [recommendations], or an overview of the platforms on the market
- Wording to copy as it stands: “The demonstration will cover only the three scenarios set out in section 2, performed live in the platform.”
- Wording to copy: “No generic presentation deck will be shown during the session.”
- Decision terms: scoring against the grid in section 10, decision communicated to all bidders on [date]
10. Scoring grid
What it is for: deciding objectively between the responses received, rather than on gut feeling.
Standard content: restate the five criteria and their weightings (real usage and adoption 40%, functional coverage 20%, technical, security and integrations 20%, onboarding and support 10%, total cost over 3 years 10%), set out in the next section.
Wording to copy: “The scoring grid and its weightings are issued to bidders alongside this document.”
Sharing the weightings upfront is not a weakness: it is what pushes vendors to work on your scenarios instead of stacking up ticked boxes.
The 4 requirements that get forgotten when teams work in the field
A requirements document written for office staff produces an LMS that field teams will never open. 61% of field workers have no access to mobile training today (IFOP study), a figure that captures exactly that blind spot in most requirements documents. Four requirements change everything, and they are missing from almost every template available online.
Genuinely tracked offline mode. Wording to copy: “the platform must allow a course to be completed with no connection and progress to be synced automatically once the network returns, with no loss of tracking.” How to test it in the demo: switch the phone to aeroplane mode while the vendor is presenting.
Sign-in without a work email address. Many field workers simply do not have one. Wording to copy, and the matching test: ask for an account to be created and signed into in front of you, in under two minutes.
Content you can complete in a few minutes. 50% of field workers say they have no time to train (IFOP). A field training session lasts as long as a break, not forty-five minutes sitting at a screen. Require content to be split into short sequences, usable on a smartphone.
Exportable proof of training. For mandatory training, require an exportable register showing who completed what, when, with what result, plus automatic reminders before expiry. Our article on regulatory certifications for field teams sets out what to require on this specific point.
- 01Genuinely tracked offline modeComplete a course with no connection, then sync progress automatically once the network is back, with no loss of tracking.Test in the demoSwitch the phone to aeroplane mode during the demo.
- 02Sign-in without a work email addressMany field workers have no company email address, so account creation cannot depend on one.Test in the demoAsk for an account to be created and signed into in front of you, in under two minutes.
- 03Content you can complete in a few minutesMaterial split into short sequences, usable on a smartphone, during a break.Test in the demoHave a full sequence opened and completed in real conditions, stopwatch in hand.
- 04Exportable proof of trainingA register showing who completed what, when, with what result, plus automatic reminders before expiry.Test in the demoAsk for the register to be exported in front of you, in the format your auditor expects.
Key point: these four requirements are the whole reason an LMS built for field teams like Beedeez exists, designed for people with no fixed desk and no work email address. On that kind of platform, completion reaches 95% when those constraints are respected, against 20 to 40% across the industry when they are ignored. A platform designed for the office can tick every box on paper without holding up in real conditions, which is why the live test matters more than the product sheet.
How to score the responses without going wrong
A weighted scoring grid decides objectively between responses, provided you weight the right criteria.
- Real usage and adoption40 %The demo built on your 3 scenarios, not the feature list.
- Functional coverage20 %Ticked boxes: the least decisive criterion, since every vendor answers yes.
- Technical, security and integrations20 %Hosting, UK GDPR, connections to your HR system and directory.
- Onboarding and support10 %Launch, support, handover of skills to the internal team.
- Total cost over 3 years10 %The total imposed in section 7, never the headline price.
Score each criterion from 0 to 5, multiply by the weighting, and only open the price column once the other criteria have been scored.
The imbalance is deliberate. Functional coverage carries the least weight, even though it is often the longest section of the document. That follows: it is also the section where every vendor answers yes, so it separates nobody.
Rule of thumb: score each criterion from 0 to 5, multiply by the weighting, and only open the price column once the other criteria have been scored. Looking at price too early skews everything that follows, however hard you try.
You now have the complete template, section by section, ready to copy into your own document. The only risk left is falling back into mistake 1: lengthening the list instead of describing your working situations. Stay on the scenarios, rank your requirements, and have vendors demonstrate live rather than present in a meeting room. If you want to test that approach on your own case, a Beedeez demo, the LMS for deskless workers, is built around your three scenarios rather than a generic script.
