Один аккаунт-менеджер ведёт двадцать пять групп вместо пяти

Онлайн-школа IT-курсов с потоками и группами. Сопровождение обучения — расписания, напоминания, контроль посещаемости и дедлайнов, коммуникация с группами — держалось на ручной работе аккаунт-менеджеров.

Опубликовано: 2026-08-24 · обновлено: 2026-08-24

Руки заполняют бумажный месячный календарь рядом с клавиатурой — Иллюстративное фото рабочего контекста, а не снимок контура клиента

Групп на одного аккаунт-менеджера
25Было: 5
Себестоимость одного курса
−40%

Коротко

Проблема: операционное сопровождение обучения держалось на ручной работе, и рост числа курсов упирался в него первым.
Решение: правила курса как источник истины, автоматические напоминания и коммуникации по событиям, контроль посещаемости и дедлайнов, эскалация аккаунту вместо сводки.
Результат: один аккаунт-менеджер ведёт 25 групп вместо 5; себестоимость курса, по расчёту заказчика, ниже на 40%.
Системы: LMS, мессенджеры, внутренний учёт групп.

Контекст

Онлайн-школа IT-курсов; название и регион под NDA.
Объём процесса: несколько параллельных потоков, в каждом — группы со своим расписанием и дедлайнами.
Команда: аккаунт-менеджеры обучения плюс руководитель операционного блока.
Системы: LMS, мессенджеры для коммуникации с группами, внутренний учёт; часть регламентов под NDA.
Ограничение стало заметным при запуске новых программ: продажи росли быстрее, чем операционный блок успевал их сопровождать.

Исходное состояние

Исходные метрики с указанием источника. Без них любой последующий результат не с чем сравнивать.

До начала работ зафиксированы: число групп на одного аккаунт-менеджера, доля напоминаний, отправленных вручную, и время до реакции на пропуск или сорванный дедлайн.
Источник данных: внутренний учёт заказчика.
Себестоимость курса считалась по модели самого заказчика: её состав нам не раскрывался, поэтому число публикуется как расчёт заказчика, а не как наше измерение.

Диагностика

Какие гипотезы рассматривались, почему выбрали эту, какие допущения приняли и при каком условии остановились бы.

Рассматривались три гипотезы: не хватает аккаунт-менеджеров, не хватает инструментов LMS, слишком много операций требует ручного запуска.
Выбрана третья: замер показал, что основная доля времени уходит на действия, полностью определённые расписанием — то есть на то, что можно вывести из правил, а не решать каждый раз.
Допущение: правила курса можно описать формально. Проверялось на трёх программах — и на одной не подтвердилось: у неё расписание менялось по ходу, и её вынесли из первой волны.
Критерий остановки: если после описания правил доля ручных действий не падает хотя бы вдвое, автоматизация не окупает сопровождения и работа останавливается.

Что внедрили

Источники данных: расписание и правила курса, журнал посещаемости, сроки сдачи заданий, состав групп.
Бизнес-правила: событие курса → кому и что уходит. Всё описано в одном месте и доступно операционному блоку без разработчика.
Автоматизация: напоминания студентам, коммуникации по событиям, контроль посещаемости и дедлайнов, отчёт по группе.
Интеграции: LMS, мессенджеры, внутренний учёт.
Human checkpoints: аккаунт-менеджер получает эскалацию и решает сам. Отчисление, перенос дедлайна и разбор конфликта система не инициирует.
Мониторинг: доля эскалаций, закрытых без вмешательства, и время до реакции — по ним видно, работают правила или превратились в шум.

Изменение процесса

Было5

Стало6

Было

5 шагов

Аккаунт-менеджер держит расписание групп в голове и в таблице
Напоминания отправляются вручную по списку
Посещаемость проверяется, когда дойдут руки
Пропуск замечается на следующем занятии или позже
Отчёт по группе собирается по запросу

Стало

6 шагов

Правила курса описаны один раз
Напоминания уходят по расписанию
Коммуникации привязаны к событиям курса
Посещаемость и дедлайны отслеживаются автоматически
Отклонение приходит аккаунту эскалацией
Отчёт по группе доступен в любой момент

Что упиралось

Статусы групп аккаунт-менеджеры держали в голове. Каждый новый курс означал либо перегруз команды, либо потерю контроля: пропуски и сорванные дедлайны замечались задним числом, когда студент уже отставал.

1Правила курса описаны один раз
2Напоминания уходят по расписанию
3Коммуникации привязаны к событиям курса
4Посещаемость и дедлайны отслеживаются автоматически
5Отклонение приходит аккаунту эскалацией
6Отчёт по группе доступен в любой момент
Замер результата

Результаты

Групп на одного аккаунт-менеджера

5 → 255 → 25

По данным: Данные заказчика: фактическая нагрузка до и после при неизменном составе команды

Себестоимость одного курса

−40%

По данным: Расчёт заказчика по своей модели себестоимости; состав затрат нам не раскрывался

Экономический эффект

Эффект — высвобожденное время операционного блока: те же люди сопровождают в несколько раз больше групп.
Снижение себестоимости курса — расчёт заказчика по собственной модели; мы её не проверяли и не раскрываем состав затрат.
Стоимость владения: правила курса живут вместе с программой. Меняется программа — правила нужно менять следом, иначе напоминания начинают врать.

Adoption

Аккаунт-менеджеры работают по единым правилам, а не каждый по-своему.
Для студентов коммуникация стала предсказуемой: напоминание приходит всегда, а не когда о группе вспомнили.
Владелец решения — руководитель операционного блока: он же владеет правилами курсов.

«Раньше сопровождение групп держалось на ручных напоминаниях и постоянных переписках. Сейчас система сама ведёт расписания, дедлайны и коммуникации — аккаунты успевают больше и без хаоса.»

Компания под NDA — Руководитель операционного блока, EdTech (NDA)

Что дальше

Масштабирование: программы с изменяющимся по ходу расписанием — те, что не вошли в первую волну.
Следующая инициатива: раннее выявление студентов, теряющих темп, по сигналам посещаемости и сдачи заданий.
Что решили не делать: автоматически отчислять и переносить дедлайны. Решение о человеке принимает человек.

Есть похожий процесс? Проверим, переносима ли гипотеза на ваш контекст

Результат другой компании не является обещанием. Но он показывает, где искать.

Все кейсы