12 Learning Platform RFP Requirements for Riyadh Employers

A learning platform RFP in Riyadh should produce comparable evidence, not interchangeable promises. Descriptions such as “intuitive, intelligent and fully integrated” leave too much room for interpretation. Define the user, task and expected result, then specify how the supplier must demonstrate that result.

Establish the operating context

Describe expected users, job roles, locations, languages, current systems and the content and records involved. Separate the initial rollout from later expansion. Identify assumptions that affect integration, migration and support pricing. Suppliers cannot provide meaningful fixed estimates when the scope remains undefined.

Include these twelve requirements

1. User journeys. Require demonstrations of onboarding, mandatory training and skills development from employee, manager and administrator perspectives.
2. Arabic and a second language. Test search, notifications, assessments and reports as well as translated navigation.
3. Mobile access and accessibility. Specify devices and essential tasks, and request evidence covering keyboard use, zoom and assistive technologies.
4. Audience management. Define assignments by role, location or entity, including transfers and exceptions.
5. Content and assessment. Supply representative packages and files, and test launch, saving, resumption and results.
6. Identity and account lifecycle. Distinguish single sign-on from account creation, updating and deactivation.
7. Integrations. Name the systems, fields, exchange direction and frequency, including error monitoring and retry behavior.
8. Data and analytics. Define completion and proficiency, with export options, source definitions and access permissions.
9. Security and privacy. Request a processing map covering hosting, support and backups, alongside relevant control evidence.
10. Support and operations. Specify service languages, operating hours, incident severity, escalation and responsibility for updates.
11. Implementation and acceptance. Require migration, pilot, acceptance testing and administrator enablement plans with named responsibilities.
12. Cost and exit. Include licensing, implementation, change requests and export charges, plus data handover and service termination arrangements.

Give every requirement an acceptance test

Add priority, test scenario, required evidence and acceptance owner to each requirement. For Arabic, for example, ask a user to find a course, answer a question, receive a notification and open a report containing English terminology and numbers. “Arabic supported” is not sufficient evidence.

The WCAG 2.2 guidelines can inform accessibility tests. State the required conformance level and tested scope in the procurement documentation. One accessibility feature does not establish that every part of a platform is accessible.

Distinguish standard capability from development

Require suppliers to classify each answer as standard, configurable, custom development or unavailable. Link proposed development to a price, delivery date and acceptance condition. Keep disqualifying requirements separate from weighted preferences: a high overall feature score should not conceal a missing critical control.

Use identical demonstration tasks and representative data for shortlisted vendors. Record results against the written requirement rather than the persuasiveness of a presentation. Ask who will maintain any customization when the underlying product changes.

Carry the evidence into the contract

Review dependencies, exclusions and assumptions before selection. Explain how changes in user numbers, content volumes or integration scope will be priced. Retain the agreed test scenarios as delivery evidence, with a process for resolving failed acceptance tests.

Contact SkillUp MENA to discuss a corporate learning platform scope that helps your team evaluate solutions and operating responsibilities with greater clarity.