Capability template for IT and systems
Online class setup packet
The learning-platform administrator receives one complete request for an approved class: course name, section, room, responsible teacher, the people who can be invited and every roster exception, drawn from the approved details and the roster export.
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
Setting up an online class stops being a chain of emails. The administrator opens one page and sees what the class is, who is responsible for it, who is cleared to be invited and which names need a person to settle before anything happens. The questions that usually surface halfway through setup, such as a teacher nobody has confirmed, a student listed twice or a status that says nothing, are already on the page with the facts.
The administrator still checks ownership and membership, creates the class and approves the invitations. The packet creates nothing and invites nobody.
Who starts the work, and when
The academic office or the registrar's assistant starts it once a class is approved and its roster export is available, and hands the packet to the learning-platform administrator. It is run again when the roster export changes before the class opens.
What they supply
- The approved class details: course code and name, section, term, room, meeting pattern, enrolment cap, the platform template to use and the approval reference.
- The teacher assignment, showing who is confirmed.
- The roster export the office already keeps, with its default column headers.
- The authorized invitation list: the people the school has cleared to be invited.
- Optionally, the statuses your office counts as enrolled, if they differ from the default.
What comes out
One packet in a fixed order: the class request, the responsible teacher with confirmation status, counts that add up, the list of people who can be invited, numbered roster exceptions and the decisions left to the administrator. If an input does not match, the work stops and says which one and why.
An invented example
Illustrative example with invented data. An invented training college, its invented staff and invented students. The inputs the academic office supplies come first, then the packet prepared from them.
What the academic office supplies
Approved class details (approval note AC-2027-0143, approved by the dean's office on 2 November 2026)
- Course code: BUS 214
- Course name: Small Business Bookkeeping
- Section: 02
- Term: Spring 2027
- Room: C112
- Meeting pattern: Tuesday and Thursday, 18:00 to 19:30
- Enrolment cap: 8
- Responsible teacher: Ms Ardell
- Platform template: Evening course standard
Teacher assignment
Staff ID, Name, Course Code, Section, Role, Confirmed
T-0412, Ms Ardell, BUS 214, 02, Teacher, Yes
T-0455, Mr Brandt, BUS 214, 02, Teaching assistant, No
Roster export (default headers)
Student ID, Family Name, Given Name, Course Code, Section, Enrolment Status
S2041, Quill, Imani, BUS 214, 02, Enrolled
S2044, Reddan, Tomas, BUS 214, 02, Enrolled
S2049, Ferrante, Lucia, BUS 214, 02, Enrolled
S2052, Pell, Owen, BUS 214, 02, Enrolled
S2057, Nandakar, Priya, BUS 214, 02, Enrolled
S2063, Wirth, Jonas, BUS 214, 02, Enrolled
S2064, Wirth, Jonas, BUS 214, 02, Enrolled
S2070, Haskett, Mira, BUS 214, 02, Waitlisted
S2075, Sollis, Ahmed, BUS 214, 02,
S2080, Bellamy, Noor, BUS 214, 01, Enrolled
Authorized invitation list (IDs): T-0412, T-0455, S2041, S2044, S2049, S2052, S2063, S2070, S2090.
Settings: a status of "Enrolled" counts as enrolled; no other status does. Who holds each kind of answer: the department or academic lead settles teacher assignments; the registrar settles roster and status questions; the office that authorizes invitations settles the authorized list.
The packet
ONLINE CLASS SETUP PACKET: BUS 214 Small Business Bookkeeping, section 02
For: Learning-platform administrator. Prepared from the approval note AC-2027-0143, the teacher assignment, the roster export (10 rows) and the authorized invitation list. Draft for the administrator's verification. Nothing has been created or sent.
Class request: Course name: Small Business Bookkeeping. Course code: BUS 214. Section: 02. Term: Spring 2027. Room: C112. Meeting pattern: Tuesday and Thursday, 18:00 to 19:30. Enrolment cap: 8. Platform template: Evening course standard. Approval: AC-2027-0143, dean's office, 2 November 2026.
Responsible teacher: Ms Ardell, T-0412. Confirmed: Yes, in the teacher assignment.
Roster counts: Export rows 10. Set aside as another section: 1. Rows for this section: 9. Enrolled: 7. Waitlisted: 1. Status blank: 1. Repeated rows (counted once): 0. Enrolled and held out of the invitation list: 3. Enrolled and listed: 4. Enrolled is within the cap of 8.
Settings used: "Enrolled" counts as enrolled (as supplied); a class over its cap is an exception (default, since no cap rule was supplied); who holds each answer is as supplied.
People who can be invited (enrolled, on the authorized list, no open exception): 5
- T-0412 Ms Ardell, teacher
- S2041 Quill, Imani
- S2044 Reddan, Tomas
- S2049 Ferrante, Lucia
- S2052 Pell, Owen
Roster exceptions: 6
- Teacher or staff: T-0455 Mr Brandt, teaching assistant, Confirmed: No, and on the authorized list. Not listed.
- Duplicate identity: S2063 and S2064 both read Wirth, Jonas, both Enrolled in section 02. The authorized list has S2063 only. Neither is listed.
- Enrolled, not authorized: S2057 Nandakar, Priya. Not on the authorized list. Not listed.
- Not enrolled, authorized: S2070 Haskett, Mira, status Waitlisted. Not listed.
- Status unclear: S2075 Sollis, Ahmed, status blank. Not on the authorized list. Not listed.
- Authorized, not on roster: S2090. No row in the export. Not listed.
Set aside: S2080 Bellamy, Noor is on the export but in BUS 214, section 01. Not part of this packet.
For the administrator to verify: (1) Ownership: the teacher named in the approval note, Ms Ardell, matches the confirmed row for T-0412. (2) Membership: 4 of the 7 enrolled students can be listed; the 3 held out are exceptions 2 and 3. (3) Template: Evening course standard, as named in the approval.
Decisions for the administrator or the academic office: 6
- Will the department or academic lead confirm Mr Brandt's teaching assistant assignment?
- Which ID is Jonas Wirth's: S2063 (the one authorized), S2064, or are they two people? The registrar holds the answer.
- Is S2057 Nandakar, Priya to be added to the authorized list, given the roster shows the student as Enrolled? The office that authorizes invitations decides.
- Is S2070 Haskett, Mira, Waitlisted, to stay on the authorized list? The office that authorizes invitations decides.
- What is S2075 Sollis, Ahmed's enrolment status? The registrar holds the answer.
- Is S2090 a roster omission or an error on the authorized list? The registrar and the authorizing office decide.
Every figure and name traces to the approval note, the teacher assignment, the roster export, the authorized list and the settings supplied. The packet creates no class, creates no account, invites nobody and changes no record.
Where it fits
- IT and systems, where the administrator receives class requests that arrive piecemeal and incomplete.
- Executive and office support, where an academic office assembles the approved details and the roster.
- Education, where schools, colleges and training providers open classes every term.
- Government, where public training bodies and agencies run classes for staff or the public.
- Established businesses, where the same work repeats every term and a fixed packet saves the retelling.
What has to change for your company
Use your own column headers for the roster and teacher files, or rename the defaults once. Decide which enrolment statuses count as enrolled. Name the platform templates you use so the packet can name the right one. Decide whether a class over its cap is an exception or only a note, and who may approve an invitation list. Keep the roster to what the office already holds: the packet needs a student number and a name, not contact details, grades or notes.
What has been checked
Fully Powered AI wrote this capability template. It was editorially reviewed on 10 November 2026. It was tried once on its invented example in Claude on 10 November 2026; the record is published with it, and lists the points where the instructions were ambiguous. Edits made afterward to settle those points, and to add two parts to the output format, have not been run again; the trial record lists them. It has not yet been tested in a client environment. It has not yet been tested as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on a class the administrator has already set up by hand, plus hard cases written in advance: a teacher not yet confirmed, a student listed under two numbers, a blank enrolment status, a name on the invitation list who is not on the roster, a header that does not match. The administrator checks every line against the approval and the export before anyone relies on the packet. Pilot acceptance-test preparation sets those cases up, and what we test before we call an AI workflow ready describes the record we keep.
The full capability template
Everything above is the outline. The complete capability template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this capability to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this capability template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: