Contacts
Get in touch
Close

Contacts

UAE Office: Sharjah Media City (Shams), Al Messaned – Al Mutsannid Suburb – Sharjah – United Arab Emirate
Egypt Office: 29 Tag Eldin Elsobky, Heliopolis, Cairo, Egypt

(+971) (0) 52 381 2713

(+2) 010 137 49733

elearning@innovito.com

How to Write an eLearning RFP in MENA: A Comprehensive Guide for Government, NGOs & Enterprises

how to write elearning RFP

Introduction: The Middle East and North Africa (MENA) region is experiencing rapid growth in digital learning initiatives, driven by young tech-savvy populations and strong government investment in education technology. As government entities, large organizations, and NGOs increasingly seek eLearning solutions, a well-crafted Request for Proposal (RFP) is essential to find the right partner. An RFP is the formal document used to solicit proposals from vendors – it outlines your project’s needs and invites eLearning providers to propose solutions. Writing an eLearning RFP might sound daunting, especially if you have no prior experience with eLearning or Learning Management Systems (LMS). This guide will walk you through the entire process in a clear, step-by-step manner. We’ll cover key terminology (don’t worry – we include a glossary!), the two major types of eLearning RFPs (for LMS platforms and for content development/blended projects), and best practices for structuring your RFP to ensure you get quality proposals. We’ll also delve into templates, checklists, and examples inspired by real RFPs in the MENA and Gulf region (anonymized for confidentiality) to illustrate what works. By the end, you’ll understand how to craft a comprehensive eLearning RFP that attracts the right vendors and sets your project up for success – even if you’re completely new to eLearning.


Why a Good eLearning RFP Matters: Taking the time to develop a thorough RFP pays off in many ways. It forces you to define your needs and goals clearly (so you know what to ask for) and to prioritize between “must-haves” and “nice-to-haves” features early on. A detailed RFP also sets boundaries and expectations on key factors like timeline, budget, and technical constraints, preventing wasted effort on vendors that can’t meet your criteria. Crucially, an RFP acts as a filter to navigate a crowded market – there are over 800 LMS platforms available globally (and countless eLearning content developers), so a well-structured RFP helps you narrow down to serious contenders. Finally, a great RFP minimizes misunderstandings by putting everything in writing, ensuring vendors and buyers are on the same page about requirements. In short, a clear RFP sets the foundation for eLearning project success, leading to better proposals and ultimately an optimal solution for your organization.
Let’s start with the basics – some key terms and concepts you’ll encounter in the eLearning RFP process.
Glossary of Key RFP and eLearning Terms
For readers new to eLearning and procurement, the terminology can be confusing. Here’s a quick glossary of important terms you should know before writing your RFP:
RFP (Request for Proposal): A document an organization creates to solicit bids from vendors for a project. An eLearning RFP outlines the organization’s project details, requirements, and expectations, allowing vendors to propose solutions to meet those needs. (By contrast, see RFQ and RFI below.)
RFQ (Request for Quotation): A procurement document focused primarily on price quotes for a well-defined product or service. An RFQ is typically used when the specifications are clear and you simply need to compare costs. In eLearning, an RFQ might be used to get pricing for a specific off-the-shelf course or a set number of LMS licenses, without extensive solution design from the vendor.
RFI (Request for Information): A preliminary information-gathering document sent to vendors before an RFP. If you’re unsure what solutions or vendors are available, you might issue an RFI to learn about options and vendor capabilities. The RFI responses can then shape your RFP. (Example: a government NGO might use an RFI to survey what eLearning content providers specialize in health training in Arabic, then use that info to write a targeted RFP.)
LMS (Learning Management System): A software platform designed to create, deliver, and manage educational or training programs online. An LMS enables organizations to upload courses, enroll learners, track progress, and report on results in one system. In this guide, LMS procurement refers to selecting a platform to host and manage eLearning (including LMS or more advanced Learning Experience Platforms, LXPs).
eLearning Content: The digital training materials or courses that learners consume on an LMS. This can include self-paced modules (often interactive), videos, quizzes, PDFs, and other media. In an RFP context, content digitization means converting existing training materials (PowerPoints, documents, classroom trainings) into interactive eLearning formats. We’ll discuss RFPs for content development projects in depth.
Blended Learning: An educational approach that combines online eLearning with traditional in-person training or workshops. A blended project in our context might involve both deploying an LMS and creating digital content while planning for some face-to-face sessions. Many organizations in MENA favor blended learning to respect local training culture while leveraging online tools.
SCORM (Sharable Content Object Reference Model): A standard format for eLearning content packaging that ensures courses are compatible with most LMS platforms. If you develop SCORM-compliant courses, you can upload them to any SCORM-supporting LMS and track learner progress. (Your RFP for content should specify if you need SCORM or other standards like xAPI for interoperability.)
Localization: Adapting eLearning content or platforms to local language and culture. In MENA, this often means Arabic language support (and possibly French in North Africa) and culturally relevant examples. A good RFP addresses localization needs – for instance, requiring that the LMS interface be multilingual (English/Arabic) and that content be culturally appropriate for the region. There is huge demand for bilingual eLearning content in MENA (Arabic and English), so be sure to include language requirements in your RFP.
Tender: Common term used in government procurement, essentially synonymous with RFP. In many Gulf countries, issuing a tender means releasing an RFP document publicly for vendors to bid on. We will use “RFP” in this article, but if you work with government procurement departments, they may refer to the process as an open tender or bid.
Proposal: The vendor’s response to your RFP. It typically includes the vendor’s proposed solution, approach, timeline, and pricing. In eLearning projects, you might receive a technical proposal (detailing how the LMS or content will meet your requirements) and a financial proposal (the cost breakdown). In fact, many large RFPs – such as UN or government tenders – instruct vendors to submit technical and financial proposals separately for fair evaluation.
With terms defined, let’s explore the types of eLearning RFPs you might need to write, since not all eLearning projects are the same.
Types of eLearning RFPs: LMS vs. Content (or Both)
Not every eLearning initiative has the same scope. Broadly, eLearning RFPs in our context fall into two major categories:
RFP for an LMS Platform (Learning Management System procurement)
RFP for eLearning Content Development (or a Blended Project with both LMS and content)
It’s important to identify which type (or if both) match your project before writing the RFP, because the focus and requirements will differ. Let’s look at each type in detail.
1. RFP for an LMS Platform Procurement
If your organization needs a platform to deliver and manage online learning, you’ll be issuing an RFP to select an LMS. This type of RFP is common for government training institutes, large enterprises rolling out corporate learning, or NGOs creating a learning platform for beneficiaries.
Key considerations for an LMS RFP:
Define Your Objectives: Clearly state why you need an LMS and what you aim to achieve (e.g. “to deliver compliance training to 5,000 employees across 10 cities” or “to provide an online learning portal for university students”). Vendors need to understand your goals to propose a suitable solution. Be as specific as possible about the problems the LMS should solve (tracking training compliance, scaling onboarding, reducing training costs, etc.).
Describe Your User Base: Provide details on the audience and scale of your LMS usage. How many learners will use the system initially and over time (e.g. “starting with 500 users, growing to 2000 within 3 years”)? What are their demographics or technical abilities? Mention if the audience includes internal staff only, or external users (partners, customers, citizens). Also note language needs – e.g. “users are primarily Arabic-speaking, with some English interface needed”. In one Gulf government project, an LMS RFP specified support for multiple user types (administrators, instructors, learners in different departments) and bilingual UI (English/Arabic) to ensure inclusivity.
List Functional Requirements: Outline the LMS features you absolutely need versus nice-to-have. This is often done in a checklist form within the RFP. Common must-have LMS features include user management, course enrollment, progress tracking, reporting/analytics, assessments/quizzes, and certification. Many organizations also require mobile learning support (an LMS with a mobile app or responsive design) and integration capabilities (e.g. integrating with HR systems or Single Sign-On). For example, a finance-sector organization in the UAE required LMS integration with their HR database and an external Salesforce CRM to track training alongside performance metrics. If you have existing systems (HR, ERP, etc.), state the integration requirements clearly.
Technical and Hosting Requirements: Specify if you prefer a cloud-based SaaS LMS or an on-premise installation. Government entities in MENA sometimes require on-premise or local hosting for data privacy reasons, so note any data residency requirements. Indicate the expected concurrent users and performance needs (e.g. “should support 300 concurrent learners without performance degradation”). Don’t forget security standards – e.g. compliance with ISO 27001 or local regulations – if relevant. Detailing these technical criteria helps vendors determine if their platform can meet your IT and security policies.
Support and Services Requirements: An LMS purchase is not just about software – consider the implementation and ongoing support. In your RFP, ask about implementation services (setup, configuration, data migration from any old system) and training for your staff. Also, include expectations for ongoing support and maintenance: do you need 24/7 support, local support in your time zone/language, a dedicated account manager? Government clients often require a local support presence or rapid response SLAs. Make these needs known. For instance, an RFP might state: “Vendor must provide administrator training for 3 staff in Arabic, and offer technical support with 1-business-day response at minimum.”
Budget Disclosure: It’s often debated whether to include budget in an RFP. In public tenders, a budget may not be stated upfront; however, giving at least a ballpark or a funding range can help vendors tailor their proposals. You could say “the project budget is in the range of USD X to Y” or “not to exceed Z”. This prevents both undershooting and wildly overshooting proposals. Providing an estimated budget results in more accurate bids. If you cannot disclose a number, at least indicate whether price will be a primary deciding factor or if you’re open to higher bids for better quality.
Timeline Expectations: LMS projects can vary greatly in timeline. If you have a target launch date or any fixed deadlines (e.g. “we must launch the LMS by Q4 2025” or “the solution should be live before the new school year begins in September”), include these. In the Project Summary section of your RFP, state key dates: proposal due date, expected award date, and desired implementation timeline. Some RFPs even include a schedule for vendor presentations, sandbox testing, and decision milestones. For example, an LMS RFP’s proposal process schedule might look like:
RFP Release: Jan 1, 2025
Vendor Q&A Deadline: Jan 15, 2025
Proposal Submission Deadline: Jan 30, 2025
Demonstrations: Feb 10–20, 2025
Final Evaluation & Award: Feb 28, 2025
Including such a timetable (even if tentative) helps vendors know what to expect and ensures they can meet your schedule. It also signals that you have a structured plan, which is reassuring to bidders.
Example (Anonymized): An international public-health agency in the Gulf needed a modern LMS for training healthcare workers across multiple countries. In their RFP, they described the project: “We aim to implement a cloud-based LMS to deliver standardized training to ~5,000 healthcare professionals in both Arabic and English. Key LMS functions include multilingual support, mobile access for on-field personnel, and compliance tracking for mandatory courses. The platform must integrate with our existing HR information system for user provisioning. Vendors should also propose a content authoring solution or built-in tool for our team to create courses.” They provided current state details (e.g. “currently using manual tracking, no LMS in place”) and a vision for success. By painting a clear picture of their needs and context, they invited vendors to propose targeted solutions.
Include a Feature Checklist (if possible): Many LMS RFPs attach a features matrix – a list of desired features where vendors mark compliance (“Out-of-the-box”, “Customization required”, or “Not available”). If you have the resources, preparing such a checklist helps in evaluation. However, ensure the list is realistic and relevant; don’t just copy a generic 300-line spreadsheet of LMS features. Focus on what matters to your use case (e.g. if e-commerce or monetization is not needed for an internal LMS, you can omit those features).
In summary, an LMS-focused RFP should give vendors a crystal clear idea of what your organization does, who your learners are, what you need the LMS to do, and the constraints (time, budget, tech) within which it must operate. The next section on RFP structure will detail how to organize all this information.
2. RFP for eLearning Content Development (and Blended Projects)
The second major RFP type is when you need digital learning content to be developed or converted. This could range from creating a single online course to digitizing an entire curriculum of training modules. In some cases, it also includes implementing an LMS to host the content – which becomes a blended project covering both content and platform.


