A Development Brief Checklist for Training Providers

What a useful training-system brief should contain

A useful training-system brief explains your provider’s goals, current processes, course and cohort model, essential workflows, users, integrations, data, constraints and success criteria. Use it as a practical document to complete and share with suppliers so they can understand how your operation works and respond to the same needs.

For each requirement, record four things:

1. What happens now? Describe the current process, including who carries it out and which tools or records they use.
2. What must the new system do? State the outcome you need, rather than prescribing a technical solution.
3. Which exceptions matter? Note where the process changes, such as a learner moving to another cohort or an instructor recording attendance after a session.
4. Is it essential or optional? Mark what the provider needs to operate, and what would be a preference if it fits the budget and approach.

Use examples from real course operations instead of broad requests such as “make the system easier to use”. For example, describe how a learner enrols, how staff confirm a place, and what happens when the course is full. This gives suppliers something specific to assess without assuming the answer must be a custom feature.

Organise the brief around the provider and its goals; current processes; courses and cohorts; enrolment, delivery and completion; users and reporting; integrations and data; operational constraints; and acceptance criteria. Add any unresolved questions or assumptions beside the relevant item. The brief is a shared starting point for discussion, not a technical specification: suppliers can help clarify scope and identify whether an existing product, a simpler process or a bespoke system is the better fit.

Describe your provider, goals and current process

Give suppliers a picture of how your training business works today and what is prompting the change. This helps them distinguish a problem with a particular tool from a process that needs to change, and identify what should remain in place.

• Describe the provider and the people it serves. Note the types of learners and customers, the courses you run, how they are delivered and the locations involved. Explain whether you mainly enrol individuals, arrange training for employers, or do both. Include differences that affect operations, such as courses delivered online, in person or through a mix of methods.
• State the business goals. Say what the proposed system should help you do better, such as coordinating course administration, giving staff a clearer view of enrolments or making information easier to report on. Separate the desired outcome from a suggested feature: explain the task or difficulty first, then note any solution you have in mind.
• List the tools and records used now. For each spreadsheet, booking tool, hosted learning platform, payment tool or manual record, describe what it is used for, who maintains it and which information it holds. Mark what may need replacing, what might remain, and what you do not yet know. Do not assume every tool needs to be combined into one system.
• Trace a typical course from start to finish. Describe who plans and publishes a course, where its details are recorded, how a learner or employer enrols, and what happens before, during and after delivery. Include how staff record attendance or assessment, confirm completion and prepare reports. Identify each hand-off: for example, who passes enrolment details to an instructor, and how that person knows about a change.
• Give concrete examples of friction. Note repeated entry of the same details, checks done manually, delays between teams, records that are hard to reconcile, or workarounds staff rely on. Explain who is affected and what task becomes difficult. Use a real example from your process rather than an unsupported estimate of the time or cost involved.
• Describe volume and variation. Give approximate volumes where you know them and explain how they vary across the year or between course types. An open-enrolment course may be administered differently from an employer cohort with a named contact and agreed attendance records. Mark unknown volumes or unclear rules as questions to resolve before suppliers estimate the work.
• Say what must stay the same. Record processes, learner or employer interactions, existing tools and reports that work well or cannot change as part of this project. For each stated need, mark whether it is essential or optional, and note any exception that could affect the proposed process.

A supplier should be able to follow your account from course planning to reporting, see where information moves and understand the reason for change. If that is not yet clear internally, mark the gaps for discussion rather than filling them with assumptions.

Set out your courses, cohorts and delivery rules

Describe the shape of your courses and the rules that make each type run differently. Suppliers need to understand not just what learners see in the catalogue, but how you create a cohort, schedule delivery and handle changes. Use the prompts below for each course type, marking every requirement as essential or optional.

