Сайт авиационного учебного центра Jet Service: WordPress, онлайн-запись, оплата и договоры

Что было сделано для Jet Service

Изначально требовался сайт учебного центра, который понятно показывает большой каталог программ. Во время проектирования стало ясно: одной витрины недостаточно. Запись затрагивает расписание, количество мест, профиль слушателя, оплату, документы и работу администраторов. Поэтому публичную часть и внутренние операции я спроектировал как одну систему.

Почему обычного сайта учебному центру было недостаточно

У образовательного центра много типов контента: направления подготовки, отдельные программы, даты, форматы, преподаватели, официальные сведения и документы. Но для клиента структура страниц — только начало. Сайт должен помогать человеку понять условия и доводить его до корректно оформленной записи.

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

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

Сначала спроектировал путь слушателя и учебного отдела

До макетов я описал сущности и переходы между ними. Программа связана со слотами, слот — с количеством доступных мест, бронирование — с пользователем и платежом, а договор — с подтверждённой заявкой. Такая модель позволила не рисовать изолированные экраны, а заранее увидеть, какие данные понадобятся на каждом шаге.

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

Индивидуальный дизайн и перенос проекта на WordPress

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

Я унифицировал подачу направлений и программ, спроектировал адаптивную навигацию, общее расписание, карточки дат и отдельные состояния интерфейса записи. Кабинеты получили более прикладную подачу: меньше декора, больше ясных полей, статусов и действий. На мобильном двухколоночные композиции перестраиваются в последовательный сценарий, поэтому кнопка записи и основные условия не теряются.

После согласования дизайн был перенесён на WordPress. Платформа отвечает за страницы, публикации и редактируемый контент, а повторяемые элементы собраны так, чтобы сайт можно было развивать без ручной перевёрстки каждого нового курса. Такой перенос сайта на WordPress сохраняет индивидуальную подачу и одновременно даёт заказчику знакомый инструмент управления.

Структура важнее эффектного первого экрана

Для образовательного проекта посетителю нужно быстро различить направление и конкретную программу. Поэтому навигация поддерживает многоуровневую структуру, но не заставляет изучать всю классификацию заранее. Человек может начать с профессии, типа подготовки или расписания, а затем уточнить выбор на странице курса. Официальные сведения и документы вынесены в предсказуемые разделы и не смешаны с продающими карточками.

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

Адаптивность как часть сценария

На телефоне недостаточно просто уменьшить макет. Календарь, список слотов, подтверждение условий и форма должны идти в логичном порядке, помещаться по ширине и оставлять кнопки доступными для касания. Табличные данные превращаются в карточки, второстепенные подписи остаются рядом со значениями, а пользователь не вынужден прокручивать страницу горизонтально.

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

Jet Service Platform: бизнес-логика внутри отдельного WordPress-плагина

Ключевая техническая часть проекта не привязана к шаблону страницы. Я разработал собственный плагин Jet Service Platform, который хранит предметные сущности, применяет правила записи и предоставляет интерфейсы для публичного сайта и кабинетов. В его собственной части около 13 300 строк PHP, JavaScript и CSS без учёта официального SDK ЮKassa. Объём важен не сам по себе: он показывает, что речь идёт о самостоятельном приложении внутри WordPress, а не о нескольких обработчиках формы.

Архитектура построена вокруг пяти таблиц базы данных. Программы содержат правила отображения и записи. Учебные сессии описывают даты, периоды, города, стоимость и доступные места. Бронирования связывают слушателя, программу, слот, платёжное состояние и документ. Шаблоны отделяют тексты и договоры от программного кода. Системные логи помогают восстановить последовательность действий при диагностике.

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

REST API как контролируемая граница

Интерфейсы не обращаются к базе напрямую. Они вызывают REST-маршруты, которые проверяют входные данные, пользователя, роль и текущее состояние записи. Маршрут получения программ не выполняет ту же работу, что создание платежа; административное редактирование слота отделено от пользовательского выбора. Такое разделение делает правила заметными в коде и уменьшает вероятность случайно открыть лишние данные.

Ответ API содержит только то, что нужно конкретному экрану. Публичному календарю не требуются персональные данные заявок, а учебному администратору — секретные ключи платёжного профиля. Поэтому ограничение доступа строится не только на скрытии кнопки, но и на составе ответа сервера. Даже если запрос сформирован вручную, серверная проверка остаётся обязательной.

Шорткоды как точки сборки страниц

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

