Most LMS reporting features lists are written as questions: can it do this, does it support that. Every vendor answers yes. A requirements list works differently. Each line is a statement the product either meets or does not, with a priority attached and a way to check the answer, which is what an RFP evaluation matrix needs.
This checklist is written in that form. Copy the rows you need into your RFP, adjust the priorities to your situation, and use the last column during demos to confirm that "yes" means yes.
Each requirement carries a suggested priority:
The priorities assume a typical compliance, association or training company buyer. Change them to fit. A regulated healthcare organization may move data residency and audit trail items up; a training company may move revenue reporting up. Delete anything that does not apply, because a long list of irrelevant requirements makes it harder to see which vendor actually fits.
| Requirement | Priority | How to verify |
|---|---|---|
| The system reports on all core LMS records: users, courses, activities, enrollments, completions, grades and certifications. | Must | Request the list of reportable fields. |
| The system connects to the LMS directly, without manual exports. | Must | Ask for a demo on a live connection, not a static dataset. |
| The vendor states data refresh latency in writing. | Must | Ask how old the data on screen is, and confirm the answer in the response. |
| Custom user profile fields are available for filtering and grouping. | Must | Name one of your own custom fields and ask to see it used in a report. |
| The system can combine LMS data with external sources such as HRIS, CRM, membership or finance systems. | Should | Ask which sources connect natively and which need custom work. |
| The system retains history beyond the LMS's own log retention. | Should | Ask how far back a year-over-year report can go on day one and after two years. |
| Requirement | Priority | How to verify |
|---|---|---|
| Non-technical users can build new reports without writing code. | Must | Have someone from your team, not the presenter, build a report during the demo. |
| Reports support filtering, grouping, sorting and calculated fields. | Must | Ask for a calculated field you define on the spot, such as days until expiry. |
| Ready-made report templates cover completion, compliance and engagement. | Should | Request the template list and check it against your top five recurring reports. |
| Reports offer standard chart types alongside tables. | Should | Observe in demo. |
| Analysts can query the data directly, for example with SQL. | Could | Ask whether direct query access is included or priced separately. |
| Requirement | Priority | How to verify |
|---|---|---|
| Separate dashboards can be configured for different audiences. | Must | Ask to see two dashboards for two roles, built on the same data. |
| Reports can be scheduled for automatic email delivery in PDF, CSV or Excel. | Must | Ask to set up a schedule during the demo. |
| Users can drill down from any summary figure to the underlying records. | Must | Pick a number on a dashboard and ask to see the rows behind it. |
| Dashboards can be embedded in the LMS or an intranet. | Could | Ask for a live example. |
| Dashboards are readable on a phone. | Could | Open one on a phone during the demo. |
For what each audience's dashboard should actually contain, see our training dashboard examples.
| Requirement | Priority | How to verify |
|---|---|---|
| The system reports certification currency (valid today), not only historical completion. | Must | Ask for the share of a named population holding a valid credential today. |
| The system reports upcoming expiries and recertification windows. | Must | Ask for everyone expiring in the next 60 days, by manager. |
| A complete audit trail records who completed what, when, and any manual changes to records. | Must | Ask how a manually overridden completion appears in reports. |
| The system can report status as of a past date. | Should | Ask who was compliant on a specific date last year. |
| Evidence can be exported in a form an auditor will accept. | Should | Ask for a sample audit export. |
| Requirement | Priority | How to verify |
|---|---|---|
| Access is role-based, and data can be restricted by organization, site or reporting line. | Must | Log in as a manager and confirm only their team is visible. |
| Access restrictions follow the LMS's existing hierarchy rather than a separate model to maintain. | Should | Ask what happens to a manager's view when someone changes team in the LMS. |
| The system supports single sign-on. | Should | Confirm supported identity providers. |
| Viewing and exporting of reports is logged. | Should | Ask to see the access log. |
| Requirement | Priority | How to verify |
|---|---|---|
| The vendor states in writing the country where reporting data and backups are stored. | Must | Include it as a contract term, not only a response answer. |
| The vendor states where support and engineering staff access production data from. | Should | Ask separately from the hosting question; the answers often differ. |
| A full data export is available at contract end, in a documented format, at no cost or a stated cost. | Must | Ask for the export format and a sample file. |
| Retention periods for reporting data are configurable. | Should | Ask who sets them and what the default is. |
| Requirement | Priority | How to verify |
|---|---|---|
| Existing reports keep working through LMS upgrades, with the vendor maintaining the data model. | Must | Ask what happened to customers' reports at the last major LMS upgrade. |
| Support response times are stated in a service level agreement. | Should | Request the SLA document. |
| Large reports run within a stated time at your data volume. | Should | Give the vendor your learner and record counts and ask for expected run times. |
| Training is provided for the people who will build reports. | Should | Ask what is included and what is billed separately. |
Treat every Must as pass or fail. Score Should and Could items on a simple scale, for example 0 for not met, 1 for met with custom work, 2 for met with configuration and 3 for met out of the box, and weight Should items higher.
Three patterns in vendor responses deserve extra scrutiny:
A requirements list tells you whether a product can do the job. It does not tell you what kind of product you need in the first place. If you are still deciding between built-in LMS reporting, a BI tool and a dedicated platform, start with our guide to choosing a learning analytics platform, then compare the main options in learning analytics platforms compared. If you run Moodle or Totara, we are happy to walk through how Zoola Analytics answers this list, including the lines it does not meet.
At minimum: reporting on all core learning records, a report builder that non-technical users can operate, scheduled delivery, drill-down to underlying records, role-based access, and, for regulated organizations, certification currency and an audit trail.
Often, if your questions stay inside one LMS. Built-in reporting typically falls short when a report needs data from another system, history the LMS no longer keeps, or dashboards for audiences outside the training team.
As statements the product either meets or does not, each with a priority and a way to verify it. Questions such as "can the system report on completions?" invite a yes from every vendor and make responses impossible to compare.