ЦОТ "Сфера безопасности" — учебный центр в сфере охраны труда, безопасности и профессионального образования.
Для такого бизнеса сайт работает не как визитка. Он должен помогать человеку найти подходящий курс, понять условия, оставить заявку, вернуться к материалам, а команде — управлять большим каталогом, статьями, юридическими страницами, заявками и источниками обращений.
В проекте фигурировал каталог 500+ курсов. Если каждый курс вести как отдельную ручную страницу, наполнение, проверка и обновление быстро становятся отдельным производственным процессом. Поэтому сайт нужно было проектировать как систему данных.
Что было до проекта
До запуска новой платформы у клиента уже были образовательные программы, контент, рассылки, СДО, CRM-контур и действующий спрос. Но цифровая система была разорвана на несколько частей.
Каталог курсов было сложно превратить в понятную витрину. Встречались похожие или пересекающиеся курсы, разные поставщики, форматы и цены. Пользователю нужно было быстро понять, какой курс ему подходит, а команде — иметь возможность проверять, обновлять и публиковать карточки без ручной сборки каждой страницы с нуля.
Отдельный риск был в заявках. Если форма отправляет данные только во внешнюю CRM, сбой интеграции может привести к потере обращения. Для учебного центра это критично: заявка может прийти из статьи, каталога, формы обратной связи или кампании с UTM-метками, и ее нужно сохранить даже при проблемах на стороне внешнего сервиса.
Еще один блок — контент и SEO. У клиента были статьи и экспертные материалы, которые могли приводить пользователей к курсам. Но статьи сами по себе не гарантируют заявку. Нужны CTA, аналитика переходов, понятные формы и техническая база, чтобы поисковые страницы, блог и каталог работали на конверсию.
Что нашли при разборе
Главный вывод: сайт учебного центра нельзя делать как набор статичных страниц. При большом каталоге и регулярном контенте он должен быть системой управления сущностями.
Мы выделили несколько узких мест:
- курс нужно описывать через набор полей, а не через произвольный текст на странице;
- для
500+курсов ручная подготовка описаний, изображений, SEO-полей и загрузки могла занять сотни часов; - админке нужны роли и состояния контента: черновик, публикация, снятие с публикации, проверка перед продом;
- для форм важны UTM, страница заявки, источник, CRM-статус и резервное хранение лида;
- в аналитике должны быть видны не только визиты, но и ключевые действия пользователя;
- для статей нужны встроенные переходы к заявке, курсам или консультации, иначе контент остается только чтением.
Отдельно зафиксировали технический принцип: CRM-интеграция не должна быть единственной точкой сохранения заявки. Сначала лид сохраняется на бэке сайта, затем отправляется в amoCRM; при сбое остается возможность повторной отправки.
Как выбрали что брать в работу
Первый этап нужно было собрать вокруг запуска и управляемости, а не вокруг всех возможных идей сразу.
В объём работ вошли:
- структура сайта и ключевые страницы;
- каталог курсов и фильтрация;
- блог и статьи;
- страницы сведений об образовательной организации;
- админка для курсов, статей и дополнительных материалов;
- импорт и донаполнение курсов;
- формы заявок и резервное хранение лидов;
- интеграция с amoCRM;
- Яндекс.Метрика, UTM и базовая аналитика;
- техническая подготовка к SEO;
- тестовый контур и запуск на боевом домене.
Такой объем позволял запустить рабочую платформу и сразу оставить основу для следующих этапов: личного кабинета, документов, повторных покупок, более глубокой CRM-логики и расширенной аналитики.
Что не стали делать
В первый этап сознательно не стали включать все будущие сценарии учебного центра.
Не стали сразу делать полноценный личный кабинет с сотрудниками, документами, статусами обучения, повторными заказами и корпоративным самообслуживанием. Эти сценарии логично развивать после запуска базовой платформы, когда уже есть каталог, заявки, CRM и данные по поведению пользователей.
Не стали вручную полировать каждую карточку курса как отдельный мини-лендинг до запуска. Для такого объема это раздувало бы сроки. Вместо этого сделали повторяемый процесс: структура данных, генерация и адаптация материалов, загрузка через API, выборочная проверка и последующие итерации.
Что сделали
1. Собрали сайт вокруг сущностей, а не страниц
Курсы, статьи, юридические страницы и дополнительные разделы были спроектированы как управляемые сущности. Это важно для учебного центра: если в каталоге сотни программ, команда должна обновлять данные системно, а не редактировать каждую страницу как отдельный документ.
Курс получил структуру: название, описание, программа, формат, длительность, цена, изображение, SEO-поля, статус публикации и связи с разделами сайта. Это создало основу для каталога, фильтров, карточек и будущих интеграций.
2. Сделали админку для курсов, статей и публикаций
Команда получила административный контур для управления контентом. Через него можно готовить материалы, проверять, публиковать и снимать с публикации курсы и статьи.
Отдельно важен тестовый контур: изменения можно проверять до публикации на проде. Для сайта с курсами, юридическими материалами и заявками это снижает риск выпускать непроверенный контент сразу на боевой домен.
3. Настроили массовое наполнение курсов
Для каталога 500+ курсов ручной сценарий был бы слишком дорогим по времени. В расчетной модели ручная подготовка описаний, изображений, загрузка, проверка и повторные правки давали примерно 200-300 часов.
Мы использовали конвейерный подход:
- структурированный список курсов;
- генерация или адаптация описаний;
- подготовка изображений с помощью AI;
- запись результата;
- загрузка через API;
- выборочная проверка;
- исправление шаблона;
- следующий прогон.
Автоматизированный workflow был разложен на 20 часов настройки, подготовки промптов, прогонов данных, исправления ошибок, выборочной редактуры и QA. Человек остался в проверке смысла и качества, а рутинное копирование, загрузка и повторение перешли в процесс.
4. Связали формы, UTM, amoCRM и резервное хранение лидов
Формы сайта были связаны с CRM-контуром и аналитикой. При создании заявки сайт сохраняет лид у себя, фиксирует источник, UTM и технические данные, а затем отправляет обращение в amoCRM.
Если отправка не проходит, лид остается в системе, получает статус, и его можно отправить повторно. Для команды это меняет контроль процесса: заявки видны не только как внешние сделки, но и как записи в собственной системе сайта с CRM-статусом и технической информацией.
5. Подключили аналитику и техническую базу запуска
В проект вошли Яндекс.Метрика, UTM-логика, Яндекс.Вебмастер, технические SEO-поля, sitemap/индексационные проверки и разбор событий, связанных со статьями и заявками.
После запуска отдельный фокус был на конверсии: где пользователю проще перейти от чтения или выбора курса к целевому действию. Сайт получил основу для дальнейших точечных улучшений: видны ключевые действия, источники и страницы, с которых пользователь приходит к заявке.
6. Проверили техническое качество страницы
По приложенному Lighthouse-снимку сайт получил:
- Performance:
92; - Accessibility:
93; - Best Practices:
100; - SEO:
100.
Ключевые метрики загрузки:
- First Contentful Paint:
0.4 s; - Largest Contentful Paint:
0.8 s; - Total Blocking Time:
20 ms; - Speed Index:
0.9 s; - Cumulative Layout Shift:
0.171.
Что изменилось после запуска
ЦОТ "Сфера безопасности" получил сайт, который можно развивать как операционную платформу.
Курсы, статьи, формы и заявки перестали быть разрозненными элементами. Каталог 500+ курсов можно поддерживать через структуру данных и админку. Контент можно готовить и проверять перед публикацией. Заявки сохраняются на стороне сайта, передаются в amoCRM и могут быть отправлены повторно при сбое.
Скорость наполнения перестала зависеть только от ручной работы контент-менеджера. Вместо сценария на 200-300 часов появилась автоматизированная схема, разложенная на 20 часов настройки, прогонов, исправлений и QA. Это не отменяет человеческую проверку, но убирает большую часть однотипной рутины.
Путь к целевому действию стал понятнее: курс, статья, форма, источник и CRM-статус связаны в один процесс. Это дало команде базу для роста конверсии и дальнейшего улучшения сайта на данных, а не на догадках.
Что можно развивать дальше
- Усилить CTA в статьях, чтобы контент вел не только к чтению, но и к заявке, подбору курса или консультации.
- Развить личный кабинет для корпоративных клиентов: сотрудники, повторные заказы, документы, счета, статусы обучения и история взаимодействия.
- Расширить CRM-логику: отдельные воронки продаж, сопровождения, поддержки и повторных касаний.
- Доработать аналитику до сквозного контура: источник, заявка, CRM-статус, КП, договор, оплата и повторная покупка.
- Продолжить SEO-техническую работу: индексация, редиректы, метаданные, внутренние ссылки, контроль дублей и событий.
- Улучшить Best Practices и CLS по Lighthouse, чтобы техническая оценка была ровнее по всем блокам.
- Перенести контентный workflow в регулярный процесс для новых курсов, статей и обновлений.
Для каких задач подходит похожий подход
Похожий подход подходит компаниям, у которых:
- есть большой каталог курсов, услуг, товаров, документов или материалов;
- сайт должен быть не витриной, а рабочей системой заявок и контента;
- нужна интеграция сайта с CRM и резервное хранение обращений;
- важно видеть UTM, источник, страницу заявки и CRM-статус;
- ручное наполнение уже тормозит запуск или обновления;
- статьи, рассылки и SEO должны приводить к понятным целевым действиям;
- текущая CMS или конструктор ограничивает развитие продукта.
CTA
Если сайт уже есть, но курсы, статьи, заявки, CRM и аналитика живут отдельно, сначала стоит разобрать систему целиком: какие сущности есть, где теряются данные, что тормозит команду и какие действия пользователя действительно нужно измерять.
Gigonom может провести цифровой аудит сайта, CRM, контента и аналитики, а затем собрать понятный бэклог: от быстрых правок пути до заявки до полноценной платформы с каталогом, админкой, интеграциями и автоматизацией.