# Контекст
В логистике всё держится на предсказуемости: машина должна выйти в рейс, доехать, вернуться и снова быть готовой к работе. На деле же каждая поломка начиналась одинаково: звонок, голосовое, сообщение в общем чате.
Кто‑то записал проблему в таблицу, кто‑то забыл, кто‑то «обязательно занесёт потом». Через пару месяцев никто не мог честно ответить на вопрос:
# Задача
Заказчику нужен был не очередной «портал для галочки», а рабочий инструмент:
# Архитектура
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ ВОДИТЕЛИ │ │ МЕХАНИКИ │ │ АДМИНЫ │
│ (MAX Bot) │ │ (Web Panel) │ │ (Web Panel) │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
└───────────────────────┼───────────────────────┘
│
┌────────────▼────────────┐
│ REST API │
│ (Express.js + Auth) │
└────────────┬────────────┘
│
┌────────────▼────────────┐
│ SQLite DB │
│ (заявки, авто, юзеры) │
└─────────────────────────┘
# Решение
→ Бот для водителей
- Работает в MAX — там, где команда общается каждый день
- Пошаговый сценарий: номер авто → пробег → тип → описание
- Для водителя это диалог, для системы — структурированная заявка с ID
→ Веб-панель для механиков и админов
# Технические особенности
notifications
Уведомления админов через MAX-бота с гибкой настройкой событий
database
Оптимизированная SQLite: индексы по ключевым полям для быстрого API
frontend
SPA-подход: динамическая загрузка через Fetch API без тяжёлых фреймворков
scaling
План миграции на PostgreSQL при росте нагрузки
# Результат
Заявки перестали теряться в чатах: у каждой есть ID, статус, автор
Руководство увидело реальную картину: какие машины тянут бюджет вниз
Водителям не нужно осваивать новый интерфейс — просто пишут боту
У механиков появился единый инструмент вместо десятка чатов