Шорткод не хранит программу внутри себя. Он получает идентификатор или контекст страницы и запрашивает актуальные данные. Благодаря этому изменение цены, слота или статуса публикации отображается в публичной части без ручной правки нескольких блоков. Один источник данных снижает расхождения между карточкой курса, общим расписанием и экраном подтверждения.

Состояния вместо набора несвязанных писем

Бронирование проходит предсказуемые состояния: создано, ожидает действия, связано с платежом, оплачено, отменено или требует работы сотрудника. Переход запускается только при выполнении условий. Например, уведомление платёжной системы не должно повторно сформировать документ, если заявка уже обработана, а пользователь не должен оплатить слот, который тем временем стал недоступен.

Эта модель упрощает диагностику. Вместо вопроса «почему кнопка не сработала» можно увидеть, в каком состоянии находилась заявка, какое действие было разрешено и какой ответ вернул внешний сервис. Для учебного отдела технические подробности переводятся в понятные статусы, а системный журнал остаётся инструментом администратора.

Программы обучения и единое расписание

Каталог курса полезен только тогда, когда посетитель понимает, когда и на каких условиях можно учиться. Для Jet Service я связал страницы программ с общей системой расписания. Пользователь может просматривать предложения и переходить к доступным вариантам, а учебный отдел меняет даты и лимиты в административном интерфейсе.

Обычный слот хранит дату, период обучения, время, стоимость, режим предоплаты и количество мест. Если точное время определяется позже, вместо искусственного значения показывается понятная формулировка «Время по согласованию». Для многодневного курса отображается период, а не только стартовая дата.

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

Что видит человек, а что настраивает сотрудник

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

Администратор сначала выбирает режим программы. Для фиксированного расписания он создаёт отдельные слоты и указывает параметры каждого. Для ежедневной записи задаёт правила один раз: рабочие дни, доступный период, исключения и лимиты. Это сокращает однообразное заполнение календаря и одновременно оставляет возможность закрыть конкретную дату.

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

Общее расписание без дублирования контента

Общее расписание собирает доступные предложения разных программ и даёт фильтры «Все», «Очно» и «Онлайн». Оно не является отдельной копией каталога: карточка получает актуальные параметры из той же системы. Пользователь может начать с интересующей программы либо с подходящей даты, но в обоих случаях приходит к одному сценарию записи.

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

Как слушатель записывается на обучение

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

Регистрация зависит от программы

У разных видов подготовки разный набор необходимых сведений. Поэтому поля анкеты выбираются в настройках программы, а не зашиваются в одну огромную форму для всех. Короткий сценарий не заставляет человека заполнять лишнее, а программа с договором может запросить информацию, которая действительно понадобится учебному отделу.

При повторной записи профиль используется как источник уже известных данных. Пользователь проверяет их и дополняет только недостающее. Это уменьшает объём ручного ввода и помогает сохранить единообразное написание информации в кабинете, заявке и документе. При этом сервер всё равно валидирует обязательные поля для выбранной программы.

Бронь и свободное место — не одно и то же

Показанный в календаре слот может стать недоступным, пока человек заполняет анкету. Поэтому перед продолжением выполняется новая проверка. Если место уже занято, система не отправляет пользователя к оплате с устаревшими условиями, а предлагает вернуться к выбору. Если место доступно, создаётся связанное бронирование с ограниченным временем действия.

Такая модель защищает обе стороны. Слушатель не оплачивает вариант, который центр не сможет подтвердить, а учебный отдел не получает две формально успешные заявки на последнее место. Время брони можно настроить под продолжительность анкеты и платежа: оно должно быть достаточным для нормального действия, но не блокировать расписание навсегда.

Запись без платёжного виджета

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

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

Собственный модуль интеграции с ЮKassa

Платёжная логика разработана внутри Jet Service Platform, но деньги принимает ЮKassa. Для интеграции использованы официальный SDK, защищённый виджет и webhooks. Это важное различие: сайт управляет заявкой, суммой и состояниями брони, а ввод платёжных данных происходит в интерфейсе платёжного сервиса.

Для разных программ предусмотрена полная оплата или предоплата. При предоплате в заявке сохраняются полная стоимость, оплаченная часть и остаток. Отдельные профили позволяют работать с передачей данных для чека или без неё в зависимости от настроек конкретной программы. Назначение платежа и признак полной оплаты либо предоплаты формируются на сервере.

Перед созданием платежа система проверяет заявку, пользователя, актуальную стоимость и доступность места. Повторный клик не должен порождать несколько независимых платежей: используется защита от повторной операции, а незавершённый платёж при допустимых условиях можно продолжить. После уведомления ЮKassa сервер дополнительно проверяет статус, обновляет бронь и запускает связанные действия.

