Разговор почти всегда начинается одинаково. Сеть из трёх-пяти языковых школ, полтысячи учеников, две готовые CRM перепробованы и отвергнуты: одна «не так считает зарплату преподавателям», вторая «не умеет наш формат абонементов с заморозкой и переносом». Дальше владелец открывает поиск и вбивает что-то вроде «система управления для языковой школы на заказ». И получает коммерческие предложения, в которых написана ровно одна цифра — стоимость разработки.
Эта цифра почти всегда честная. И почти всегда — не та, по которой принимают решение.
Ниже — арифметика на три года: что входит в смету, что в неё не входит, и в каких случаях заказная платформа действительно оказывается дешевле. Спойлер: такие случаи есть, но их меньше, чем кажется на этапе «нам нужны две настройки, которых мы не нашли».
Откуда берётся идея «закажем своё»
Идея редко приходит от жадности до технологий. Она приходит от усталости.
Типичный сценарий: школа выросла с одного кабинета до четырёх филиалов. Абонементы к этому моменту обросли исключениями — перенос занятия, заморозка на время болезни, семейная скидка со второго ребёнка, отдельная логика для корпоративной группы. Зарплата преподавателя английского считается не по одной формуле, а по трём: часовая ставка новичку, ставка плюс процент от наполняемости опытному, отдельный тариф за индивидуальные. Всё это годами жило в голове владельца и в файле Excel, который правил один человек.
Когда такую школу пробуют перенести в готовую систему, случается стык. Система умеет 90% процессов, а оставшиеся 10% — те самые, которые владелец считает своим ноу-хау. И вот здесь развилка: либо разбираться, как эти 10% ложатся на существующие настройки, либо решить, что систему проще написать под себя.
Второй вариант психологически комфортнее. Он не требует признавать, что «уникальный процесс» может оказаться просто непривычным интерфейсом. Он даёт ощущение контроля: платформа будет наша, исходники наши, захотим — переделаем.
Ощущение контроля — реальная ценность. Просто она стоит денег, и вопрос только в том, сколько именно. Если вы ещё на стадии выбора и не решили окончательно, сначала имеет смысл пройтись по обзору готовых систем для учебных центров — иногда «такого никто не умеет» рассыпается на первом же демо.
Свежие цифры рынка — в почту
Один разбор и обновлённые бенчмарки раз в две недели. Отписаться можно из любого письма.
Нажимая «Подписаться», вы соглашаетесь с политикой конфиденциальности и получением писем от BigBen CRM.
Из чего складывается смета и что в неё не входит
В коммерческом предложении на разработку обычно есть четыре строки: аналитика, дизайн, разработка, тестирование. Всё вместе даёт срок в месяцах и сумму. Это добросовестная оценка работы до момента сдачи.
Проблема в том, что языковая школа покупает не момент сдачи. Она покупает систему, которая должна работать в сентябре следующего года, когда придёт новый набор, поменяется расписание, а бухгалтер попросит выгрузку в новом формате.
Вот что почти никогда не попадает в смету:
- Поддержка после сдачи. Не «исправление багов по гарантии» — это обычно есть, — а живая работа: обновить зависимости, починить упавшую интеграцию, поднять сервер в субботу вечером, когда родители не могут оплатить абонемент.
- Доработки под изменения. Школа меняется быстрее, чем кажется. Новый филиал, новый формат «онлайн + офлайн», новая система лояльности. Каждое изменение — задача разработчику, и она оплачивается по часам сверх сметы.
- Интеграции. Эквайринг, онлайн-касса, СМС-шлюз, переписка с родителями в мессенджерах. Каждая — отдельный протокол, отдельные ключи, отдельная логика повторных попыток. И каждая ломается, когда провайдер меняет API.
- Соответствие закону. Персональные данные учеников, часть из которых несовершеннолетние. В своей платформе на вас ложатся не только организационные меры, но и техническая часть: разграничение прав, журналирование доступа, шифрование, уведомление Роскомнадзора об инциденте в течение суток (ч. 3.1 ст. 21 152-ФЗ). Подробнее — в разборе того, как 152-ФЗ ложится на школу.
- Инфраструктура. Сервер, домен, сертификаты, резервные копии, мониторинг. По отдельности копейки, суммарно — постоянная строка расходов, которой у вас раньше не было.
Ни один из этих пунктов не является обманом со стороны подрядчика. Просто КП описывает разработку, а вы покупаете владение. Это разные вещи, и считать их надо по-разному.
Сколько стоит владение на горизонте 3 лет
Дальше — калькулятор. Он не пытается доказать, что заказная разработка — плохо. Он раскладывает обе модели по годам, чтобы вы увидели, где именно они расходятся и наступает ли вообще точка безубыточности на вашем масштабе.
Подставьте свои цифры: число филиалов, учеников, ставку разработчика из полученного КП, обещанный срок и цену лицензии готовой системы.
Калькулятор стоимости владения на 3 года
Заказная платформа против готовой CRM: сколько уйдёт по годам и когда своё начнёт окупаться
| Год | Своя платформа | Готовая CRM | Разница |
|---|---|---|---|
| Год 1 (разработка и запуск) | -- | -- | -- |
| Год 2 (эксплуатация) | -- | -- | -- |
| Год 3 (эксплуатация) | -- | -- | -- |
| Итого за 3 года | -- | -- | -- |
Модель считает разработку как 160 часов в месяц на 1,5 специалиста (бэкенд плюс частично фронтенд), закладывает 30% типового перерасхода срока, 20% от стоимости разработки в год на поддержку и доработки, инфраструктуру 6000 ₽ в месяц плюс 1200 ₽ на филиал и разовые интеграции (эквайринг, касса, мессенджеры) в размере 15% от разработки. Для готовой CRM — лицензия плюс разовый перенос данных и обучение команды в первый год, далее индексация 8% в год. Цифры — рамка для разговора с подрядчиком, а не оценка конкретного КП: подставьте свои.
Обратите внимание на строку «Год 1». У большинства сетей до пяти филиалов она отличается не на проценты, а в разы. И это ещё оптимистичный расчёт: он не учитывает, что первые полгода школа живёт в двух системах сразу, потому что новую нельзя включить одномоментно.
Если после калькулятора цифры выглядят подъёмными — сверьте их с реальной экономикой школы через калькулятор рентабельности. Бюджет на разработку берётся не из воздуха, а из той же прибыли, из которой платят преподавателям.
Риск, о котором не пишут в КП: разработчик уходит
Это главный риск заказной платформы, и он не финансовый. Он организационный.
Готовую CRM пишет команда. Человек уходит — на его место садится другой, потому что код общий, документация есть, а продукт живёт независимо от конкретного сотрудника. Заказную платформу для школы пишет один разработчик или маленькая студия. Через два года этот человек может уйти в найм, сменить стек, поднять ставку втрое или просто перестать отвечать.
Дальше начинается то, что владельцы описывают одинаково: система работает, но её никто не понимает. Новый подрядчик смотрит код и говорит, что проще переписать. И он часто прав — не потому что предыдущий писал плохо, а потому что чужой код без автора всегда разбирают дольше, чем пишут свой.
Три вещи, которые снижают этот риск и которые надо требовать до подписания договора, а не после:
- Исходники в вашем репозитории с первого дня. Не «передадим по окончании» — с первого коммита, на вашем аккаунте.
- Документация как часть приёмки. Схема базы, описание интеграций, инструкция по развёртыванию с нуля. Проверяется одним способом: сторонний человек поднимает копию по документу и не звонит автору.
- Стек без экзотики. Чем скучнее технологии, тем проще найти замену. Оригинальный выбор фреймворка — это удобство подрядчика, а не ваше.
Ни один из трёх пунктов не спасает полностью. Они переводят риск «система умерла вместе с разработчиком» в риск «на замену уйдёт два-три месяца и деньги». Это уже управляемо.
Две модели по осям решения
Сравнение без цифр — по тому, как эти два варианта ведут себя в реальной жизни школы.
| Ось | Заказная платформа | Готовая CRM |
|---|---|---|
| Срок до запуска | 6-12 месяцев по КП, на практике дольше: аналитика и приёмка съедают время владельца | 2-6 недель: перенос данных, настройка абонементов, обучение администраторов |
| Стоимость года 1 | Пик расходов: разработка, интеграции, инфраструктура, параллельная работа в старом учёте | Лицензия плюс разовый перенос данных и обучение |
| Стоимость года 3 | Поддержка, доработки, серверы. Ниже года 1, но не исчезает никогда | Лицензия с индексацией. Новые функции приходят без вашего бюджета |
| Уход разработчика | Критический риск: система работает, но развивать её некому | Вас не касается — продукт живёт независимо от конкретного сотрудника |
| Кто чинит в субботу | Тот же один разработчик, если возьмёт трубку. Дежурство — отдельный договор и отдельные деньги | Поддержка вендора по регламенту, мониторинг и резервные копии на стороне провайдера |
| Интеграции | Каждая пишется и поддерживается за ваш счёт, включая ремонт после смены API у провайдера | Готовые модули: эквайринг, касса, мессенджеры, телефония. Обновляются вендором |
| Соответствие 152-ФЗ | Оператор ПД — вы, техническая защита тоже на вас: права, журналы, реакция на инцидент | Оператор ПД по-прежнему вы, но техническая часть и хранение — зона ответственности вендора |
| Уникальные процессы | Реализуются буквально так, как вы описали | Реализуются настройками. Если настройки не хватает — доработка вендора или отказ |
Последняя строка — и есть развилка. Всё остальное в таблице говорит в пользу готовой системы, и только она одна может перевесить всё сразу. Вопрос в том, насколько ваши процессы действительно уникальны.
Когда своя платформа действительно оправдана
Такие случаи есть, и их стоит назвать честно.
Первое. Ваш процесс — это и есть продукт. Не «мы по-своему считаем зарплату», а «мы продаём методику, и её механика физически не ложится ни на одну учётную модель». Школы с собственной адаптивной программой, где траектория ученика пересобирается после каждого среза, — реальный кандидат.
Второе. Вы собираетесь продавать платформу другим школам. Тогда разработка перестаёт быть расходом и становится инвестицией в новый бизнес. Но считать её надо как отдельный бизнес: с маркетингом, поддержкой чужих клиентов и продажами. Школа при этом становится первым клиентом, а не заказчиком.
Третье. Масштаб, на котором лицензии перестают быть мелочью. Не пять филиалов, а несколько десятков и тысячи учеников. На этом уровне годовая стоимость лицензий сопоставима с зарплатой небольшой продуктовой команды, и калькулятор выше начинает давать реальную точку безубыточности.
Четвёртое. Отраслевое требование, которого готовые системы не закрывают: например, хранение данных в собственном контуре по договору с крупным корпоративным заказчиком.
Что в этот список не входит: «нам не нравится интерфейс», «хотим свой логотип в системе», «в готовой нет отчёта, который я привык смотреть». Первое решается привыканием, второе — брендированием, третье — выгрузкой.
Как проверить, что «уникальный процесс» — не две настройки
Есть простое упражнение, которое занимает вечер и экономит миллионы. Оно называется «опишите процесс так, чтобы его понял человек не из вашей школы».
Возьмите то, ради чего вы собираетесь заказывать разработку, и запишите по шагам: что происходит, при каком условии, какая формула, какое исключение. Не «мы по-особому считаем абонементы», а конкретно: «абонемент на 8 занятий, срок действия 2 месяца, заморозка до 14 дней по заявлению, при переносе занятие списывается по цене исходного тарифа».
Дальше три проверки:
- Покажите описание любому вендору и попросите не рассказ, а показ. «Настройте это на демо-стенде при мне» — вопрос, который снимает половину сомнений за час. Отказ показать тоже информативен.
- Посчитайте, сколько денег висит на этой уникальности. Если правило касается 5% учеников и приносит меньше, чем месяц работы разработчика, — это кандидат на упрощение, а не на автоматизацию. Иногда дешевле изменить процесс, чем платформу.
- Спросите, что будет, если правило отменить. Часть «уникальных» правил — это следы старых решений, которые никто не пересматривал с тех пор, как школа была на один кабинет.
В разговорах с руководителями школ на эфирах EduGrowth эта развилка всплывает регулярно, и почти всегда за «нам нужна своя система» стоит не механика процесса, а отсутствие цифр: владелец не видит наполняемость групп и не может проверить, работает ли реклама. Своя платформа эту проблему не решает — она просто переносит её в новый интерфейс, за который вы заплатили сами. Что именно должна показывать система, чтобы проблема ушла, разобрано в материале о том, зачем языковой школе CRM, а сценарий сети — в статье про управление филиалами.
Контринтуитивная часть: чем сильнее вы уверены, что ваш процесс уникален, тем выше шанс, что вы просто ни разу не описывали его словами. Уникальность, которую невозможно записать на одну страницу, — это не уникальность, а привычка.
Что делать до того, как подписывать договор
Порядок, который экономит и деньги, и полгода:
- Опишите свои «уникальные» процессы письменно, по шагам, с формулами и исключениями.
- Прогоните описание через два-три демо готовых систем и требуйте показа, а не рассказа.
- То, что не легло, посчитайте деньгами: сколько учеников затрагивает и какая сумма на кону.
- Прогоните калькулятор выше на своих цифрах и посмотрите на точку безубыточности.
- Если после этого своё всё ещё выигрывает — заказывайте, но с исходниками в своём репозитории и документацией в приёмке.
Частые вопросы
Цена разработки складывается из ставки команды и срока: примерно 160 часов в месяц на специалиста, полтора специалиста в среднем по проекту, 6-12 месяцев работы. Но эта сумма — только первый год. Дальше добавляются поддержка и доработки (ориентировочно 20% от стоимости разработки ежегодно), инфраструктура и интеграции. Смотреть надо не на КП, а на стоимость владения за три года — для этого и сделан калькулятор выше.
Это чаще всего лучший из вариантов, и его почему-то рассматривают последним. Вы платите за конкретную функцию, а не за учёт, расписание, оплаты и отчёты, которые уже написаны. Порядок такой: сначала выясните у вендора, есть ли нужное поведение в настройках; если нет — запросите оценку доработки. Обычно она в десятки раз меньше стоимости своей платформы, а поддержка остаётся на вендоре.
Риск реальный, но лечится он не разработкой, а договором: регулярная выгрузка всех данных в открытом формате (CSV или SQL-дамп), право на выгрузку прописано, выгрузка проверена вами хотя бы раз. Своя платформа от потери данных не защищает — она переносит риск с вендора на одного разработчика и на ваш сервер, где резервные копии делает тот же человек.
Оператором персональных данных школа остаётся в обоих сценариях — это не перекладывается на вендора. Разница в технической части: в готовой системе защита, хранение и реакция на инциденты в основном лежат на вендоре, в своей платформе всё это ваше, включая уведомление Роскомнадзора об утечке в течение суток. Считать эту работу надо в бюджете, а не в героизме администратора.
Универсального числа нет — считается через калькулятор на ваших цифрах. Но закономерность устойчивая: пока годовая стоимость лицензий заметно меньше содержания одного разработчика, точка безубыточности уходит за горизонт планирования. Сети до пяти филиалов в эту логику почти никогда не попадают.
Потраченное уже не вернуть, и оно не должно влиять на решение — считайте только будущие расходы. Ответьте на два вопроса: сколько ещё нужно вложить до рабочего состояния и во сколько обойдётся год эксплуатации после. Сравните с готовой системой на том же горизонте. Если разница в пользу готовой — честнее остановиться, забрать исходники и данные и перенести школу, чем доплачивать за решение, принятое год назад.
Коротко
Заказная платформа — это не покупка системы, а найм на длинный срок. Вы берёте на себя роль вендора для самого себя: с поддержкой, релизами, серверами и ответственностью за 152-ФЗ. Это оправдано, когда процесс действительно является продуктом или когда масштаб такой, что лицензии сопоставимы с зарплатой команды. В остальных случаях аккуратный расчёт на три года показывает разницу в разы не в пользу своего.
Перед тем как принимать решение, пройдите модуль Академии про CRM для руководителя — там разобрано, какие процессы школы автоматизируются настройками, а какие действительно требуют кода. И запросите демонстрацию BigBen CRM на своих процессах: попросите показать ровно ту механику абонементов и зарплат, ради которой вы собирались заказывать разработку. Час на демо стоит дешевле, чем полгода на аналитику.
Раз в две недели — цифры рынка школ
Один разбор и обновлённые бенчмарки рынка языковых школ: ставки преподавателей, средний чек, отток. Без новостей и рекламных писем.
Нажимая «Подписаться», вы соглашаетесь с политикой конфиденциальности и получением писем от BigBen CRM.