• Catalogue structure: List the courses you offer and how they are organised. Do learners enrol on a standalone course, a sequence of modules, a level or a wider pathway? Note any prerequisites, optional modules or different versions of the same course. State which details staff need to maintain and which should appear to learners or employers.
• Delivery format: For each course, say whether it is in person, online, blended or self-paced. Explain whether delivery is at one location, across multiple sites or remotely. For blended courses, describe how classroom sessions, live online teaching and independent study fit together, and where learners find the materials or joining information.
• Cohort setup and capacity: Explain how a cohort is opened, who approves it and how learners are assigned. Record any minimum or maximum capacity, waiting-list process and rules for repeating sessions. Describe what happens if a cohort does not proceed, fills up or needs to be split. Note whether staff need to move learners between cohorts and what information must stay with each learner.
• Scheduling and resources: Set out how dates and times are chosen, including recurring sessions, time zones for online delivery, and how changes are communicated. If relevant, describe how rooms, equipment or online teaching resources are reserved and who can amend a booking. Include what happens when a room or resource is unavailable, a session is rescheduled or a learner needs an alternative date.
• Instructor assignment: Explain who allocates instructors and what they consider, such as availability, location, subject or qualifications. Say what information staff need to see before assigning someone, who can make the assignment and how a replacement is handled if an instructor becomes unavailable. Include any cases where more than one instructor supports a session.
• Different customer models: Separate public enrolments from employer-sponsored programmes and bespoke corporate cohorts. For each, describe who chooses the course, provides learner details, confirms places and receives updates. Note any different course content, scheduling, approval or communication process; do not assume one enrolment model covers every customer.
• Normal case and exceptions: Give a short example of a typical course setup, then list the exceptions that materially change the process. These might include a course delivered across sites, a cohort with restricted enrolment, or a change to a scheduled session. Explain what staff do now, what the system should support and what can remain a manual decision.
• Priority: Mark each requirement essential or optional, and explain the reason where the distinction may not be obvious. Identify any variation that is only a preference rather than a rule. This helps suppliers compare approaches without treating every course variation as a separate system requirement.

Where a rule is not yet agreed, label it as undecided and name who will confirm it. That gives suppliers a clear basis for their response while keeping assumptions visible.

Map enrolment, delivery and completion

Describe the training journey as a sequence of actions and hand-offs, from a learner’s first enquiry or booking to the record of completion. For each stage, note what happens now, what the system must support, which exceptions matter and whether each requirement is essential or optional.

• Enquiry and application: How does a learner find a course and express interest? Record any application questions, supporting information or approval steps. Say who reviews an application, how they decide whether the learner can proceed and what the learner is told if information is missing or the application is declined.
• Booking and capacity: Explain how a learner selects a course, session or cohort, and how available places are checked. Note whether staff can make bookings on a learner’s behalf, whether a manager or employer must approve them, and what happens when a course is full. Include waiting-list handling only if you use it: who offers a place when one becomes available, and how the offer is accepted or expires.
• Booking changes: Describe how cancellations, transfers, substitutions and changes to a booking are requested and approved. Identify who updates the learner’s record and any related cohort list, instructor information or communications. Include the exceptions that affect your operation, such as a learner moving to another cohort or an employer replacing a participant.
• Information collected: List what you collect at enrolment, who needs to see it and at what point. Distinguish information supplied by the learner from details entered by staff or an employer. Explain whether an individual booking and an employer booking for a group follow different steps, and how staff identify which learners belong to each group booking.
• Communications: Set out what learners, instructors and relevant staff need to be told before, during and after delivery. For each message, record the event that prompts it, who is responsible for sending it and whether staff must review or act first. Consider booking confirmation, joining or session information, changes to delivery, reminders and completion outcomes where these apply. Note what should happen if a message needs correcting or a recipient changes.
• Attendance and participation: Explain how attendance is recorded for classroom sessions, online delivery and any blended course. Say who records it, when it is entered and how the record is linked to the learner and session. Specify how staff handle relevant exceptions, such as late arrival, an authorised absence, a learner attending a different session or an attendance record being disputed.
• Learning and assessment: List what learners and instructors need to access, such as learning materials, session information, progress records, quizzes or assessments. Describe when access is provided and who can update or review progress. If assessment is part of the course, state who sets or marks it, how results are recorded and what evidence needs to be kept. Distinguish the process you require now from features that would be useful but are not essential.
• Completion: Define the steps that count as completing a course. Include any attendance threshold, required learning activity, assessment result, resit or evidence review that your process uses. Say who confirms completion, what record is created and whether a certificate or other completion document is issued. Identify who can correct a result or completion record and how that change is handled.
• Delivery changes: Describe what staff do if an instructor becomes unavailable, a session changes or a course is cancelled. Note who makes the decision, how affected learners and instructors are identified, and what needs updating in the schedule, attendance records and communications. Separate changes the system must help staff manage from unusual cases that can remain manual.

To check that the steps fit together, include one or two representative learner journeys. For example, trace an individual booking from application through attendance and completion, or follow an employer group booking where a participant is replaced. At each hand-off, name the person or role responsible, the information they need and the next action. This helps suppliers spot missing decisions and exceptions without prescribing a technical design.