Как связаны заявка, платёж и webhook

Платёж создаётся не из суммы, присланной браузером. Сервер находит бронирование, получает программу и сохранённые условия, проверяет право пользователя и только после этого формирует запрос в ЮKassa. Это не позволяет подменить стоимость простым изменением данных на странице. В метаданных используется внутренний идентификатор, по которому ответ связывается с конкретной заявкой.

Webhook сообщает об изменении статуса, но сам входящий запрос не считается достаточным основанием для всех последующих действий. Обработчик проверяет формат события и затем запрашивает актуальное состояние платежа у ЮKassa. Только подтверждённый результат переводит бронирование в оплаченный статус, фиксирует сумму и разрешает создание договора.

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

Полная оплата, предоплата и остаток

Режим задаётся для программы. При полной оплате сумма заявки и платежа совпадает. При предоплате сервер рассчитывает требуемую часть по настройке и сохраняет одновременно три значения: полную стоимость, фактически оплаченную сумму и остаток. Это позволяет корректно показать условия в кабинете и подставить их в документ.

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

Возврат к незавершённой оплате

Закрытое окно ЮKassa не всегда означает отказ. Пользователь мог отвлечься, потерять соединение или перейти назад. Пока бронь и платёж остаются допустимыми, система предлагает продолжить существующую операцию. Она не генерирует новую заявку при каждом открытии страницы и не засоряет кабинет дублями.

Перед продолжением сервер снова сверяет статус. Если платёж уже прошёл, пользователь получает результат и доступные документы. Если он отменён или бронь истекла, место освобождается, а интерфейс предлагает выбрать актуальный слот. Поведение определяется состоянием на сервере, а не тем, какой экран последним видел посетитель.

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

После оплаты учебному отделу не нужно заново переносить ФИО, программу, даты и сумму в отдельный документ. Администратор заранее загружает DOCX-шаблон и размещает в нём понятные переменные. Когда платёж подтверждён, система берёт данные связанной заявки и создаёт заполненный файл.

В шаблон можно подставить имя слушателя, название программы, дату или период обучения, место проведения, полную стоимость, сумму предоплаты, остаток и код бронирования. Переменные отделяют оформление документа от кода: учебный центр может поддерживать нужную структуру договора, не меняя алгоритм заполнения для каждого нового курса.

Готовый DOCX доступен для скачивания и последующего подписания. Система не заявляет, что документ подписан автоматически: она устраняет ручное копирование данных и подготавливает согласованный файл для дальнейшего документооборота.

Отдельные кабинеты для слушателя и учебного отдела

У разных участников проекта разные задачи, поэтому выдавать всем одинаковый доступ к WordPress было бы неправильно. В системе разделены роль слушателя, администратор учебного отдела и системный администратор. Каждая роль видит только те экраны и действия, которые нужны для её работы.

Рабочее место учебного администратора

Frontend-админка построена вокруг регулярных операций, а не вокруг внутренней терминологии WordPress. На стартовом экране сотрудник видит программы и заявки, использует поиск и фильтры, переходит к редактированию и понимает текущий статус. Для создания курса собраны поля публичного описания, формата, контактов, оплаты, регистрационной анкеты, договора и расписания.

Заявка показывает данные слушателя, выбранные условия, платёжное состояние и дополнительные поля. Администратор может скорректировать разрешённую информацию и сменить статус, когда действие происходит вне автоматического сценария. Например, подтвердить обращение без онлайн-оплаты после звонка. Ручное изменение не стирает связь с исходной программой и пользователем.

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

Кабинет слушателя

Кабинет нужен не как декоративная «закрытая зона», а как постоянная точка возврата. Здесь пользователь авторизуется, проверяет профиль и работает со своими записями. Если оплата была прервана, дальнейшее действие связано с существующим бронированием; если она подтверждена, отображается актуальный результат.

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

Служебные письма и контроль отправки

Запись на обучение сопровождается сообщениями: доступ к кабинету, сброс пароля, подтверждение бронирования, результат оплаты и уведомление о запросе юридического лица. Тексты вынесены в шаблоны, чтобы разные события не превращались в одно универсальное и непонятное письмо.

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

Журналирование также помогает отделить ошибку интерфейса от сбоя почтового соединения. Если сообщение можно безопасно отправить повторно, сотруднику не приходится создавать новую заявку или просить слушателя проходить регистрацию заново. Это снижает количество ручных обходных действий вокруг основной системы.

