Путь слушателя public flow
- Программа
- Подходящая дата
- Анкета
- Оплата или заявка
- Документы
WordPress · собственный код · интеграции · авиационное образование
Создание сайта для авиационного учебного центра
Разрабатываю сайты для АУЦ и учебно-тренировочных центров авиакомпаний. Собираю не только публичные страницы, но и рабочую систему: каталог программ, расписание, запись, свободные места, оплату, договоры, личные кабинеты, документы и интеграции.
Состав проекта определяется процессами конкретной организации. Функции можно запускать поэтапно: сначала привести в порядок программы и документы, затем подключить управляемое расписание, запись и внутренние кабинеты. В каждом случае заранее фиксируются границы автоматизации, роли сотрудников и системы, с которыми должен обмениваться сайт. Поэтому в оценку попадает только согласованный объём, а не весь возможный перечень модулей, с учётом ресурсов команды и требований инфраструктуры.
- 3 проекта в авиационном образовании
- WordPress и собственные модули
- Работа на инфраструктуре заказчика
- Запуск, инструкция и поддержка
Можно прийти без готового технического задания. Сначала разберу, как центр публикует программы, формирует расписание, принимает заявки и ведёт слушателя.
- Программа
- Дата
- Запись
- Оплата
- Договор
Не просто презентация
Сайт становится рабочим инструментом учебного отдела
Обычный корпоративный сайт знакомит с центром и собирает заявки. У авиационного учебного центра задача сложнее: программы связаны с форматами обучения, датами, городами, количеством мест, документами, оплатой и работой сотрудников. Если эти процессы остаются в отдельных таблицах, письмах и формах, данные приходится переносить вручную.
Я проектирую публичную часть и внутренние операции как одну систему. Слушатель находит программу и проходит понятный путь записи, а учебный отдел управляет расписанием, заявками и документами без постоянного обращения к разработчику.
На старте разбираю не только желаемые страницы, но и источники информации. Важно понять, где сейчас хранится актуальная программа, кто открывает набор, как сотрудники узнают об оплате и в какой момент заявка считается подтверждённой. Эти ответы определяют архитектуру точнее, чем перечень экранов.
Автоматизация не должна усложнять редкие операции ради красивой схемы. Если действие требует решения специалиста, система может сохранить ручное подтверждение, но дать сотруднику все данные и понятный статус в одном месте. Повторяемые переносы, проверки и уведомления, наоборот, становятся кандидатами на автоматизацию.
Работа учебного отдела back office
- Программа
- Слоты
- Публикация
- Заявки
- Статусы
- Выгрузка
Отраслевые сценарии
Один подход к архитектуре — разные задачи авиационного образования
Авиационный учебный центр
Программы подготовки авиационного персонала, расписание, документы, заявления и сведения об образовательной организации. Структура помогает слушателю отличить направления подготовки, требования к поступлению, форму обучения и ближайшие даты, а сотрудникам — обновлять эту информацию из одного управляемого источника.
Учебно-тренировочный центр авиакомпании
Обучение сотрудников и внешних слушателей, закрытые материалы, интеграция с внутренними системами и работа в инфраструктуре заказчика. До разработки отдельно определяются публичный и корпоративный контуры, правила доступа, сетевые ограничения и зона ответственности за серверы.
Центр подготовки БАС и БВС
Каталог программ, теория и практика, набор групп, расписание, оплата и выдача согласованных документов. Если этапы курса проходят на разных площадках, в модели можно разделить теоретические занятия, практику, группы и доступные периоды без дублирования страниц.
Ассоциация и отраслевое объединение
Публичная информация, новости, реестр участников, закрытый кабинет, поиск и обмен документами. Для такого проекта основным процессом может быть не продажа обучения, а безопасная работа участников с протоколами, письмами и общими материалами.
Корпоративный центр подготовки персонала
Разные роли, филиалы, форматы обучения, заявки от организаций и интеграции с CRM или внутренним контуром. Архитектура учитывает, кто создаёт программу, кто открывает набор, кто подтверждает группу и в какой системе должен появиться итоговый статус.
Существующий АУЦ, которому нужна доработка
Аудит текущего сайта, перенос без потери важных URL, новый каталог программ, запись, кабинеты или отдельный кастомный модуль. Перед изменениями проверяю структуру адресов, документы, формы, аналитику и связи с внешними сервисами, чтобы развитие не разрушило работающие сценарии.
Модули системы
Собираю сайт под реальные процессы конкретного центра
Набор функций определяется после разбора программ, ролей и пути заявки. Ниже — модули, из которых можно собрать минимальный рабочий контур и последующее развитие платформы.
Каталог программ
Направления, категории, форматы, города, требования, стоимость и связанные документы.
Единое расписание
Конкретные даты, периоды, время по согласованию, фильтры и ближайшие наборы.
Свободные места
Лимиты, серверная проверка доступности и защита от двойного обещания одного места.
Запись физического лица
Профиль, анкета, подтверждение условий и связанная заявка.
Заявка от организации
Отдельный сценарий для группы, реквизитов и согласования условий без обязательной мгновенной оплаты.
Онлайн-оплата
Полная оплата, предоплата или запись без платежа; конкретный сценарий проверяется с провайдером и кассой.
Автоматические договоры
Заполнение DOCX-шаблона данными слушателя, программы, даты и оплаты.
Личный кабинет слушателя
Профиль, записи, статусы, документы и доступные материалы.
Кабинет учебного отдела
Программы, слоты, заявки, статусы, ручные операции, поиск и CSV без доступа к секретным настройкам WordPress.
Закрытая часть обучения
Материалы по логину и паролю, разграничение доступа и интеграция с внешней LMS при необходимости.
Документооборот
Загрузка, поиск, скачивание и распределение документов по участникам или категориям.
Уведомления и почта
Служебные письма, Telegram-уведомления, журнал отправки и повторная отправка.
Интеграции
CRM, API, платёжные системы, внутренние справочники, вебхуки и согласованные выгрузки.
Версия для слабовидящих
Режимы отображения и доступность интерфейсов; полное соответствие стандарту подтверждается отдельным аудитом.
Аналитика
Яндекс Метрика, цели, события ключевых шагов и контроль воронки.
Защита и журналы
Роли, права, серверные проверки, защищённые маршруты, логи платежей, писем и действий.
Не все модули нужны сразу. На старте определяется минимальный рабочий контур, но общая модель данных проектируется так, чтобы сайт можно было развивать без полной переделки.
Связи между модулями
Ценность появляется не в количестве функций, а в согласованном движении данных
Единая модель программы
Название курса, формат и описание не должны заново вводиться в расписании, заявке и договоре. Программа становится основной сущностью, а даты, цены, документы и требования связываются с ней через понятные поля.
Так редактор меняет содержание в одном месте, а система показывает актуальную версию в каталоге, карточке набора и кабинете.
Слот как конкретный набор
Одна и та же программа может проходить в разные даты, городах и форматах. Для каждого набора хранятся период, лимит, статус публикации и правила записи. Это отделяет постоянное описание курса от оперативного расписания.
Если набор переносится или закрывается, сотрудник меняет слот, а не редактирует несколько несвязанных страниц.
Заявка с историей статусов
После анкеты важны не только контактные данные, но и выбранная программа, дата, тип заказчика, платёжный сценарий и документы. Связанная заявка позволяет видеть весь путь и не восстанавливать его по почтовой переписке.
Права на просмотр и изменение статусов определяются ролями сотрудников и согласованным регламентом центра.
Проверки в критической точке
Интерфейс может заранее показать доступность места, но перед бронированием и оплатой сервер должен проверить её повторно. По такому же принципу проверяются права, обязательные поля и допустимость перехода между статусами.
Это снижает риск расхождений, когда несколько пользователей действуют одновременно или внешняя система отвечает с задержкой.
Почему нужен собственный код
WordPress управляет контентом, а бизнес-логика работает в отдельном модуле
WordPress удобен для страниц, новостей, программ и документов, но сложный процесс записи нельзя надёжно собирать из набора несвязанных форм. Когда дата влияет на цену, цена — на оплату, оплата — на статус, а заявка — на договор и доступ в кабинет, нужна единая серверная модель.
Поэтому публичный сайт остаётся понятным редакторам, а критическая логика выносится в собственный плагин или отдельную интеграционную часть. Это позволяет контролировать права, данные, платежные статусы, доступность мест и дальнейшее развитие системы.
Публичный сайт WordPress
Программы, страницы, новости, документы и формы.
Собственный модуль
Запись, статусы, места, договоры и серверные проверки.
База, роли и журналы
Связанные данные, права сотрудников и история действий.
Оплата, CRM, почта, API
Внешние сервисы и инфраструктура организации.
Интерфейсы по ролям
Каждый участник видит свой участок процесса, а не всю служебную систему
Слушатель
Получает понятный каталог без внутренних терминов, сравнивает даты и форматы, читает требования и проходит согласованный сценарий записи. В кабинете видит только собственные заявки, статусы, документы и материалы, к которым ему открыт доступ.
Если для организации предусмотрен другой порядок, пользователь сразу понимает, когда нужно оплатить, а когда — отправить заявку на согласование.
Учебный отдел
Работает с программами, наборами и заявками в отдельном интерфейсе, не заходя в критические настройки WordPress. Поиск, фильтры, статусы и выгрузки проектируются под ежедневные операции, а не под структуру базы данных.
Ручные действия остаются там, где требуется решение сотрудника; повторяемые переносы данных можно автоматизировать.
Администратор системы
Контролирует роли, интеграции и технические журналы в пределах согласованных полномочий. Секретные ключи, платёжные настройки и служебные маршруты не должны быть доступны обычному редактору контента.
Такое разделение уменьшает риск случайного изменения критической логики и упрощает передачу проекта команде заказчика после запуска.
Модульная архитектура
Шаблон публикует страницы — система связывает весь путь заявки
Сравнение помогает определить, где достаточно стандартных возможностей WordPress, а где нужен отдельный контур данных и проверок.
| Возможность | Обычный сайт на шаблоне | Сайт АУЦ с собственным модулем |
|---|---|---|
| Редактировать страницы и программы | Да | Да |
| Показывать разные даты и форматы | Ограниченно | Да |
| Проверять свободные места перед оплатой | Обычно нет | Да |
| Разделять физлиц и организации | Через отдельные формы | Единая логика |
| Хранить связанную историю заявки | Ограниченно | Да |
| Формировать договор из данных записи | Нет | Да |
| Разделять роли слушателя и сотрудников | Ограниченно | Да |
| Развивать систему по этапам | С риском переделки | Да, при модульной архитектуре |
Таблицу можно прокручивать по горизонтали →
Границы решения
Собственный модуль нужен там, где данные влияют друг на друга
Что остаётся стандартным
Информационные страницы, новости, статьи, контакты и большая часть документов могут редактироваться привычными средствами WordPress. Для них не нужно создавать отдельную административную систему только ради внешнего отличия.
Это сохраняет понятный процесс публикации и позволяет сотрудникам самостоятельно обновлять материалы после передачи проекта.
Что требует общей логики
Расписание, места, заявки, платежи и договоры рассматриваются как связанный процесс. Изменение даты или статуса не должно оставлять противоречивую информацию в письме, кабинете и интерфейсе учебного отдела.
Для каждого перехода заранее описывается источник данных, допустимое действие, ответственный пользователь и поведение при ошибке внешнего сервиса.
Как проект развивается
Первый запуск может включать только каталог, расписание и заявки, если этого достаточно для текущего этапа. При этом названия сущностей, связи и роли фиксируются так, чтобы позднее подключить оплату, договоры или кабинеты без переноса в совершенно другую модель.
Очередность определяется пользой для сотрудников и слушателей, рисками интеграций и готовностью данных заказчика.
Структура образовательной организации
Предусматриваю документы, обязательные разделы и удобное обновление
На сайте образовательной организации недостаточно разместить только каталог программ и контакты. При проектировании предусматриваю специальный раздел со сведениями об организации, документы, информацию об образовании, руководстве, педагогическом составе, материально-техническом обеспечении, платных услугах и другие подразделы, которые относятся к конкретному центру.
Состав и формат публикации проверяются перед запуском по актуальным требованиям и документам заказчика. Я отвечаю за структуру, интерфейс и техническое размещение переданных материалов. Юридическую полноту, актуальность документов и применимость требований подтверждает ответственное лицо или юрист образовательной организации.
01Отдельная навигация по обязательным сведениям
02Редактируемые страницы и файлы
03Понятные названия и даты документов
04Версия для слабовидящих и клавиатура
05Политика данных и согласия в формах
06Контроль файлов и битых ссылок
Техническая реализация не заменяет юридическую проверку. Полноту сведений, формулировок и документов подтверждают ответственные специалисты со стороны центра.
Перед публикацией
Раздел со сведениями проектируется не как склад файлов, а как поддерживаемая структура
Карта материалов
До сборки фиксируются подразделы, ответственные сотрудники и фактический набор документов. Для каждого файла полезно определить понятное название, дату, формат и место публикации, чтобы посетитель мог найти нужный материал без знания внутренней структуры организации.
Если один документ относится к нескольким страницам, лучше хранить единый актуальный источник, а не независимые копии с разными датами.
Доступность интерфейса
Клавиатурная навигация, заметный фокус, читаемый контраст и корректная структура заголовков закладываются в компоненты сайта. Для таблиц и длинных перечней подбирается мобильный сценарий, который не обрезает содержание и не создаёт горизонтальный скролл всей страницы.
Версия для слабовидящих может расширять режимы отображения, но подтверждение соответствия конкретному стандарту требует отдельной проверки всех шаблонов и контента.
Персональные данные
В анкете запрашиваются только поля, необходимые для согласованного процесса. Согласия и ссылки на политику размещаются рядом с действием пользователя, а доступ сотрудников к заявкам ограничивается ролями.
Состав формулировок предоставляет или подтверждает заказчик. В аналитику не передаются телефон, электронная почта, реквизиты организации или свободный текст заявки.
Опыт в нише
Три проекта для авиационных учебных центров — три разных рабочих сценария
Флагманский проектJet Service
Сайт и собственная платформа обучения на WordPress
Для Jet Service разработал публичный сайт и отдельный WordPress-плагин, который связывает программы, расписание, свободные места, регистрацию, бронирование, оплату через ЮKassa, DOCX-договоры и кабинеты. Учебный отдел управляет программами и заявками в отдельном интерфейсе, а критические действия проверяются на сервере и записываются в журналы.
Открыть кейс Jet Service ↗
Инфраструктура заказчикаNW Training
Сайт тренировочного центра авиакомпании
Для тренировочного центра авиакомпании «Северный ветер» разработал сайт на WordPress с учётом брендбука, работы на серверах заказчика и интеграции с CRM. В проекте предусматривались автоматическое формирование договора и закрытая часть для дистанционного обучения отдельных слушателей.
Открыть кейс NW Training ↗
Закрытый кабинетАссоциация авиационных учебных центров
Публичный сайт и закрытый обмен документацией
Для Ассоциации авиационных учебных центров разработал сайт на WordPress и личный кабинет участников. В закрытой части реализованы загрузка, скачивание и поиск протоколов, входящих и исходящих писем. Публичная часть знакомит с деятельностью ассоциации и собирает обращения.
Открыть кейс Ассоциации АУЦ ↗Объём разработки
Можно начать с нового сайта или автоматизировать отдельный процесс
Корпоративный сайт АУЦ
Подходит, когда нужно системно представить центр, программы и документы, обновить визуальную подачу и заменить разрозненные формы единым понятным маршрутом заявки. На этом этапе можно подготовить модель будущего расписания, даже если автоматизация запускается позже.
- Структура и прототип
- Индивидуальный дизайн
- Каталог программ
- Новости, документы и обязательные сведения
- Формы заявок
- Аналитика и базовая SEO-подготовка
Сайт с записью и оплатой
Выбирается, если конкретная дата, лимит мест и данные слушателя должны быть связаны до подтверждения заявки. Отдельно согласуются сценарии физического лица и организации, момент резервирования места, платёжные статусы и поведение при отмене или ошибке.
- Всё из корпоративного сайта
- Управляемое расписание
- Места и регистрация
- Сценарии физлиц и организаций
- Полная оплата или предоплата
- Договоры и уведомления
Цифровая платформа учебного центра
Нужна, когда сайт становится рабочим местом нескольких ролей и взаимодействует с внутренним контуром. Проект разбивается на модули и этапы: так можно сначала запустить критический путь, проверить его на реальных операциях и затем расширять кабинеты и интеграции.
- Всё из предыдущего формата
- Кабинеты слушателя и учебного отдела
- Роли, статусы и журналы
- Закрытые материалы
- CRM/API и внутренние интеграции
- Развитие системы по этапам
Стоимость рассчитывается после короткого разбора процессов. На неё сильнее всего влияют не количество информационных страниц, а логика расписания, роли пользователей, оплата, документы, интеграции и требования к инфраструктуре. После обсуждения фиксирую состав, этапы, сроки и стоимость.
Что нужно для оценки
Для первого расчёта важнее примеры рабочих материалов, чем формальный многостраничный бриф
Программы и расписание
Достаточно показать одну типичную программу и реальный пример расписания: какие бывают даты, города, форматы, длительность и ограничения группы. По ним можно увидеть, какие данные постоянны, а какие относятся к конкретному набору.
Если расписание пока ведётся в таблице, она часто полезнее общего описания желаемого сайта, потому что показывает фактические поля и исключения.
Путь заявки и документы
Нужно коротко описать, что происходит после интереса слушателя: кто получает анкету, когда подтверждается место, требуется ли оплата, кто готовит договор и какие письма отправляются. Для организаций отдельно фиксируется групповая заявка и работа с реквизитами.
Шаблон договора или уведомления помогает оценить автоматическое заполнение, но юридическое содержание остаётся ответственностью заказчика.
Системы и ограничения
На оценку влияют CRM, платёжный провайдер, почта, LMS, внутренние справочники и требования к размещению. До обещания интеграции проверяются документация, доступный способ обмена, авторизация, тестовая среда и ограничения на передачу данных.
Если часть доступов появится позже, проект можно разделить так, чтобы публичные страницы и подготовка модели не зависели от неопределённой интеграции.
Как проходит работа
Сначала описываю процессы и данные — затем рисую интерфейс
Знакомство и аудит
Программы, расписание, заявки, документы, роли, текущий сайт и ручные операции.
Архитектура
Сущности, статусы, связи, права, интеграции и пограничные ситуации.
Структура и прототип
Путь слушателя, путь организации и рабочие экраны учебного отдела.
Индивидуальный дизайн
Авиационная стилистика, интерфейсы программ, расписания, кабинетов и документов.
WordPress и собственный код
Управляемый контент, отдельные модули и серверные проверки.
Интеграции
CRM, платежи, почта, уведомления, шаблоны документов и внешние API.
Тестирование
Роли, мобильные устройства, оплаты, письма, лимиты мест, ошибки и восстановление сценариев.
Запуск и передача
Аналитика, инструкция со скриншотами, обучение сотрудников и согласованная поддержка.
Результат этапов
Команда получает не только опубликованные страницы, но и понятные правила работы системы
Зафиксированная архитектура
До программирования описываются основные сущности, связи, роли и статусы. Отдельно разбираются пограничные ситуации: группа заполнена во время оплаты, письмо не отправилось, платёж вернулся с задержкой, сотрудник изменил дату после заявок.
Так решения принимаются до появления дорогих переделок, а заказчик понимает границы первого запуска.
Согласованные интерфейсы
Прототип показывает не только последовательность рекламных блоков, но и действия слушателя и сотрудника. В дизайне проверяются длинные названия программ, разные статусы, пустые состояния, ошибки, мобильные таблицы и реальные объёмы документов.
Компоненты собираются в едином визуальном языке, чтобы новые разделы не выглядели чужими.
Проверенные сценарии
Тестирование проходит по ролям и цепочкам действий, а не только по отдельным кнопкам. Проверяются успешные и неуспешные оплаты, повторные запросы, лимиты, письма, документы, права доступа и работа на мобильных устройствах.
Состав тестов зависит от утверждённых модулей и возможностей подключённых систем.
Передача команде
После запуска сотрудники получают инструкцию со скриншотами по своим операциям: обновление программы, публикация набора, обработка заявки, поиск документа или выгрузка. Технические доступы и зоны ответственности фиксируются отдельно.
Поддержка и дальнейшие этапы согласуются по реальным задачам, а не включаются в обещания без определения объёма.
Владимир БалакинДизайн · WordPress · собственный код · API
Разработчик, а не посредник
Проектирую дизайн и сам отвечаю за сложную техническую часть
Меня зовут Владимир Балакин. Я разрабатываю сайты на WordPress и Tilda, пишу собственные модули, подключаю API, оплаты, кабинеты и автоматизацию. В проектах для авиационного образования уже работал с публичными сайтами, серверами заказчика, CRM, закрытым обучением, документооборотом и полноценной системой записи.
Поэтому на первой встрече могу обсуждать не только внешний вид страниц, но и реальные процессы: где создаётся программа, как появляется дата, кто подтверждает заявку, когда резервируется место, откуда берутся данные договора и какие действия доступны каждой роли.
Я не передаю техническую часть неизвестному подрядчику после согласования макета. Архитектурные решения, интерфейс и реализация рассматриваются вместе: если визуальный сценарий требует данных, которых нет у подключённой системы, это выясняется до разработки, а не во время запуска.
При работе на инфраструктуре организации заранее обсуждаются окружение, доступы, резервные копии, обновления и сетевые ограничения. Это помогает отделить разработку сайта от постоянного администрирования серверов и зафиксировать ответственность участников проекта.
Вопросы и ответы
Частые вопросы о разработке сайта авиационного учебного центра
Можно ли начать с обычного сайта и позже добавить запись?
Да. Сначала можно запустить структуру, программы, документы и формы заявок, а затем добавить расписание, бронирование, оплату и кабинеты. Важно ещё на первом этапе определить общую модель данных и сохранить возможность расширения без полной переделки.
Можно ли перенести уже работающий сайт АУЦ на WordPress?
Да. Перед переносом проверю страницы, URL, документы, формы, аналитику и текущие позиции. Составлю карту переноса и редиректов, сохраню важные адреса и отдельно определю, какие разделы стоит переработать.
Можно ли сделать разные сценарии для физлиц и организаций?
Да. Физическое лицо может выбрать дату, заполнить профиль и перейти к оплате. Организация может отправить заявку на одного слушателя или группу, передать реквизиты и согласовать договорные условия без запуска розничного платежного сценария.
Сайт может показывать реальные свободные места?
Да. Количество мест хранится у конкретного учебного слота. Перед подтверждением и оплатой система повторно проверяет доступность на сервере, чтобы не обещать одно место нескольким слушателям.
Можно ли автоматически формировать договор на обучение?
Да. Система может подставлять данные слушателя, программы, даты и стоимости в согласованный DOCX-шаблон. Это автоматическое заполнение документа, а не электронная подпись. Юридически значимое подписание подключается отдельно.
Можно подключить ЮKassa, CRM и внутренние сервисы?
Можно, если выбранные системы предоставляют нужный API, webhooks или другой поддерживаемый способ обмена. До оценки проверяю документацию, доступы, ограничения инфраструктуры и состав данных.
Можно разместить сайт на серверах организации?
Да. У меня есть опыт развёртывания проекта учебно-тренировочного центра на инфраструктуре заказчика. До старта согласуются окружение, доступы, ответственность за администрирование, резервные копии, обновления и сетевые ограничения.
Делаете ли вы версию для слабовидящих?
Да. Можно добавить управление размером текста, контрастом, изображениями, интервалами и другими режимами отображения. Полное соответствие конкретному стандарту подтверждается только после отдельного аудита всего сайта и контента.
Вы помогаете сертифицировать авиационный учебный центр?
Нет. Я проектирую и разрабатываю сайт, кабинеты и интеграции. Сертификацию АУЦ, утверждение программ, юридические формулировки и полноту обязательных документов ведут профильные специалисты и ответственные лица заказчика.
Сколько стоит и сколько занимает разработка?
Срок и стоимость зависят от расписания, ролей, оплаты, документов, личных кабинетов, интеграций и инфраструктуры. После короткого разбора процессов подготовлю архитектуру, этапы и фиксированный расчёт под задачу.
Обсудим проект
Расскажите, как сейчас устроена запись на обучение — предложу понятную архитектуру сайта
Подробное техническое задание не требуется. Достаточно прислать ссылку на текущий сайт, пример программы, расписание и коротко описать, что сотрудники делают вручную. Я задам уточняющие вопросы и предложу первый этап.
Работаю с проектами по всей России. Структура, дизайн, WordPress, собственный код, интеграции, запуск и инструкция — в одном проекте.
Проекты и разборы