For every item, label it essential if the process cannot operate without it, or optional if it would improve the experience but could be deferred. If a rule varies by course or customer, state the variation rather than presenting it as universal.

Define users, commercial workflows and reports

Specify who needs to use the system, what each person must do and how commercial activity relates to enrolment and course records. This helps suppliers distinguish access needs from business processes, and identify which reports should support a real decision rather than simply reproduce existing paperwork.

1. List the roles. Include the roles that apply to your organisation, such as learners, instructors, programme administrators, employer contacts, finance staff and managers. Note whether a person may hold more than one role, and whether access differs between courses, cohorts or employers.
2. Describe each role’s view and actions. For each role, write down what information the person needs to see and what they need to do. For example, an instructor may need a list of learners assigned to a session and a way to record attendance; an employer contact may need to nominate learners or check participation; an administrator may manage enrolments and course records. These are prompts, not assumptions about the functions your system must provide.
3. Set boundaries around information. State what a role should not be able to view or change, and explain any differences between internal staff, learners and external contacts. Identify information that needs to be kept separate between employers or cohorts. If the current process relies on staff forwarding files or maintaining separate records, describe where that happens and what could go wrong.
4. Map the commercial workflow where it applies. Explain who pays and how the arrangement works: for example, individual payment, instalments, a subscription, a course bundle, employer invoicing or purchase-order handling. Describe the hand-off between the person arranging a place, the person authorising or making payment, and the staff member confirming the enrolment. Note which steps are manual today and which should change.
5. Explain how payment status affects course activity. Say whether payment status should affect enrolment, access to learning materials, cancellation or completion records, or whether staff handle these decisions separately. Describe exceptions such as an employer-funded place awaiting approval, a payment that needs checking, or a learner changing course. Mark which cases the system must support and which can remain a staff process. Do not assume a particular payment function is needed.
6. Choose reports by the decision they support. For each report or view, record who uses it, what they need to decide and when they need the information. Depending on your operation, examples might include capacity planning, attendance follow-up, completion monitoring, assessment outcomes, revenue tracking or employer participation. Include only the information relevant to your courses and management decisions.
7. Identify manual collation. List information staff currently gather from spreadsheets, booking tools, learning platforms, finance records or email. Say how often they need it and what they do with it. Then decide whether the new system must produce a report, provide a view of the underlying records, or leave the existing process in place. This can prevent a request for a polished report when the real need is reliable access to source information.
8. Set priorities and exceptions. For each role, workflow and report, state the current process, desired outcome, important exceptions and priority. Label it essential, optional or suitable for a later phase, and explain the consequence if an essential need is not met. Where a preference could be handled by changing a process, say so. Suppliers can then respond to the actual operating need rather than treating every suggested feature as mandatory.

Use this information to compare proposals: ask suppliers to explain how they would handle the stated workflows, what assumptions they have made and where a simpler process or existing tool could meet the need.

List integrations, data and transition needs

List the systems and records that the new arrangement must connect to, retain or replace. For each item, record what happens now, what needs to happen in future, who can confirm the details and whether it is essential or preferred.

• Systems and hand-offs: Name each booking, learning, finance, communication or reporting tool that must connect or remain in use. Describe the information or action that needs to move, in which direction, and at what point in the workflow. For example, note whether an enrolment should create a learner record elsewhere, or whether a completion result must return to a separate record system. Mark the connection as essential or a convenience, and note the system owner or supplier contact if known.
• Data to carry forward: List the records that may need to move, such as course and cohort details, learner profiles, enrolments, attendance, assessment outcomes, certificates and payment history. For each type, say whether it is needed for current delivery, historical reference, reporting or not yet confirmed. Identify duplicate records, inconsistent formats, missing fields or other known quality concerns rather than assuming the data is ready to import.
• Ownership and access: Record who administers each current system and who can approve or arrange access to its data. Note what export options, field descriptions or other information you still need to confirm with the existing supplier. Flag unanswered questions for follow-up; do not treat assumed access or undocumented data as settled.
• What must continue during transition: Describe live cohorts, upcoming bookings, scheduled communications and staff tasks that cannot simply stop while systems change. Say which records staff need to consult during the change, who will handle changes to bookings or learner details, and how learners and instructors should receive updates. Include any overlap between old and new processes that the supplier needs to plan around.
• Migration checks: Ask suppliers to state what they assume about the source data, what they expect your staff to prepare, and who will check that transferred records are complete and usable. Ask how missing, duplicated or inconsistent information would be identified and reported, and how you can review representative records before relying on the new system. Separate the supplier’s proposed approach from decisions your provider still needs to make.