Дополнительная защита публичного сайта и кабинетов

Проект работает с профилями, заявками и платёжными состояниями, поэтому проверки нельзя оставлять только в браузере. На серверной стороне добавлены разграничение ролей, проверка прав, nonce для предусмотренных операций, ограничения авторизации и защита чувствительных REST-маршрутов.

Критические действия проверяют пользователя и состояние сущности повторно. Контроль повторных запросов снижает риск двух платежей или конфликтующих изменений одной заявки, а журналирование сохраняет информацию, необходимую для разбора ошибок. Учебная роль не получает доступ к секретным настройкам только потому, что пользователь знает адрес системной страницы.

Защитные меры внутри плагина являются частью многоуровневого подхода, а не обещанием абсолютной неуязвимости. Они не заменяют обновления WordPress и зависимостей, резервные копии, безопасную серверную конфигурацию и внешний контроль периметра. Такая граница важна и технически, и честно по отношению к заказчику.

Проверка выполняется там, где принимается решение

Браузерная валидация помогает человеку заметить ошибку, но не является защитой. Значения цены, роли, идентификатора пользователя и разрешённого перехода проверяются сервером. Если клиент отправляет неполный или изменённый запрос, операция завершается без изменения бронирования, а интерфейс получает безопасное сообщение.

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

Эксплуатация остаётся частью безопасности

Даже хорошо написанный модуль требует обновлений, контроля резервных копий и наблюдения за журналами. В административной части предусмотрены сигналы о необходимости поддерживать ядро в актуальном состоянии. Регулярная проверка нужна и после изменений в ЮKassa, почтовой инфраструктуре или серверной конфигурации, потому что безопасность проекта зависит от всей цепочки, а не от одного плагина.

Отдельный режим отображения для слабовидящих

На публичном сайте реализована панель, которая позволяет менять представление контента под индивидуальные потребности пользователя. Можно увеличить текст, выбрать цветовую схему, изменить показ изображений, интервалы и шрифт, а затем вернуться к обычной версии.

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

Корректная формулировка результата — режим расширяет доступность сайта. Заявлять полное соответствие WCAG или ГОСТ без отдельного формального аудита было бы неточно, поэтому в кейсе такого обещания нет.

После запуска учебный отдел получил инструкцию со скриншотами

Сложная система полезна только тогда, когда сотрудники понимают регулярные операции. Поэтому вместе с проектом подготовлена пошаговая инструкция на 11 страниц. Она показывает вход администратора учебки, создание программы, настройку формата и оплаты, загрузку договора, управление слотами, выбор полей регистрации и размещение шорткода.

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

Документация снижает зависимость от разработчика в ежедневных задачах. Учебный отдел может самостоятельно добавлять программы, актуализировать расписание и вести заявки. За технической поддержкой остаются изменения архитектуры, интеграций и новые функции, а не каждое редактирование даты.

Передача — это проверяемый процесс

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

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

После обновлений меняются не все страницы руководства, а только затронутые сценарии. Номер версии помогает отличить актуальное описание от старого. Такой подход проще поддерживать, чем большой документ без привязки к релизу, в котором сотрудник не может понять, почему увиденная кнопка отличается от инструкции.

Сайт работает как единая система

В результате Jet Service получил публичный сайт и связанную с ним рабочую платформу. Программа существует не отдельно от расписания, заявка — не отдельно от пользователя, а платёж — не отдельно от договора. Связи между сущностями позволяют проходить путь последовательно и сохранять контекст на каждом шаге.

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

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

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

Не только страницы, но и логика под процессы

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

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

Когда стандартных возможностей платформы недостаточно, выполняю кастомную доработку WordPress: проектирую сущности и роли, создаю интерфейсы, подключаю API, оплаты и документы. Чтобы определить разумный состав первого этапа, достаточно обсудить проект и показать текущий процесс.

Когда подобная платформа действительно нужна

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

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

На первой встрече я прошу показать путь одной заявки: от вопроса посетителя до зачисления, оплаты и документа. Затем отмечаем ручные передачи данных, исключения и ответственных. Из этого получается не список модных функций, а схема модулей с понятными границами. Именно она помогает оценить, какие части запускать вместе, а какие разумно оставить следующим этапом.

До оценки фиксируем также источники контента, ответственных за расписание, правила хранения данных и обязательные интеграции. Это позволяет заранее заметить зависимости, подготовить реалистичный план запуска и не переносить критические решения на момент, когда интерфейсы уже собраны.

Частые вопросы о разработке сайта учебного центра