Key considerations for an eLearning Content RFP:
Project Scope – Content Details: Clearly define what content you need created or digitized. Provide as much detail as possible: number of courses or modules, estimated duration of each (e.g. “10 modules of approximately 30 minutes each”), the subject matter topics, and the source material availability. For instance, “We have 5 existing instructor-led workshops (with slides and manuals) on safety training that need to be converted to interactive e-learning modules.” If starting from scratch, outline learning objectives for each module. In one anonymized example, a regional NGO’s RFP stated: “Development of 10 e-learning modules (total ~90 minutes of content) on our Code of Conduct policies” and even listed the titles of each module (e.g. Introduction, Child Safeguarding, Anti-Trafficking, etc.). This level of detail helps vendors accurately gauge the effort and demonstrate relevant experience in those topics.
Authoring Tool or Format Requirements: Specify if you have preferences for the authoring tools or formats. Many organizations standardize on tools like Articulate Storyline, Adobe Captivate, etc., or need the output in SCORM format. For example, “Modules should be developed using Articulate Storyline and delivered as SCORM 1.2 packages”. The Mercy Corps RFP excerpt required Storyline as the authoring tool and SCORM compliance for a non-profit’s courses. If you have an LMS already, ensure the content will be compatible (SCORM/xAPI version, or if it’s a proprietary LMS, clarify how content must be delivered). Also mention if source files should be handed over (usually yes, so you can update later).
Multilingual and Localization Needs: Content projects in MENA often involve multiple languages. Indicate if the eLearning courses must be delivered in more than one language. It’s common for regional projects to require Arabic and English versions at minimum. For example, “Each module must be produced in both Arabic and English (with exact same content), and include Arabic voice-over narration”. If translation will be done by the vendor, specify that. In our NGO example, the RFP required modules available in English, Spanish, French, and Arabic to cater to a global staff. That meant the vendor needed robust localization capabilities (multilingual narration, on-screen text translation, etc.). Be sure to also mention cultural adaptation – e.g. “use regionally appropriate imagery and examples.” If you expect to review translations or provide glossaries, outline that process.
Interactivity and Media Requirements: Describe the desired level of interactivity and media in the content. Should it include animations, videos, quizzes, gamified elements, or is it mostly slide-based? If you want high-end interactive scenarios versus basic informative slides, clarify that so vendors with the right development skills will respond. Also, mention if you have any branding or style guidelines to follow. For instance: “Courses should incorporate our organization’s branding and follow our visual style guide (to be provided). We expect a mix of multimedia: animation, graphics, and some video interviews we will supply.” The more precise you are, the more accurate the vendor proposals (and pricing) will be.
Volume and Duration: If it’s a multi-module project, state the total seat time or hours of learning to be developed. Some organizations also specify the number of interactions or question items expected. For example, “approx. 3 hours of e-learning content total, comprising 6 modules of 30 minutes each, with at least one knowledge check (quiz) per module.” This level of detail helps vendors estimate effort. Remember to include any blended elements: if the project involves instructor-led components or physical workshops in addition to eLearning, outline how the vendor might support those (developing facilitator guides, slides, etc.).
LMS or Platform Context: If you already have an LMS where this content will live, mention it. For example, “Content will be hosted on XYZ LMS – vendors must ensure compatibility and assist with uploading courses to the platform.” If you do not have an LMS and need one as part of the project, then your RFP actually combines content + LMS procurement. In that case, you’ll have a broader scope: you’ll need to include all the LMS requirements from the first type of RFP plus the content development scope. Be explicit that you expect a one-stop solution. Many UN tenders and government projects in the region bundle LMS implementation with content creation. The advantage is you deal with one vendor or consortium for an end-to-end solution. The RFP should then have two parts: technical requirements for the LMS and scope for content development. Ensure vendors know they can bid on both or either parts (if you allow partial bids or prefer an all-in-one vendor).
Vendor Qualifications – Content Specific: When evaluating content developers, their creative and pedagogical expertise is key. In your RFP, ask for examples or case studies of similar eLearning content they have developed. You might require that bidders provide sample courses or portfolios (perhaps via links or demo access) as part of their proposal. For instance: “Please include at least 2 samples of eLearning modules you have developed, preferably on topics related to health or safety, and in Arabic if available.” This helps you gauge quality. Also consider requiring profiles of the proposed team (instructional designers, multimedia developers, voice artists etc., and language capabilities). In one anonymized tender by a UN agency, the RFP asked vendors to confirm they can provide native Arabic speakers for voice-over and instructional design review, due to the importance of linguistic accuracy.
Timeline for Content Delivery: Developing custom eLearning takes time. Outline your expected timeline or deadlines for deliverables. For example, “We expect the first module to be delivered within 6 weeks of contract, and all 10 modules completed within 6 months.” If you have key milestones (like a pilot launch or a specific event), specify them. Be realistic – high-quality content production (especially multilingual) can require iterative reviews. Build in time for your team to review storyboards, alpha and beta drafts of modules, etc. You might include in the RFP a broad schedule such as: needs analysis phase, design phase, development iterations, review cycles, and final deployment. Vendors can then propose a more detailed project plan in their response.
Example (Anonymized): A ministry of education in the Gulf planned to digitize their teacher training curriculum. They issued an RFP stating: “Development of an eLearning course library for teacher professional development, consisting of ~20 modules (~15 minutes each) across topics like curriculum planning, classroom management, and educational technology. The content exists in manuals and videos (in Arabic) which will be provided. The vendor will design interactive modules (in Arabic, with English subtitles) including animations and knowledge checks. All modules must be SCORM-compliant and compatible with the Ministry’s LMS. The project timeline is 8 months, with a pilot of 2 modules delivered in 3 months.” By clearly enumerating modules and expectations, the ministry enabled vendors to craft precise proposals. They also emphasized localization, requiring culturally appropriate graphics and regional case studies in scenarios.
Blended Project Note: If you want to procure both an LMS and content together (blended project), make sure your RFP sections differentiate the two. One approach is to allow joint ventures or partnerships – e.g. a tech firm and a content studio can partner to bid. Your RFP could state that bidders may need to demonstrate capability in both, or partner with others to cover all aspects. Evaluate each aspect on its merits (some proposals might be stronger in LMS and outsource content or vice versa). The benefit of a combined RFP is a unified solution – for example, the content developers can design courses that fit the chosen LMS’s features perfectly (using its built-in quiz engine, badge system, etc.). The downside is fewer vendors might handle both well, so be prepared to assess partnerships. Make sure to ask in the RFP for project management structure – who will be your single point of contact if multiple parties are involved.