Share uncertainties alongside confirmed requirements. This gives suppliers a basis for identifying dependencies and proposing a transition approach, without implying that every historical record or existing connection must be carried forward.

Record constraints and define what success looks like

Give suppliers the boundaries they need to propose a workable solution, then define how you will decide whether it meets your essential needs. Keep requirements specific enough to discuss and test, while marking assumptions and unresolved questions rather than presenting them as settled.

• Project boundaries and dependencies. State what is included and excluded, which existing tools or processes must remain, and what depends on another supplier, internal decision or piece of work. Name the people who will approve requirements and decisions, and describe the time your staff can contribute. Note dates, events or operational periods that may affect planning, without asking suppliers to infer a delivery estimate.
• Accessibility and usability. Describe who needs to use the system and any practical needs that affect their ability to do so. For example, explain whether learners or staff need to navigate tasks without a mouse, use assistive technology, or access captions and clearly structured course materials. Ask suppliers how they will address these needs and how you can review the result. Ask suppliers which accessibility standards or guidance they propose to follow and how you can review their approach.
• Security, privacy and operations. Set out the security and privacy requirements you need to discuss, including who should be able to access learner, staff and course records, and how access should change when someone changes role or leaves. Describe your expectations for support, maintenance, service continuity and performance in operational terms. Ask suppliers what they assume, what is excluded and what ongoing work your staff would need to manage. Treat these as scoping questions, not a substitute for advice from your relevant specialists.
• Internal input still needed. List information or confirmation that must come from your finance, operations, IT, data or learning teams, as well as from existing software suppliers. Identify the owner for each answer and whether it is confirmed or still an assumption. This helps suppliers distinguish a settled requirement from a dependency that could change scope.
• Essential outcomes and preferences. Mark each requirement as essential or optional, and state why it matters. For each essential item, describe how you will assess it. Avoid phrases such as “easy to use” on their own; specify the task and the person completing it. For example, a named staff role can find a learner’s enrolment and record attendance for the correct session.
• Acceptance and exceptions. Define observable outcomes for representative workflows, including relevant exceptions. Explain what information should be present, what action the user takes and what result confirms the task is complete. Consider cases such as a changed booking, a missed session or a correction to a record. Agree with suppliers how these scenarios will be reviewed and what evidence you will use to accept the work.
• Questions for suppliers. Ask them to identify assumptions, exclusions, dependencies and unresolved decisions in their response. Ask how their proposal handles the exceptions you have listed, what migration or ongoing support includes, who owns the system and its associated materials, and what responsibilities remain with your provider. Compare responses against the same essential outcomes, not just against a list of features.

Decide whether to adapt existing software or build

Use the same checklist to compare a process change, an established product, configuration of existing software and custom development. Start with the essential workflows and constraints; do not assume that a custom build is the right answer simply because your current tools are awkward.

• Check whether the process needs to change. Identify steps that could be simplified, removed or handled consistently before asking software to reproduce them. Note who would need to approve a change and what must remain as it is.
• Assess established products. Ask suppliers to show how a product would handle your essential course, cohort, enrolment and completion workflows. Record where the product fits, where it does not, and whether changing your process would be acceptable.
• Consider configuring what you already use. Where the core workflow fits, document the configuration needed and any gaps. Ask what workarounds staff would have to use, what other systems or manual steps would remain, and how future changes could affect the setup.
• Consider custom development where important needs remain unmet. This may be worth scoping when essential workflows or rules cannot be handled adequately by changing the process or using existing software. Be ready to define those requirements, decide who owns the decisions and plan for ongoing maintenance and support.
• Compare options against the same questions. For each option, record whether it covers the required workflows and exceptions, handles the data and migration needs, connects to required systems, fits your operational constraints, and can be tested against your acceptance criteria. Include the ongoing support arrangements and any assumptions or exclusions.
• Ask suppliers to separate fit from preference. Invite them to explain what they would configure, build or recommend changing. Ask them to identify gaps and assumptions clearly, rather than treating every requested feature as essential. Compare their responses against your priorities, not just the number of features proposed.

If custom development appears to be a suitable option and you are ready to discuss your requirements, Request a project quote. It is one route to explore, not a substitute for assessing whether a simpler process or established product will meet your essential needs.