Сайт паромной переправы без админки: контентом управляет Telegram-бот вместо CMS

Есть распространённое убеждение: если у сайта меняется контент, значит, нужна CMS — админка с логином, разделами, полями и кнопкой «Сохранить». В большинстве случаев это верно. Но иногда честный вопрос «кто и как будет этим пользоваться?» приводит к другому ответу. Именно так вышло с этим проектом.

Заказчик — ООО «Грузовая переправа», оператор грузовой паромной переправы через Волгу между Камышином и Николаевском. Задача формулировалась просто: официальный сайт, на котором посетитель видит актуальное расписание рейсов, тарифы и статус навигации. А управлять всем этим должен один человек — диспетчер, у которого нет ни времени, ни желания осваивать веб‑панель.

Почему классическая CMS здесь избыточна

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

1. Расписание рейсов — время отправлений из Камышина и Николаевска.
2. Прайс — 34 категории транспорта, от легкового автомобиля до комбайна.
3. Баннер навигации — сообщение вроде «Навигация приостановлена до апреля».

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

Зато Telegram у диспетчера всегда открыт. Отсюда и родилась главная идея проекта:

Отдать управление контентом в Telegram-бот, а сайт оставить быстрым лендингом, который сам подтягивает свежие данные.

Сайт: быстрый лендинг, который не падает без сервера

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

Но интереснее не то, что видно, а как это устроено под капотом. Здесь заложено одно важное инженерное решение: сайт продолжает работать, даже если сервер с данными недоступен.

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

sequenceDiagram
    participant U as Посетитель
    participant SPA as Сайт
    participant API as Сервер
    participant DB as База

    U->>SPA: открывает сайт
    SPA->>SPA: показывает запасные данные (мгновенно)
    SPA->>API: запрос за свежим контентом
    alt Сервер доступен
        API->>DB: чтение контента
        DB-->>API: расписание, прайс, баннер...
        API-->>SPA: свежие данные
        SPA->>SPA: обновляет экран
    else Сервер недоступен
        API--xSPA: таймаут / ошибка
        SPA->>SPA: остаётся на запасных данных (без ошибок)
    end

Для бизнеса это значит простую вещь: сайт переправы не показывает «белый экран» в самый неподходящий момент. Техника здесь — современный фронтенд (React) и лёгкая сборка, но для читателя важен результат: страница открывается быстро и всегда.

Главное: Telegram-бот вместо CMS

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

Быстрые действия — в одно‑два нажатия

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

mindmap
  root((Бот вместо CMS))
    Быстрые действия
      Открыть навигацию
      Закрыть навигацию
      Отменить рейс
      Срочное объявление
    Баннер
      4 готовых шаблона
      Ручной ввод
    Расписание
      Ввод текстом
      Предпросмотр и подтверждение
    Прайс
      Правка одной позиции
      Массовая загрузка
    Контакты и галерея
      Телефоны, адрес
      Загрузка фото
    Надёжность
      История изменений
      Откат к прошлой версии
      Аудит-лог
    Аналитика
      Сводка Яндекс.Метрики

Расписание и прайс — обычным текстом

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

Камышин: 08:00, 15:00
Николаевск: 09:00, 16:00
Действует с 25.11.2025

Бот сам разбирает это сообщение: понимает направления, проверяет время и дату, собирает пары рейсов «туда‑обратно». Формат при этом гибкий — двоеточие можно и пропустить, бот всё равно поймёт. Прайс задаётся так же построчно, в формате «категория — цена», по одной позиции на строку.

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

stateDiagram-v2
    [*] --> Меню
    Меню --> ВыборШаблона: «Баннер»
    ВыборШаблона --> Опубликовано: готовый шаблон
    ВыборШаблона --> ВводТекста: «Ввести вручную»
    ВводТекста --> Предпросмотр
    Предпросмотр --> Опубликовано: «Опубликовать»
    Предпросмотр --> Меню: «Отмена»
    Опубликовано --> [*]

Надёжность: история изменений, откат, аудит

Когда контентом управляет один человек с телефона, важна страховка от случайной ошибки. Она встроена на уровне логики.

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

Плюс бот раз в несколько минут проверяет, жив ли сайт, и если тот перестал отвечать — сразу пишет предупреждение администраторам. Проблему замечают не посетители, а команда.

flowchart TD
    CHANGE["Изменение через бота"] --> SVC["Сервис контента"]
    SVC --> WRITE["Публикация на сайт"]
    SVC --> REV["+ снимок версии"]
    SVC --> AUDIT["+ запись в журнал<br/>(до / после)"]
    REV --> ROLLBACK["Откат = публикация<br/>прошлой версии"]
    HEALTH["Проверка сайта раз в 5 мин"] -->|сайт не отвечает| ALERT["Уведомление админам"]

Заявки с сайта — прямо в рабочий чат

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

Аналитика — по кнопке в том же боте

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

Что в итоге получилось

Собрался не «просто лендинг», а компактная система:

Что заменил Telegram-бот	Как раньше	Как сейчас
CMS / админку	Логин, разделы, поля, обучение	Кнопки и текст в мессенджере
Почту для заявок	Письма, которые не читают	Сообщение сразу в рабочий чат
Кабинет аналитики	Отдельный вход, графики	Сводка по кнопке в чате

При этом сайт открывается быстро и не падает без сервера, а каждое изменение обратимо и записано в историю.

Правильный интерфейс управления — не всегда веб‑админка

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

Здесь оператор — один занятой диспетчер, у которого Telegram всегда под рукой. Для него самый удобный «продукт» уже стоит на телефоне. Задача была не навязать ему новую программу, а грамотно встроиться в привычный инструмент — и при этом не потерять надёжность, историю изменений и обратимость операций, которые обычно и оправдывают существование тяжёлой CMS.

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

Как это выглядит

Посмотреть вживую

Перейти на сайтgrp134.ru Исходники на GitHubGRP134.ru

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