In summary, a content development RFP should paint a clear picture of the learning materials you need, how they will be used, and the standards they must meet (educationally and technically). The more detail you provide, the more accurate and comparable the proposals will be.
Structuring Your eLearning RFP: Sections and Templates
Now that we’ve covered the types of RFPs and key content to include, let’s talk about RFP structure. A well-structured RFP document helps vendors navigate your requirements and ensures you don’t miss any critical information. While every organization might format things slightly differently, most comprehensive RFPs contain similar sections. Here we outline a typical eLearning RFP template structure, which you can adapt to your needs. Think of this as a blueprint – you can combine or rename sections as appropriate, but make sure all the core information is somewhere in your RFP.
1. Executive Summary / Project Overview: Start with a one-page (or short) summary of the project. This should cover the who, what, and why of the project in a nutshell. Include a brief background of your organization, the purpose of the RFP (e.g. “to procure an LMS for X” or “to develop online courses for Y”), and the key outcomes you seek. Mention the type of solution you’re looking for (LMS, content, or both) and any non-negotiable requirements or constraints upfront. Also state the RFP reference number (if any) and the date of issue. The summary helps vendors quickly decide if they are a fit. For example: “[Organization X] is seeking proposals from qualified eLearning solution providers to implement a cloud-based Learning Management System and develop a library of custom e-learning modules. The goal is to train approximately 2,000 staff across 5 countries in both Arabic and English. Key requirements include mobile access, integration with HR systems, and culturally localized content. This RFP provides details on scope, requirements, and submission instructions for interested bidders.” Keep this section concise and impactful – it’s like the elevator pitch of your RFP.
2. About the Organization (Background): Provide context about who you are and why this project exists. In the case of government or NGOs in MENA, you might describe your mandate or program that drives the need for eLearning. Include relevant stats like number of employees or beneficiaries, geographic spread, or current training methods. However, avoid overly lengthy history – vendors don’t need five pages of organizational history. Focus on information relevant to the project. For example, mention if you have tried eLearning before or if this is your first initiative, any known challenges (like low internet connectivity areas, or staff unfamiliar with online learning), etc. You can also describe the decision process: is this part of a larger digital transformation or a specific funded project? This background helps vendors tailor their approach. (If a detailed background is not crucial, you can merge this into the Executive Summary or an appendix. But usually, a short background section is helpful especially for unfamiliar audiences.)
3. Project Goals and Objectives: Clearly articulate what you want to achieve with the eLearning project. These are the success criteria. For an LMS: e.g. “The objective is to centralize all training on a single platform to improve tracking and access to learning.” For content: e.g. “To convert legacy training manuals into engaging eLearning to reach a wider audience at lower cost.” List out specific goals (bullet points work well). This section sets the tone for requirements – every requirement should trace back to a stated goal. It also helps internally to ensure all stakeholders agree on the goals.
4. Scope of Work and Requirements: This is the heart of the RFP, often the longest section. It can be broken into subsections for clarity:
4.a. Functional Requirements (LMS or Content): List all the features and capabilities you expect. For LMS projects, as discussed, include user features, admin features, integrations, reporting needs, etc. For content, list number of modules, interactivity level, languages, etc. It’s helpful to categorize requirements (e.g. “User Management,” “Learning Content & Delivery,” “Technical/IT Requirements,” “Content Development Requirements,” etc.) to organize this section. Use bullet points or tables for clarity. A “Must Have” vs “Nice to Have” distinction is useful here – you can explicitly label some requirements as mandatory and others as optional. This guides vendors in prioritizing their responses and pricing.
4.b. Inputs Provided: If you will provide certain materials or support to the vendor, mention it. For instance, “The organization will provide existing training manuals and raw content for conversion, access to subject matter experts for clarifications, and a test group of users for pilot feedback.” This lets vendors know what base materials they have versus what they must create from scratch. In an LMS RFP, an input might be “current user data from our HR system for import” or “branding guidelines for UI customization.” Clarifying inputs helps avoid assumptions.
4.c. Deliverables: Specify the expected deliverables from the vendor. For LMS projects, deliverables include the configured and deployed platform, admin training sessions, user guides or documentation, and support services. For content, deliverables are the developed eLearning modules (often in SCORM packages), source files, and any ancillary materials (storyboards, transcripts, etc.). Also state any acceptance criteria – e.g. “deliverables will be accepted upon our team’s sign-off after quality review and successful pilot testing.” If a pilot phase or proof-of-concept is expected before full rollout, describe it here as a deliverable (e.g. “Pilot deployment for 100 users and two sample courses, with refinements based on feedback”).
4.d. Timeline/Milestones: Although you may cover timeline elsewhere, in the scope it’s good to note any key milestones in the work. For example, “Phase 1: LMS installation and configuration – 2 months; Phase 2: Content development – months 3-6; Phase 3: Testing and launch – month 7.” A visual timeline or table can be helpful if there are many phases. In content projects, specify review milestones (alpha, beta, final for each module).
4.e. Performance Metrics (if applicable): In some RFPs, especially by large organizations, they include how the project’s success will be measured. For eLearning, this could be targets like “at least 80% of staff complete mandatory training within 3 months of launch” or system uptime requirements like “LMS availability 99% during working hours.” If you have such metrics or KPIs mandated (perhaps by a donor or law), list them so vendors know the stakes. This might also tie into SLAs (Service Level Agreements) you expect from the vendor.
5. Vendor Qualifications and Expectations: This section outlines what information you want from the bidders about themselves, and any minimum qualifications to be eligible.
Company Profile & Experience: Request the vendor to provide an overview of their company, including relevant experience. You might ask for “describe 3 similar projects undertaken, including client, scope, outcome”. Given our focus, you may insist on experience in the MENA region or developing Arabic eLearning as a plus. For example: “Vendor must demonstrate experience implementing learning platforms in a government or large enterprise context, and content development in Arabic language.” If you require local presence (some government tenders require the vendor or a partner be registered locally), state that here. Also, if consortia are allowed, indicate how they should present joint credentials.
Key Staff & Team Composition: Ask for CVs or bios of the team members who will execute the project (Project manager, LMS specialist, instructional designer, multimedia developer, etc.). For content projects, knowing the instructional design lead’s background is valuable. For LMS, an experienced technical lead is key. You can also set expectations like “The Project Manager must be fluent in English; Arabic language proficiency on the team is required for content QA.” This ensures the vendor assigns appropriate personnel.
References: It’s common to request references. For example, “Provide at least two client references for similar projects (name, organization, contact info, brief description of project).” Large organizations will likely contact these references, so vendors with a good track record will be more comfortable providing them. This can be crucial in vendor evaluation later.
Financial Stability (if relevant): Government RFPs sometimes ask for financial statements or assurances that the vendor is financially sound to complete the project. If your procurement policies need that, include it (e.g. last 2 years of audited financial statements, or a statement of solvency). This might be more relevant for huge projects or multi-year support contracts.
Compliance Requirements: If there are any specific compliance needs (e.g. “vendor must comply with local data protection law X” or “vendor should not be on any sanctions list” – relevant for NGOs/UN), list them. Also, if you require signing a Non-Disclosure Agreement (NDA) before receiving certain materials, mention that process.
6. Proposal Guidelines for Vendors: Here you explain how vendors should structure and submit their proposals. Providing a clear format ensures you can compare proposals apple-to-apple and vendors include everything you need. Guidelines to specify:
Proposal Structure: You can outline sections you expect in the vendor’s proposal. For example: “1) Executive Summary, 2) Technical Approach, 3) Project Plan, 4) Team & Experience, 5) Pricing, 6) Appendices (CVs, sample work)”. Some RFPs even mirror the requirements list and ask vendors to respond point-by-point to each requirement (this makes evaluation easier). In short, tell vendors what information to provide and in what order. Tip: Ask them to restate your requirement and then describe their solution for it – this way you see they addressed each point. The Ardent Learning team suggests including instructions like these so that all quotes are “on the same page” for equal comparison.
Format and Length: Specify if you have any page limit or format (e.g. “Max 30 pages excluding appendices, A4 size, font 11”). Also how many copies if physical, though nowadays electronic PDF submissions are common (specify email or portal submission). If you require separate technical and financial proposals, make that clear here. For example: “The proposal must be submitted in two PDF files: one Technical Proposal (no prices) and one Financial Proposal. The files should be clearly named. Technical proposals will be evaluated first, then financials of technically qualified bids will be opened.” This is a typical practice in public sector RFPs to ensure unbiased technical evaluation.
Submission Method and Deadline: State the exact deadline date and time for submission, and the method (email, online procurement system, hard copy, etc.). Include time zone (especially important in MENA where vendors in different countries might be bidding – specify e.g. “by 4:00 PM Gulf Standard Time (GMT+4) on 10 October 2025”). If submission is by email, give the email address and any instructions like subject line to use. If large files are expected, mention if multiple emails or a file share link is allowed (UN agencies often note email size limits). If via a portal, provide the link and any registration instructions.
Q&A Process: Most RFPs allow vendors to ask questions before they submit proposals. Clarify the process: “Vendors may submit questions to [contact person/email] by [date]. Answers will be compiled and shared with all bidders.” (Sharing with all ensures fairness). Provide a contact name for inquiries (and whether phone calls are allowed or only written questions). Some organizations hold a bidder conference or webinar – if you plan this, announce the date/time and how to join. For example, “An optional pre-bid webinar will be held on Zoom at [link] on 1 Sept 2025, 10:00 AM Cairo time, to clarify any questions.” Also clarify up to when questions can be asked (usually up to a week or so before the deadline).
Proposal Validity and Legal Bits: Often you should state how long the vendor’s bid must be valid (e.g. “Proposals must remain valid for 90 days from the submission deadline.”). This covers the period you’ll take to evaluate and award; the vendor shouldn’t change their pricing in that time. Additionally, include any reservation of rights (like “Issuing this RFP does not commit us to award a contract”) and mention that you may choose to award all or part of the work, or none. If you have standard contract terms or a model contract, it’s good to attach it or mention any key terms (payment schedule, etc.) up front so vendors are aware.
Checklist of Proposal Contents: It’s helpful to literally list everything a complete proposal should include. For example:
Signed cover letter on company letterhead
Technical proposal addressing Sections A, B, C…
Budget breakdown (pricing) in provided format
Vendor registration form (if required by your org)
etc.
This acts as a checklist for vendors before submission (and for you when reviewing submissions). Some RFPs put this as an annex or in a text box for clarity.
7. Evaluation Criteria: Being transparent about how you will evaluate proposals is a best practice, especially in public procurement. It also helps vendors focus on what matters to you. In this section, outline the criteria and their weights (if you use a point system). For example, you might say: – Technical Proposal – 70 points, broken down into: – Understanding of requirements & proposed solution (30 points) – Experience and past performance (20 points) – Project plan and timeline (10 points) – Key personnel qualifications (10 points) – Financial Proposal – 30 points, evaluated separately (usually the lowest bid gets full points and others are pro-rated, or another formula you use).
Whatever your system, describe it at least in general terms. If you have threshold conditions (e.g. “must score at least 50 points in technical to be considered for financial opening”), mention that. Some RFPs simply list criteria without numeric weights, e.g. “Proposals will be evaluated on: completeness, technical merit of the solution, vendor’s experience, proposed timeline, and cost effectiveness.” At minimum, list the factors. Ideally, include weights or priority to guide vendors. For instance, if quality is more important than cost, make that clear (commonly the case for specialized eLearning development – cheapest is not always best). A sample statement: “The selection will be based on the best value approach – weighing technical quality at 60% and cost at 40%. Within technical quality, approach and methodology will be given more importance than company size.” By providing this, you not only abide by fairness but also encourage better proposals targeted to what you value.
Additionally, mention if there will be presentations or interviews as part of evaluation. E.g. “The top 3 ranked bidders will be invited to deliver a live demonstration of their LMS and a Q&A session with the evaluation committee during the week of Nov 15.” Provide tentative dates if possible, so vendors can plan. Also clarify if a proof of concept or sample work is required (sometimes, for content, you might request a sample storyboard or a draft module outline to see their approach).
8. Budget and Payment Terms: Depending on your approach, you might have vendors propose a budget (common in service RFPs) or you might fix the budget. In either case, it’s wise to include a section on how to present the financials. Request a breakdown of costs – not just a lump sum. For example: – For LMS: license/subscription fees, one-time setup fees, customization costs, training, support fees, etc., over the contract period. – For content: cost per module or per deliverable, any recurring costs (like licensing stock images or voice talent), etc.
If you want pricing for multiple options (e.g. optional features or a scalable user count), indicate that structure. You can even provide a pricing table template for them to fill. Ensure the pricing is in a specific currency (USD, EUR, local currency) and whether it should include taxes/duties or not. Also mention the expected contract type – is it a fixed price contract or time-and-materials? Most RFPs of this nature will be fixed-price based on deliverables or milestones. If you plan to have milestone payments, you can outline a proposed schedule (e.g. 20% on kickoff, 30% on delivery of half the modules, 30% on completion of all modules, 20% after final acceptance – as an example).
For public entities, sometimes the RFP states that payment is only upon completion or that advance payment is not possible – include such constraints here, as it may affect vendor pricing or willingness. NGOs might mention if the project is donor-funded, any specific budget caps, or if co-financing is expected.
9. Terms and Conditions: This section might be boilerplate, but important. It can include: – Reservation of rights (as mentioned earlier, that you can cancel or not award, etc.). – Confidentiality notice (vendors should not disclose the contents of the RFP or their proposals to others). – Intellectual Property (IP) clauses: e.g. “All developed content and materials will become the property of [Your Organization] upon completion. The vendor waives rights to the content except for usage in their portfolio.” For software, if the LMS is proprietary, maybe IP isn’t transferred but ensure rights to use are clear. For custom development or configurations, clarify ownership. – Data protection: if any personal data is involved (learner info), mention that vendors must comply with data protection regulations and possibly sign data processing agreements. – Conflict of Interest declaration: some RFPs ask vendors to certify they have no conflict (e.g. not related to anyone in your org, etc. – more relevant in government). – Validity period (if not mentioned earlier). – Any standard contract or legal jurisdiction (e.g. “Any contract resulting from this RFP will be governed by the laws of [Country].”). – If you attached a Sample Contract or Terms of Reference, mention that the award will be under those terms.
Often, organizations attach their full contract terms as an Annex. If you have such, do so, or at least highlight key terms here. This avoids nasty surprises later (for both sides).
10. Appendices: You can include additional information as appendices to keep the main RFP body focused. Examples of useful appendices: – Detailed Requirements Matrix or Checklist: If too cumbersome to include inline, attach a spreadsheet or table the vendor can fill out (e.g. list of LMS features to indicate compliance). – Current State Documentation: If you have an existing system or process, you might attach screenshots or reports to illustrate what you have now. For content, maybe a sample of current training material to show complexity. – Forms for vendors to fill: Sometimes procurement requires a particular pricing template, or vendor info form (company info, signatures, etc.). Attach those for consistency. – Sample Content or Design Guide: If you have a style guide for content or any specific standards, attach them so vendors can account for them in their approach. – Glossary or Acronyms: If your RFP is heavy on internal jargon, include a glossary (though we’ve covered eLearning terms earlier in this article for you!).
By following a structured template and including the sections above, you ensure your RFP is comprehensive and clear. According to eLearning RFP experts, a good RFP “keeps all vendors on the same page” and reads as a logical story of your needs. This not only helps vendors, but also helps your evaluation team when comparing responses.
Before finalizing the document, do an internal checklist (yes, a checklist within a checklist!) to see if you answered the basic “five W and one H” questions for the project, as Paradiso Solutions suggests: Who, What, When, Where, Why, and How of the eLearning project. For example: – Who are the learners or audience? (And who internally will manage the project?) – What is the project about (LMS, content, both) and what are the deliverables? – When does it need to happen (timelines)? – Where are the learners (any geographic or language considerations)? – Why is this project being done (the problem it solves, the goals)? – How should the solution work (key requirements, technical specs)?
If your RFP addresses all of the above clearly, you’re on the right track.
To further help you, here’s a sample RFP outline in a condensed form. You can use this as a template checklist:
Sample RFP Outline (for an LMS + Content Project): – Cover Page: Project title, RFP reference, issue date, contact info. – Executive Summary: Brief project overview and request. – Background: About the organization and context. – Objectives: Goals of the eLearning initiative. – Scope of Work: – Functional Requirements (LMS features, content modules needed, etc.) – Deliverables (e.g. platform, courses, training, documentation) – Schedule/Milestones – Constraints (technical, budget, etc.) – Vendor Qualifications: Experience, team, references required. – Proposal Instructions: Format, submission method, deadline, etc. – Evaluation Criteria: How proposals will be judged (weights or descriptions). – Budget & Pricing: Info on pricing format or budget range. – Terms & Conditions: Legal and procedural boilerplate. – Annexes: (A) Detailed requirements checklist, (B) Pricing template, (C) Sample content excerpt, (D) Company information form, etc.
Using a structured outline like this ensures nothing important slips through the cracks. In RFP writing, clarity and completeness are vital – vendors should find all the info they need to decide to bid and to craft a responsive proposal.
Before release, have someone not involved in writing it (perhaps a colleague from another department) read the RFP to see if it’s understandable and if they catch any ambiguities. Sometimes internal stakeholders like IT or security should also review it to validate technical requirements wording.
Next, we’ll look at the bigger picture: the eLearning procurement lifecycle and tips on managing the process around the RFP.


