Що репетитори реально автоматизують після 10, 20 і 50 учнів
Практична maturity-model сторінка для незалежних репетиторів: що ще можна вести вручну на 10 учнях, що ламається на 20 і без чого вже не обійтись на 50.
Коротко: Репетитори автоматизують не тому, що хтось написав «треба масштабуватись». Вони автоматизують тоді, коли кожен новий етап створює новий тип адмінського болю. Близько 10 учнів зазвичай потрібна ясність. Близько 20 — винятки починають накопичуватись. Близько 50 — ти вже не просто організовуєш уроки, а оперуєш маленькою системою.
Універсального «закону кількості учнів» немає. Але повторювана maturity-модель є.
Як виглядає maturity model?
Думайте про три шари, а не про одну цифру:
| Етап | Головна задача | Що ще працює вручну | Що починає боліти |
|---|---|---|---|
| ~10 учнів | Ясність | Календар + таблиця + чат | Дрейф між вкладками |
| ~20 учнів | Координація | Дисципліна + звички | Винятки щотижня |
| ~50 учнів | Системи | Надійно — майже нічого | Пам'ять як база даних |
Назва «CRM» необов'язкова. Потреба в одній цілісній операційній моделі — ні.
Що змінюється на 10 учнях?
На 10 учнях багато репетиторів ще нормально живуть із таблицею, календарем і чатом.
Першими зазвичай починають боліти:
- видимість тижня;
- швидка відповідь на питання «хто ще не оплатив?»;
- доступ до нотаток по минулому заняттю.
На цьому етапі не потрібна велика платформа. Потрібно менше дрейфу.
Типові «автоматизації» тут легкі:
- регулярні блоки в календарі;
- одна колонка оплат у таблиці;
- проста нотатка по домашці на учня.
Цього достатньо, якщо перенесень мало, а оплата проста. Див. Why tutors don't actually need a CRM — чесний аргумент залишитись на легкому стеку.
Що змінюється на 20 учнях?
На 20 учнях проблема вже не тільки в зберіганні, а в координації.
Типові симптоми:
- make-up стають щотижневою рутиною;
- статус оплат починає «плисти»;
- запитань від батьків стає більше;
- lesson history вже важко відновити за 10 секунд.
Саме тут репетитор часто перестає потребувати просто «кращої дисципліни» і починає потребувати місця, яке тримає рухомі частини разом.
Що тут реально автоматизують:
- розклад + учень — щоб перенесений урок не «втратився»;
- статус оплат по учню — не лише загальна сума в банку;
- історія занять — щоб наступний урок не починався з археології в чаті.
Шаблони допомагають до софту: трекер оплат або політика скасувань. Софт виправдовує себе, коли шаблон стає клеєм між п'ятьма іншими додатками.
Що змінюється на 50 учнях?
На 50 учнях ручна адмінка стає операційним ризиком.
Тут уже критично важливі:
- структуроване керування розкладом;
- стабільна видимість оплат і боргів;
- повторюваний homework/progress flow;
- швидкий доступ до контексту по учню без пам'яті як бази даних.
На цьому етапі софт уже не nice upgrade, а інфраструктура.
Що ламається без системи:
- подвійні бронювання або урок «не в тому контексті»;
- пропущені оплати після завантаженого тижня;
- батьки питають те, на що ви відповідаєте через три додатки;
- вигорання від адмінки, а не від викладання.
Чого не варто автоматизувати занадто рано?
Чесний список:
- складні звіти до того, як вирівняли розклад і оплати;
- parent portal до того, як ваші записи стабільні;
- marketplace-style booking, якщо учні вже регулярні;
- зміна інструментів «бо блог сказав CRM», а не бо тиждень ламається.
Автоматизація має знімати біль, який ви вже відчуваєте — а не вигадувати нову складність.
Висновок
Поріг автоматизації — це не одна магічна цифра. Це момент, коли поточні інструменти перестають триматися синхронно без вашої постійної ручної участі.
10 учнів просять ясності.
20 учнів просять координації.
50 учнів просять системи.
Якщо ви між етапами — порівняйте чесно: When a tutor CRM is actually necessary, What we learned from tutor workflows і чи ще вистачає суворішої таблиці.
Related reading
- Why tutors don't actually need a CRM
- When a tutor CRM is actually necessary
- What we learned from tutor workflows
- The hidden cost of missed lessons
- Облік оплат репетитору