Supporting a cohort when you are the whole team
Support load is not proportional to cohort size. It is proportional to how unclear the course is, which means most of it is preventable.
One person running a course absorbs every question, every access problem, every payment query and every learner who has gone quiet. It is the part of the work that is invisible in any plan and consumes the most unplanned hours.
The instinct is to become more efficient at answering. The larger win is to receive fewer questions.
For a broader operations parallel, workforce optimization software looks at using workload data to adjust capacity and process rather than simply count hours.
Most questions are a defect report
Categorise a cohort's questions and the pattern is stark: the majority cluster on a small number of points, and each cluster marks something ambiguous in the material, an instruction that does not work, or a step that assumed knowledge nobody had.
Answering them individually treats the symptom every cohort. Fixing the underlying point removes the question permanently. Keeping a tally of which question was asked how many times is what turns support load into a prioritised fix list.
For general operational guidance relevant to small organisations, the U.S. Small Business Administration provides public business resources.
A question asked by six people is not six support requests. It is one defect, and fixing it is cheaper than answering it six times per cohort forever.
Answer in public and keep the answer
A private answer helps one person. The same answer posted where the cohort can see it helps everyone who had the question and did not ask, which is usually more people than asked.
Better still, move the good answers into a growing per-module question page. After two or three cohorts that page absorbs a large share of what previously arrived as messages.
Batch it, and say when
Support handled continuously fragments the whole day and makes deep work impossible. Two fixed windows a day, with a published response time, delivers a better experience than sporadic instant replies followed by silence.
Learners are content with a stated turnaround. What produces anxiety and repeated messages is not knowing whether an answer is coming.
Separate the categories
- Content questions — the teaching, and the only category that genuinely needs the instructor.
- Access and technical — logins, payments, downloads. Largely solvable by a short setup guide and a checklist, and largely repetitive.
- Administrative — dates, deadlines, certificates. Should be answered by the course pages, not by a person.
- Pastoral — falling behind, personal circumstances, whether to continue. Needs a person, and needs a considered response rather than a fast one.
The middle two are where most of the volume is and where nearly all of it is preventable by better documentation.
Set boundaries and publish them
A single instructor cannot be continuously available, and an unstated boundary becomes an expectation of constant availability that eventually fails badly.
State support hours and response times at the start. This is not a reduction in service; it is the difference between a service that is described accurately and one that is described optimistically and then withdrawn under load.