The eLearning Procurement Lifecycle: From RFP to Implementation
Writing and issuing the RFP is just one step in your eLearning procurement journey. Especially for government and large organizations, a formal process governs how you go from initial idea to signed contract and beyond. Understanding this procurement lifecycle will help you plan better and set expectations with both internal stakeholders and vendors. Here’s an overview of typical stages in an eLearning procurement lifecycle:
Needs Assessment & Approval: Identify the training challenges or needs that require an eLearning solution. Build the business case internally – for example, demonstrating how an LMS will save costs or how online content will increase reach. Secure management buy-in and budget approval for the project.
Market Research (Optional RFI): As mentioned, you might issue an RFI or do informal market research to understand what solutions exist. This could involve meeting vendors, reading industry reports, or checking demos. The goal is to gather information that will inform your RFP requirements. For instance, a ministry might survey what LMS products other ministries use, or what content vendors NGOs have used in similar projects.
RFP Preparation: Draft the RFP (using guidance from this article!). Ensure all stakeholder requirements are captured – involve HR, IT, learning & development, etc., in providing input. Also plan the evaluation methodology and form your evaluation committee at this stage.
RFP Issuance: Officially release the RFP through appropriate channels. Government tenders may be posted on e-procurement portals or newspapers; NGOs might send directly to a list of pre-qualified vendors and post on their website. Make it as widely available as needed to get good competition. In MENA, consider notifying local and regional companies, and international ones if you’re open to them. (Using UNGM or other tender platforms can reach many vendors if you’re a UN/NGO).
Question & Answer Period: Manage incoming questions from vendors. As noted, best practice is to compile all Q&As and send to all potential bidders to ensure fairness. Be responsive – this is where some ambiguities can be clarified to avoid confusion later. Always stick to the communicated deadline for final questions and then issue a last Q&A addendum.
Proposal Submission & Opening: Once the deadline hits, collect all proposals. If digital, ensure you download and secure them. If sealed bids physical, you might have a formal opening (some government procurements even do public bid openings reading out supplier names and maybe prices for transparency). If you required separate technical/financial proposals, typically you open technical ones first and leave financials unopened until after technical evaluation.
Proposal Evaluation: Each proposal is evaluated against your criteria. Usually, an evaluation committee (perhaps 3-5 people) will independently score the technical section of each proposal, then convene to discuss. They might shortlist the top proposals for further scrutiny. Ensure this process is well-documented and objective – especially in government/NGO contexts where audit trails matter. Use the scoring sheet based on the criteria you gave. It helps to have a matrix where you note for each requirement whether the proposal meets/exceeds/doesn’t meet it. You may also check compliance with mandatory criteria (e.g. did they include that required certificate? If not, possibly disqualified).
Vendor Presentations/Demos: It’s common for LMS procurements to involve demos of the platform. Schedule these with top vendors. Provide a script or specific scenarios you want to see in the demo (so you can compare apples to apples). For content vendors, you might have interviews or ask them to walk through their creative process. Use these sessions to clarify any doubts about proposals. Keep it fair (all vendors get similar time/opportunity). After demos, the committee can rescore or adjust evaluations if needed.
Technical Score Finalization: Determine which proposals meet your technical quality threshold. If you set a minimum score (say 70/100), eliminate those below it. For those above, if you have weights, incorporate the financial scores now.
Financial Evaluation: If you haven’t already, open the financial proposals of the qualifying bids. Compare prices on an equal basis. Be mindful of any deviations (like one vendor proposed 3 years of license vs. others 1 year – normalize for decision, etc.). Calculate scores if using a formula. Here, your procurement rules might dictate you choose the lowest bidder among those technically qualified, or if best value, a combination of score. Typically, you’ll create a ranking of proposals from most favorable to least, based on the combined scores or overall value assessment.
Vendor Selection and Negotiation: Identify the preferred vendor (or in some cases, top 2 to negotiate further). Before announcement, you might enter negotiations to iron out details. Common negotiation points in eLearning projects: slight adjustment of scope, timeline commitments, licensing terms, pricing (if budget constraints), support terms, etc. Governments might have less room for negotiation (if the tender was very specific, you either accept or not), whereas NGOs and companies often negotiate a bit before final contract. Make sure not to deviate unfairly from original RFP – negotiations should not give an unfair advantage or change the award logic, otherwise other bidders could contest the process. Usually, you negotiate with the top choice. If that fails (unable to reach agreement), you move to the next in line.
Contract Award: Once negotiations succeed, prepare the contract. It should incorporate the RFP, the vendor’s proposal (often as an annex or by reference), and any agreed modifications. Both parties sign. At this point, formally notify the other bidders of the outcome (some orgs provide debriefs to unsuccessful vendors if requested, which can be a nice professional touch and helps them improve for future bids).
Project Kickoff and Implementation: Now the real work begins – executing the project. Hold a kickoff meeting with the vendor’s team and your stakeholders to align on scope, timeline, communication protocols, etc. This meeting revisits their proposal commitments and sets a detailed project plan. Ensure the vendor provides a project charter or plan if not already in proposal.
Project Monitoring & Change Management: During implementation, keep track of progress against milestones. Regular check-ins (weekly/biweekly) are advisable. If it’s a long project, formal monthly progress reports can be required. Manage any scope changes through a formal change request process to avoid scope creep (especially in content development where additional modules or revisions can sneak in). Also, prepare your organization for the changes – e.g. if launching a new LMS, plan user orientation, pilot tests, and marketing the new system internally. For content, gather feedback from sample learners to ensure it’s effective.
Testing and Acceptance: Before final acceptance, test everything. For LMS, do user testing – create test users, have staff try enrolling in courses, generating reports, etc. Ensure all features promised work as expected. For content, review every module thoroughly (both language versions if multilingual) for accuracy, functionality (quizzes tracking, etc.), and linguistic quality. It’s often wise to run a pilot with a small group of end-users to catch any issues. Document any bugs or fixes needed and have the vendor address them. Only sign the acceptance certificate or final sign-off when you are satisfied that deliverables meet the RFP requirements and any acceptance criteria set.
Training and Handover: Ensure the vendor has provided all required training to your administrators or instructors – e.g. training sessions on using the LMS, or train-the-trainer sessions for content if needed. Get all credentials, documentation, and source files. For an LMS, you should receive admin manuals; for custom code or configurations, get the documentation. For content, get the raw files (e.g. Storyline .story files) and any asset libraries. This ensures you are not locked out from editing or maintaining content later (important if you won’t have a long maintenance contract).
Go-Live and Rollout: Launch the solution to all users. Monitor closely in the initial period. Have vendor on standby for support during launch (often, contracts will include a hyper-care period of intense support in the first few weeks of go-live). Address any user issues or technical hiccups quickly. Gather initial usage data and feedback.
Ongoing Support & Evaluation: After launch, enter the maintenance phase. Make sure the vendor delivers support as agreed (response times, issue resolutions). You should track key metrics to evaluate success – e.g. usage rates, course completion rates, user feedback, etc. This ties back to the objectives set. It’s good to do a post-implementation review internally: did the project meet our goals? What lessons were learned? Document these for future projects.
Future Enhancements: If the eLearning initiative grows, you might already plan Phase 2 (more content, more features, etc.). Use the experience from Phase 1 and possibly engage the same vendor if appropriate or go through a new RFP if scope is substantially different. Maintain a good relationship with the vendor – a successful project can become a long-term partnership for your eLearning needs.
Throughout this lifecycle, good communication and project management are crucial. In particular, vendor evaluation (step 7-10) and vendor management post-award (steps 13-18) deserve special attention:
Vendor Evaluation Best Practices
During RFP evaluation, to ensure fairness and choose the truly best-fit vendor, consider these tips:
Use a Scorecard: Create a scorecard derived from your criteria and have each evaluator fill it independently for each proposal. This quantifies comparisons. For example, score 1-5 on each sub-criterion (e.g. understanding of requirements, methodology, relevant experience, etc.). It reduces bias by focusing on pre-set factors.
Hold Moderation Meetings: After individual scoring, meet as a team to discuss significant score discrepancies. Evaluators can explain their reasoning, and the team can agree on final consensus scores. This ensures one person’s perspective doesn’t skew results without others’ input.
Check References: Don’t skip calling the references provided by top vendors. Have a brief set of questions ready (project delivered on time? quality of work? issues faced? would you hire them again?). References can validate the claims in the proposal and sometimes reveal strengths or weaknesses (e.g. maybe a vendor’s product was good but support was slow – good to know if you choose them).
Total Cost of Ownership (TCO): When evaluating financials, consider the total cost, not just immediate price. For an LMS, a vendor might have a lower upfront fee but higher annual costs, whereas another is higher upfront but lower recurring. Calculate a multi-year cost if relevant (many do 3-5 year TCO comparison). Also factor in costs of any necessary add-ons or third-party licenses the vendor’s solution might require. If a bid looks significantly lower than others, be cautious – it could indicate they under-scoped or there might be hidden costs. It’s appropriate to ask for clarification on any ambiguous cost items during evaluation.
Quality vs. Cost: In eLearning, quality can vary widely – a cheaply made course might not engage learners, and a low-cost LMS might lack scalability or good UX. It’s often worth investing a bit more for a solution that truly meets user needs. So, your evaluation should reflect that (hence typically heavier weight on technical). If budgets are tight, you still need to ensure minimum quality. Sometimes the best proposal might exceed your budget; you can try negotiating scope or phasing to afford it, rather than just defaulting to a lower-quality option. Communicate with internal decision-makers early about this balance, so procurement rules align with getting a quality outcome (e.g. use of best value criteria instead of just lowest bidder).
Document Everything: Keep records of evaluation scoring sheets, notes from meetings, and reasons for choices. Public organizations often have to provide reports justifying the award. Even if not required, it’s a good practice. It also helps if any vendor challenges the outcome – you can show a transparent process was followed.
By rigorously evaluating vendors on how well they meet your RFP (and not just how slick their sales pitch is), you set the stage for a successful partnership.
Budgeting Models and Considerations
Budget planning for eLearning projects can be tricky for newcomers. Understanding typical cost drivers will help in both writing the RFP (to request the right pricing info) and evaluating proposals.
For LMS projects, common budgeting models include: – Subscription Licensing: Many modern LMS platforms are offered on a Software-as-a-Service (SaaS) basis, charged per user (or “per seat”) per year. E.g., $5/user/year for 1000 users. Sometimes there are tiers (e.g. 1-1000 users, 1001-5000 users, etc.). Ensure you know roughly how many users you need to budget for. Some vendors charge only active users (those who log in that year), others charge all registered users – clarify that in RFP questions. Also, ask if pricing changes with user growth and if there are any limits (like number of admins or content items). – One-Time License (Perpetual): Less common now, but some organizations, especially government, prefer to buy a perpetual license and host the LMS themselves. This usually is a large one-time cost plus annual support fees (~15-20% of license cost). If you are open to both models, have vendors quote both. – Open Source LMS with Services: There are open-source LMS options (e.g. Moodle, Totara) which are free to use, but you’d pay a vendor for customization, hosting, and support. In your RFP you can ask vendors to propose either proprietary or open-source solutions, and compare the trade-offs (open source might avoid license fees but you pay for support hours). When evaluating cost, consider the ongoing support costs for open source as analogous to subscription fees. – Implementation Services Costs: Beyond licensing, there will be costs for initial setup, configuration, and any custom development (like custom features or integrations). Often vendors will quote this as a one-time implementation fee. If you have complex needs (integration with multiple systems, unique workflows), expect this part to be higher. In your budgeting, set aside funds for implementation separate from pure licensing. – Training and Support Costs: Some vendors include admin training free, others have a fee. Similarly, basic support might be included in license, but premium support (e.g. a dedicated account manager or on-site support) may cost extra. If you expect a support contract for X years, factor that in. Government RFPs often ask for 3-5 years of support pricing upfront (which vendors might discount in multi-year deals). – Hardware/Infrastructure: If on-premise, budget for servers, IT resources to maintain. If SaaS, this is not needed, but ensure you have good internet bandwidth for users to access the cloud LMS.
For Content development projects, budgeting is often based on: – Cost per learning hour: A common industry metric – e.g. the cost to develop one hour of eLearning content. Depending on complexity, this can vary widely (basic slide narration might be $5,000 per hour of content, while highly interactive scenario-based learning with custom graphics could be $20,000+ per hour). Specify the level of complexity to get accurate estimates. Vendors often will estimate hours of work (instructional design, media, programming) and translate that to cost. – Voice-over and Multimedia costs: If courses require professional voice-over in multiple languages, that adds cost (each language VO recording, plus translation). Similarly, custom video shoots or 3D animations are high cost. If you need those, budget accordingly. If budget is limited, you might opt for simpler animation or illustration styles. – Volume discounts: If doing multiple modules, vendors might scale pricing. The first module design is usually most expensive (due to upfront style design, etc.), subsequent ones might cost slightly less if they reuse templates. – Project Management and Revisions: Ensure that quotes include time for revisions after your review. Most content development proposals allow for X rounds of revision. Clarify if extra revisions cost more. – Maintenance of content: Consider budgeting for future updates. Courses can become outdated (especially with policy or regulation changes). It might be wise to include a clause or optional item for updating the content after a year or two. Some vendors offer a maintenance rate or warranty period (e.g. free fixes for 6 months). Make sure to budget if your content will need periodic refresh (or ensure you have internal capability to edit if built in a tool you can use).
Budget Tip: It’s often better to define your scope and requirements first, get vendor proposals, and then see what the realistic costs are. If you have a fixed budget from the start (especially in NGO projects), you may need to adjust scope to fit it. Be upfront if budget is a limiting factor; vendors can propose creative solutions to meet essential needs within budget (e.g. maybe using some off-the-shelf content for less critical topics, or phasing the implementation).
Timeline Planning and Project Management
Time is a critical resource in eLearning projects. Plan your timeline with some buffers and be transparent in the RFP about any hard deadlines. Here are some timeline tips:
Use a Gantt or Schedule Table: In your planning (and possibly in the RFP), lay out a timeline with phases. E.g. RFP out in Jan, award by Mar, implementation Apr-Jun, pilot in July, full launch by Sep. This helps internal alignment and signals to bidders your expectations.
Consider Local Calendars: In the MENA region, be mindful of major events like Ramadan and Eid holidays, which can slow down work or availability. If your timeline spans these, account for potential reduced productivity during those periods (both for your team and vendor’s team). Also fiscal year-ends for government might affect availability or urgency.
Realistic Development Time: For LMS, a standard implementation might take 2-3 months if configuration only, but could be 6+ months if significant customization or if waiting on content to be ready. For content, a rule of thumb: 1 hour of eLearning content could take 4-8 weeks to develop (from analysis to final), depending on complexity and stakeholder review time. Multiply that by the number of hours of content. Of course, vendors can do some modules in parallel if they have a team, but don’t expect 10 hours of content to be delivered in 2 weeks – that would be unrealistic and likely poor quality.
Overlaps and Dependencies: Determine if content creation can happen alongside LMS setup or if one depends on the other. Often, they can overlap (LMS can be implemented while first few modules are being built). Coordinate schedules so that, say, the LMS is ready by the time the content is ready to upload and test.
Pilot and Feedback Cycles: Build in time for a pilot launch or user testing phase. For example, allocate 2-4 weeks for a pilot group to use the LMS or take some courses and provide feedback, and for you to make adjustments accordingly. It’s better to catch issues in a pilot than after full launch.
Internal Review Time: When planning content timelines, include your team’s review periods for storyboards and drafts. Your subject matter experts (SMEs) might need a week or more to review each module draft – ensure the vendor knows how long you’ll take, so they incorporate that in schedule. And ensure your SMEs are committed to those timelines to avoid delays.
Project Management: Decide who on your side will be the project manager liaising with the vendor. This person should be empowered to make day-to-day decisions or gather quick feedback to keep things moving. From the vendor side, expect a dedicated project manager; have weekly status calls or meetings to stay on track.
Agile vs. Waterfall: Some content development might be done in an agile way (iterative releases) vs. a strict linear waterfall. If you prefer one, discuss it. Agile might deliver usable chunks faster (like module by module) which could be good for phased rollout. Waterfall might deliver everything at end. For LMS, agile means maybe starting with core features then iterating with enhancements.
The timeline in the RFP doesn’t have to detail the vendor’s project plan (they will provide that), but it should communicate any fixed deadlines and the overall expected duration. Then, during implementation, hold the vendor accountable to the agreed schedule. Many contracts include penalties for late delivery – whether you include that is up to your policies, but sometimes just the knowledge that penalties could apply ensures vendors stay on schedule. If you do include such clauses (liquidated damages), make sure they are reasonable and enforceable.
Localization and Cultural Considerations
We touched on localization earlier, but let’s emphasize how important this is for MENA region eLearning projects:
Language: Arabic is a right-to-left (RTL) language, which has technical implications. Ensure any LMS chosen can fully support RTL display and Arabic text input. Many global LMS claim multi-language support but double-check Arabic specifically (and ask vendors to demonstrate it). For content, if creating Arabic modules, make sure the authoring tools or templates handle RTL alignment properly. Also consider whether you’ll provide an English version for bilingual use – many regional organizations do both Arabic and English to cover all staff or stakeholders. If French is relevant (North Africa or certain UN projects), include that as well. DigitalDefynd’s research highlights the demand for bilingual educational content (Arabic/English) in the Middle East, so plan your project accordingly if your audience includes both language speakers.
Cultural Imagery and Examples: If using stock images or characters in courses, ensure they are appropriate to the region (e.g., modest attire where relevant, relevant workplace settings). Vendors should be sensitive to local cultural norms – you can state in the RFP that content must be culturally adapted. For example, in a module about workplace conduct, the scenarios given should resonate with regional context (names, environments, etc.). Avoiding cultural mismatches will make the learning more effective and prevent offense. A good vendor might even have native Arabic-speaking designers or cultural consultants – that could be a criterion to look for.
Voice-Over Talent: If courses will be narrated in Arabic (or other local languages), insist on professional voice talent that speaks in the dialect or standard appropriate for your audience (Modern Standard Arabic is commonly used for region-wide, but if it’s a local initiative maybe a specific dialect is fine). Check if the vendor’s proposal includes narration and whether samples are available. Poor voice-over can diminish the quality greatly.
Local Support and Training: For LMS implementations in MENA, having local or regional support can be a big plus. It means the vendor can perhaps come on-site if needed, or at least operate in similar time zones, and communicate in Arabic if required for administrators. Some government tenders require the provider to have a local registered office or partner. Even if not required, vendors who understand the regional context often perform better. During evaluation, you might give some preference to those with MENA project experience or local partners, because they’ll likely be familiar with typical challenges (e.g. internet bandwidth issues in some areas, preference for certain authentication methods, etc.).
Accessibility and Inclusion: While not unique to MENA, consider if your eLearning needs to be accessible for people with disabilities (e.g. does it need to meet WCAG accessibility standards?). If you’re a government entity, this might be mandated. Ensure content has captions (especially if multi-language, maybe bilingual subtitles), transcripts for audio, and that the LMS supports screen readers etc. Also consider gender inclusivity in content if relevant (e.g. using both male and female character examples in scenarios, in culturally appropriate ways).
Testing across locales: If your audience spans multiple countries (e.g. a pan-Arab organization), test the solution in different locales – e.g. does the LMS send notifications in the right language to users based on location? Does it handle different date formats, Arabic names sorting, etc.? Little things can crop up, so ensure the vendor is prepared for a truly localized deployment.
Addressing localization thoroughly in your RFP and subsequent project will greatly improve adoption. Users are quick to disengage if an LMS interface is only in English and they’re not comfortable with it, or if course content feels “foreign.” Conversely, culturally attuned content in one’s native language greatly enhances engagement and training effectiveness.

By now, we have covered why a detailed RFP is needed, what it should contain, how to structure it, and how to carry it through the procurement process with best practices in evaluation, budgeting, timeline planning, and localization. This comprehensive approach aligns not only with eLearning industry best practices but also with modern content strategy principles (clarity, user-focus, thoroughness) which echoes Google’s emphasis on helpful, people-first content in recent search updates. In other words, just as you structure this RFP document clearly to help vendors, we structured this guide for you with clear headings, lists, and up-to-date insights to make it as useful as possible (a nod to the 2025 SEO content structuring methods).


Before we wrap up, let’s briefly address some frequently asked questions that those new to eLearning RFPs might have:
Frequently Asked Questions (FAQ)
Q1: Our organization has never done an eLearning project before. How can we estimate what we need in an RFP?
A: Start by identifying the core training problems you need to solve. Engage with potential end-users and stakeholders to gather requirements. If possible, talk to peer organizations who have done something similar. You can also issue an RFI (Request for Information) to get ideas from vendors before the RFP. Additionally, consider hiring a consultant for the RFP phase if budget permits – they can help capture technical requirements you might not think of. This guide and other resources provide templates of what a good RFP includes, so you can adapt those. Remember, it’s okay to ask vendors to propose solutions for parts you’re unsure about – a well-written RFP invites vendor creativity where appropriate (just ensure you provide enough context).
Q2: Should we include our budget in the RFP or keep it hidden?
A: There’s no one-size-fits-all answer. Including at least a budget range can ensure you get proposals that are financially feasible – vendors will tailor their solution to that range. It can prevent wasting time on proposals you simply cannot afford. On the other hand, some organizations fear that if they state a budget, all vendors will quote that amount (even if the work could cost less). In practice, reputable vendors will still break down costs and give you value for money. If you have done some research and have a realistic budget, stating it can be helpful. If you truly have no idea, you might ask for a ballpark in an RFI first, or glean from similar projects. For NGOs/donors, if budget is fixed (like a grant amount), it’s often better to be transparent so vendors can adjust scope accordingly.
Q3: How do we ensure getting apples-to-apples comparisons from vendor proposals?
A: The key is in how you structure the RFP and instructions for proposals. Provide a clear outline for responses and perhaps a spreadsheet for feature compliance or cost breakdown to standardize inputs. During evaluation, create a comparison matrix for critical points (we gave tips on evaluation above). Despite best efforts, proposals will always have differences – one might propose a different tech approach or extra features. It’s your evaluation criteria that will normalize this (focus on how well each meets your stated requirements). If something is unclear, you can seek clarification from vendors during evaluation to fill gaps. Ultimately, a solid RFP with detailed requirements and a format for responses is your best defense against wildly incomparable proposals.
Q4: We have internal disagreements on what we need (e.g. one department wants feature X, another says it’s unnecessary). How do we handle conflicting inputs in the RFP?
A: This is common in large organizations. It’s crucial to convene stakeholders before issuing the RFP to iron out differences. If compromise isn’t possible, one approach is to categorize requirements by priority (Must vs. Optional) and possibly include both viewpoints in the RFP, then decide based on vendor input/cost. For example, Department A insists on a virtual classroom feature in the LMS, but Department B says it’s not needed. You might include it as a “desirable feature” but not mandatory, and see how vendors price it. Or request it as an optional line item. Data from proposals (cost or complexity of that feature) might help your team make a final call. Also, consider phasing: sometimes you can plan to implement a core set in phase 1 and advanced features in phase 2, which can appease both sides. The RFP could then be scoped accordingly or mention future phases (though focus on current scope for evaluation fairness).
Q5: Is it better to select one vendor for both LMS and content, or separate specialists for each?
A: There are pros and cons to each approach: – With one vendor handling everything, you have a single point of accountability and potentially smoother integration of content into the platform. Coordination is easier and the vendor can tailor content to platform capabilities. Many full-service eLearning companies (like Innovito, which we’ll discuss shortly) offer end-to-end solutions. However, one vendor might not be equally strong in both areas; there’s a risk one aspect (either the LMS or the content) might not be as stellar. – With separate vendors, you can choose an expert LMS provider and a specialist content developer, getting the best of each. This might yield higher quality in each domain. But it means you (the client) have to manage two contracts and ensure the content vendor and LMS vendor collaborate (e.g. testing courses on the LMS). It can be done, but requires more project management effort on your part. There might also be “finger-pointing” if something doesn’t work (content says LMS issue, LMS says content packaging issue).
A middle ground is to hire a primary vendor (say LMS provider) who then subcontracts or partners with a content specialist, so you still have one contract. Ultimately, if you find a vendor that has proven capability in both, it can simplify things. If not, and you have capacity to manage two, that’s fine too. Consider scale: for a small project, one vendor is easier. For a very large initiative, you could even break into two RFPs (one for LMS, one for content) if different skill sets are needed and then integrate. The decision also might depend on your internal procurement rules: some agencies prefer a single procurement for simplicity, others don’t mind multiple if it gets best results. Whichever you choose, make sure the RFP (or RFPs) clearly outline responsibilities and that integration testing is included.
Q6: What if no vendor meets all our requirements or the proposals are over budget?
A: It can happen that after evaluation, you feel none of the proposals are fully satisfactory. Since an RFP is not an offer but an invitation, you generally aren’t obliged to award. You have a few options: – Negotiate scope or cost with the best candidate: Perhaps trim some non-critical requirements to fit budget, or discuss if they can enhance certain features. – Re-issue or adjust the RFP: If the issue was that requirements were unrealistic or budget too low, you might revise and go back to market (or use a negotiated procedure if allowed, with changes). This delays the project but might be worthwhile to get a better outcome. – Split the award: In some cases, you might award parts to different vendors (if your RFP allowed that). For example, one vendor for LMS, another for content, if individually they were good but none was strong in both. – Phased approach: If budget is the main issue, consider awarding a smaller initial phase (maybe just the LMS setup and a pilot content) with option for extending later if more funding comes. Some procurement systems allow framework agreements or multi-phase awards.
It’s better to have no award than to force an award to an unsuitable vendor – a failed project is worse. If you cancel or no-award, be sure to document reasons and possibly inform stakeholders that either requirements or budget need adjustment for a successful procurement next round.
Q7: How can we incorporate the latest eLearning trends (like AI, gamification, microlearning) into an RFP?
A: It’s great to be forward-thinking! When writing requirements, include any new features you’re interested in as either optional or core requirements. For example, “The LMS solution preferably should include modern features such as gamification (points, badges, leaderboards) and AI-driven personalized learning recommendations.” This signals to vendors that you value innovation. However, if you are new to eLearning, be cautious about chasing buzzwords – make sure any trend aligns with your objectives. Gamification is popular and can increase engagement (many LMS platforms in 2025 have this built-in). AI in eLearning (like AI-based content creation or chatbots) is emerging; you could ask vendors to highlight any AI features they offer (some might have AI tutors, automatic content curation, etc.). Microlearning (short bite-sized modules) is a design approach – you can mention you desire content in shorter modules for flexibility. Essentially, your RFP can encourage vendors to propose innovative approaches: “Vendors are encouraged to propose any additional features or approaches that leverage modern eLearning best practices (e.g., mobile-first content, microlearning, AI personalization, etc.) which could enhance the solution.” This leaves room for them to wow you with new ideas, beyond your listed requirements. Just ensure you still evaluate primarily on how they meet the core needs, with bonus points for innovation.
Now, with all these insights in mind, you should be well-equipped to craft an effective eLearning RFP that will yield high-quality proposals. By following the guidance above, you’ll avoid common pitfalls and impress your internal stakeholders with a thorough, professional procurement process. The final step is to consider how you will implement the project once you’ve chosen a partner. And that’s where selecting the right vendor is so important – which brings us to a brief discussion of how a company like Innovito can support you in this journey.
Innovito: Your Partner for LMS Implementation, Content Digitization & Managed eLearning Services
Crafting a solid RFP is only the beginning. Once you’ve selected a vendor, you need a team that can deliver on the vision – implementing the platform, creating engaging content, and supporting your eLearning program to ensure lasting success. This is where Innovito comes in. As a leading digital learning provider in the MENA region, Innovito offers end-to-end eLearning solutions that align perfectly with the needs outlined in this guide.
➤ LMS Implementation with Innovito: Innovito specializes in deploying next-generation Learning Management Systems tailored to organizations in the MENA and Gulf. Our flagship platform, Evolve, is an award-winning LMS/LXP (Learning Experience Platform) that combines robust LMS functionality with modern, engaging learner experiences. Whether you need a cloud-based solution or a custom LMS instance, our team handles the full implementation lifecycle – from initial setup and configuration to integration with your existing systems and data migration. We understand the local requirements deeply: for example, Evolve supports multilingual interfaces (including Arabic) out-of-the-box and conforms to regional data security standards[38]. When you partner with Innovito for LMS implementation, you get: – A platform built for engagement: Social learning features, gamification, mobile app access, and AI-driven analytics are all built into Evolve[39][40], ensuring high user adoption and impactful learning experiences. – Customization and Scalability: We can configure the LMS to your unique workflows and branding. Need a specific feature? Our developers can customize the solution (or even build a Custom LMS from scratch if required) to align with your processes. And as your user base grows, Evolve scales effortlessly, whether you have 500 or 50,000 learners. – Integration Experts: Innovito’s technical team will integrate the LMS with your HR systems, Single Sign-On, CRM, or any other enterprise software you use[41]. This means your eLearning platform won’t sit in a silo – it becomes a seamless part of your IT ecosystem. – Training and Support: We don’t just hand over the system – we empower your administrators and instructors through comprehensive training. Plus, our support team (based in the region) is on standby for any technical assistance. With local offices in Sharjah and Cairo, you can expect timely support that understands your context. We offer flexible support packages, including managed hosting, regular system health checks, and feature updates as the platform evolves.
If you’re interested in learning more about Innovito’s LMS offerings, check out our LMS implementation services page, which provides details on Evolve’s capabilities and how it can elevate your learning programs.
➤ Content Digitization and Custom eLearning Development: Innovito is not only a tech provider – we’re passionate about content. Our Innovito Convert service is dedicated to transforming your traditional training materials into interactive, engaging eLearning content[42][43]. When you have binders of manuals, PowerPoint slides from workshops, or even just ideas for training, our instructional design team turns them into immersive digital learning experiences. Here’s what we offer: – Expert Instructional Design: Our eLearning content creators work closely with your subject matter experts to design courses that meet your learning objectives. We apply best practices in adult learning and multimedia design, ensuring the content is not just accurate, but also engaging and pedagogically sound. – Multimedia Development: Need animation, video, or gamified elements? We have in-house media specialists proficient in the latest eLearning authoring tools and creative software. From scenario-based simulations to bite-sized microlearning videos, we build content in various formats (and yes, fully SCORM or xAPI compliant for compatibility). – Localization Excellence: As a MENA-focused provider, Innovito excels in bilingual course development. We develop content in English and Arabic (or other languages as required) with equal quality. Our team includes native Arabic speakers for content writing and voice-over, ensuring the localized courses feel natural and culturally relevant. We can also integrate Arabic subtitles or provide separate language versions, according to your needs. – Interactive and Blended Formats: Whether you want video-based microlearning, interactive modules with rich media, or even support for blended learning (combining online modules with live webinars or classroom sessions), we design with that in mind. For instance, we can create facilitator guides and activities to complement the eLearning pieces for a holistic blended program. – Samples and Proven Track Record: Innovito has developed hundreds of eLearning hours across topics like onboarding programs, compliance training, health & safety, product knowledge, leadership development, and more[44][45]. Our content has been used by leading organizations and NGOs worldwide (and in the region) – and we can provide sample modules or case studies similar to your project upon request. We take pride in making content that resonates with learners of all ages and backgrounds[46].
By choosing Innovito for content digitization, you ensure your learning materials will be both effective and appealing – something that traditional training alone often struggles to achieve. Visit our Custom eLearning Content page to see how we turn static content into dynamic courses and how we might do the same for your training materials.
➤ Managed eLearning Services: For many large organizations or government bodies, implementing an LMS and creating content is half the battle – the other half is running the show smoothly and continuously improving it. Innovito offers managed eLearning services that act as an extension of your team. If you don’t have a dedicated eLearning department, we can fill that gap with expertise and manpower. Our managed services include: – LMS Administration: We can handle the day-to-day management of your learning platform – user management, enrollments, permissions, generating reports, etc. You get the benefits of an in-house LMS admin team without needing to hire one. This is especially useful for organizations new to eLearning or those with limited IT staff. – Content Updates and Maintenance: Need to update courses with new regulations or fresh information? Our team can routinely update and maintain your eLearning content library. We ensure your courses remain up-to-date, relevant, and technically compatible with evolving systems. As part of our service, we monitor content effectiveness and can suggest revisions or new modules based on learner feedback and performance data. – Helpdesk and Learner Support: We can provide first-line support to your learners and instructors. For example, if employees can’t log in, or have issues accessing courses, our support channels will assist them, reducing the burden on your internal helpdesk. We offer multilingual support (English/Arabic) during regional business hours, and extended support as needed. – Analytics and Improvement: Managed services also mean we help you track the KPIs of your eLearning program. We’ll regularly analyze LMS data – enrollment numbers, completion rates, assessment scores – and provide insights. Perhaps certain courses have low completion – we’d investigate why and help adjust. Or we notice users engage more with video content – we’d recommend more of that in future designs. Essentially, we partner with you in continuous improvement of your digital learning strategy. – Scaling and New Initiatives: As your programs grow, we’ll assist in scaling the infrastructure (more users, more courses, perhaps adding an Learning Experience Platform layer, etc.). If you want to integrate new technologies (like an AI learning coach, AR/VR content, etc.), our team stays on top of eLearning innovations and can pilot these with you. Our Labs at Innovito constantly explore the latest in learning tech, so our managed service clients often get to benefit from cutting-edge solutions.
In short, Innovito can manage your eLearning ecosystem end-to-end – you get expert consultants, administrators, designers, and technologists all-in-one, supporting your mission. This allows you to focus on your core business or educational goals, while we handle the heavy lifting of the eLearning operations.
We invite you to learn more about our philosophy and offerings on our website, or reach out directly for a consultation. Innovito has spent over a decade delivering impactful digital learning experiences, fully localized for MENA but on par with global standards. We have partnered with government ministries, multinational corporations, and international NGOs, consistently achieving project success and learner satisfaction. Our approach is semi-formal and highly informative, much like this article – we communicate clearly, professionally, but also personably, bridging the gap between technical possibilities and human-centric learning.
Ready to take the next step? If you’re planning to write an eLearning RFP or embark on a digital learning project, consider Innovito as your partner. We can even assist in the RFP phase by sharing best practices (as we’ve done here) or helping refine your requirements – all with no obligation. Ultimately, our goal is to elevate learning across the region with smart, innovative solutions.
Feel free to contact Innovito for any inquiries or to discuss your specific needs. Whether you need an LMS demo, a pilot content module, or just expert advice, we’re here to help you succeed in your eLearning journey.

Conclusion: Writing an eLearning RFP is a critical step toward modernizing and enhancing your organization’s learning and development efforts. By following the guidelines in this comprehensive post, you can create an RFP that attracts capable vendors and lays the groundwork for a successful project – one that is delivered on time, on budget, and on target with your objectives. We covered the spectrum from terminology and RFP structure to evaluation, procurement process, and even post-award management. The MENA and Gulf region has unique considerations, but with careful planning and attention to localization, any organization here can leverage world-class eLearning solutions.
In the spirit of the latest best practices (in both eLearning and content SEO), remember to keep the focus on the learner’s experience and the project’s strategic goals. The RFP is not just a bureaucratic document – it’s essentially the story of your needs and a blueprint for partnership. Write it clearly, structure it well, and the vendors’ proposals will mirror that clarity.
Finally, as you venture into eLearning, know that you are not alone. Companies like Innovito are dedicated to supporting government agencies, NGOs, and enterprises in the region through every step – from ideation to implementation to ongoing success. We hope this guide has demystified the RFP process and given you confidence to move forward. Here’s to your successful eLearning project that empowers your learners and advances your mission!
For more resources, guides, and insights on eLearning and LMS in the MENA context, feel free to explore Innovito’s blog and knowledge center. And if you found this article helpful, consider sharing it with colleagues who might be embarking on a similar journey.
Good luck with your eLearning RFP – and we look forward to seeing the innovative learning experiences that result from it!