Серия «Вайбкод колхозника»

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

Вот тогда я и решил: надо писать свое.

Первые шаги: парсеры и база конкурентов

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

Это оказалось сложнее, чем я думал. Пришлось научиться писать парсеры — программы, которые собирают данные с сайтов и карт. Сначала делал статические, потом научился делать динамические. Парсил Яндекс.Карты, 2ГИС, Авито, собирал отзывы, телефоны, адреса, сайты. В итоге база разрослась до более чем 2700 сервисов.

Дальше — анализ. Нужно было понять, какие услуги предлагают конкуренты, какую долю рынка они занимают и что вообще ищут клиенты. Для этого я использовал статистику Авито, Яндекс Вордстат и анализировал отзывы.

Тут мне пригодился DeepSeek. Я написал свои модули, которые через API этой нейросети обрабатывали все собранные данные и формировали по каждому конкуренту резюме: какие услуги он предлагает, сколько зарабатывает, что о нем пишут клиенты. Работает это так: вы вставляете данные в модель, указываете задачу, и нейросеть выдает структурированный ответ.

Переход к онлайн-записи

В феврале 2026 я окончательно решил отказаться от YClients и писать свою систему онлайн-записи. Для этого пришлось освоить Python и фреймворк Flask.

Деплой на Beget: отдельная песня

Когда код был готов, встал вопрос: куда это все разместить? Выбрал хостинг Beget — у них есть поддержка Python приложений и удобный SSH доступ.

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

1. Включаю SSH в настройках хостинга

2. Подключаюсь через терминал, захожу в Docker

3. Создаю виртуальное окружение, активирую его

4. Устанавливаю Flask и другие библиотеки

5. Настраиваю файлы `.htaccess` и `passenger_wsgi.py`

6. После каждого изменения делаю `touch tmp/restart.txt`, чтобы перезапустить приложение

Сложнее всего было с правами на файлы и кодировкой. Я трижды переписывал конфигурационные файлы, прежде чем все заработало.

Подводя итог

За 3 месяца я прошел путь от полного нуля до собственной системы онлайн-записи, которая:

- собирает и анализирует информацию о 2700 конкурентах;

- принимает записи с автоматическим выбором бокса;

- показывает свободные слоты с учетом загрузки;

- отправляет уведомления клиентам и в Telegram;

- генерирует динамические скидки.

Если честно, в начале я даже не представлял, что все это возможно. DeepSeek здорово помогал на всех этапах — и с кодом, и с анализом данных, и с поиском ошибок.

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

Самое интересное здесь — структура боксов. В YClients была просто запись на время, а мне нужно было разделить места в мастерской: есть обычный "Бокс услуг", есть "Бокс эстакады" для подвески, и есть "Бокс подъемников", который внутри делится на 4 отдельных места (Подъемник 1, Подъемник 2, Рабочее место 1, Рабочее место 2).

Вот это поле parent_id — ключевое. Оно позволяет создавать вложенность: один бокс может быть родителем для других. Так "Бокс подъемников" стал родителем для "Подъемник 1", "Подъемник 2" и так далее.

Это нестандартное решение, потому что в типовых системах обычно просто перечисляют все места записи плоским списком. А тут — иерархия!

2. Модуль бизнес-логики (app.py)

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

Основные функции:

- /api/available-slots — ищет свободные слоты для записи. Сначала проверяет все боксы, затем исключает занятые и заблокированные. Учитывает скидки и автоматически назначает бокс, если для услуги он задан по умолчанию.

- /booking — создает запись, сохраняет в базу и запускает уведомления.

- /operator/* — панель управления (все админские штуки защищены декоратором @Operator_required).

3. Модуль уведомлений (встроен в app.py)

Отдельного файла для уведомлений нет, но логика там серьезная. Есть две функции:

send_telegram_notification() — отправляет оператору сообщение в Telegram. Формирует красивое HTML-сообщение с деталями записи.

send_client_email() — отправляет клиенту письмо с подтверждением записи. Там целый HTML-шаблон с логотипом, деталями и важными инструкциями. Используется SMTP-сервер Mail.ru — я завел отдельную почту специально для этих целей.

Интересная деталь: я сделал так, что если клиент не указал email, письмо просто не отправляется. Это позволяет не спамить тем, кто не хочет получать уведомления.

4. Модуль парсинга и анализа конкурентов (отдельная система)

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

- Собирает данные с Яндекс.Карт и 2ГИС — названия, адреса, телефоны, сайты.

- Парсит отзывы с этих карт и социальных сетей.

- Собирает статистику с Авито — какие услуги предлагают конкуренты и сколько они зарабатывают.

- Использует Яндекс Вордстат — чтобы понять, что ищут клиенты (например, "замена тормозных колодок цена").

- Передает все это в нейросеть DeepSeek через API, и та выдает резюме по каждому конкуренту — услуги, цены, отзывы, доля рынка.

5. Планировщик динамических скидок

Это отдельный демон, который запускается вместе с приложением. Он использует библиотеку APScheduler и делает две вещи:

- Ежедневно в 05:00 — генерирует скидки на основании прогноза погоды и текущей загрузки.

- Каждый час — корректирует скидки, если изменилась ситуация.

Как работает логика скидок? Если на улице мороз или дождь, люди реже едут в сервис. Значит, нужно их привлечь скидкой. Если загрузка низкая — тоже скидка. В итоге у меня есть система, которая в реальном времени подстраивает цены под спрос.

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

1. Автоматический выбор бокса по умолчанию

Когда клиент выбирает услугу, система автоматически назначает бокс. Например, если выбрали "Ремонт тормозной системы", автоматически назначается "Подъемник 1". Клиент вообще не видит выбор бокса — это решается на бекенде.

Я сделал так, потому что в YClients клиент выбирал время, а потом мучился с выбором мастера, места и т.д. У меня все просто: клиент выбирает услугу и время — система сама понимает, где это можно сделать.

2. Иерархия боксов через self-referencing foreign key

Я уже упоминал это решение — поле parent_id, которое ссылается на ту же таблицу work_bay. Это позволяет строить деревья любой вложенности. По сути, я реализовал структуру "категория → подкатегория → элемент" прямо внутри одной таблицы.

Это позволило мне создать группу "Бокс подъемников" и вложить в нее четыре дочерних места. При этом оператор может в один клик отключить всю группу или отключить отдельное место.

3. Двойной API для дополнительных услуг

Обычно список дополнительных услуг грузится прямо в карточке основной услуги. Я пошел дальше: сделал отдельную страницу /operator/services/<id>/addons, где оператор может в удобном интерфейсе добавлять, редактировать и сортировать доп. услуги, а для клиентской части сделал отдельный API-эндпоинт, который отдает только активные услуги в правильном порядке.

Такой подход позволил разделить управление и отображение. Оператору удобно, клиенту быстро.

4. Отслеживание ухода клиентов с сайта

Я добавил модуль статистики, который записывает, на каком этапе клиент бросил запись. Если человек начал выбирать услугу, но через 60 секунд бездействия закрыл вкладку — появляется опрос "Почему вы не записались?". Это помогает улучшать интерфейс.

Как все это связано между собой

Вот упрощенная схема:

1. Клиент заходит на сайт, выбирает мастерскую, услугу, дату и время.

2. Модуль app.py ищет свободные слоты в БД (с учетом боксов и скидок).

3. Если клиент оставляет заявку — создается запись в БД, модуль уведомлений отправляет письмо клиенту и Telegram-сообщение оператору.

4. Планировщик каждую ночь анализирует загрузку и прогноз погоды и обновляет скидки.

5. Модуль анализа конкурентов собирает данные и помогает корректировать цены и услуги.

Сложности, с которыми я столкнулся

Написание кода — это половина дела. Вторая половина — заставить это работать на сервере.

- Настройка Beget — пришлось потратить время, чтобы разобраться с виртуальным окружением, правами на файлы и Passenger. Три раза переписывал конфигурацию!

- Кодировка — на сервере стояла locale с отличной от моей, из-за чего некоторые символы отображались кракозябрами. Лечится через export LC_ALL="en_US.UTF-8".

- SQLite на сервере — не хотел ставить PostgreSQL, потому что для моих объемов SQLite хватает за глаза. Но пришлось настроить права на запись в папку с БД.

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

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

3. Анализирует историю — если в прошлом году в этот день было мало клиентов, система запоминает этот паттерн.

Логика расчета скидки

Вот как это работает в коде: если температура ниже минус 15 градусов, система добавляет 10 процентов скидки. Если при этом вероятность осадков выше 60 процентов — добавляет еще 10. В итоге в сильный мороз и снегопад скидка может достигать 20 процентов.

Если температура ниже 5 градусов и вероятность осадков выше 70 процентов — скидка 15 процентов.

Если скорость ветра выше 25 километров в час — добавляется еще 5 процентов.

Если загрузка мастерской меньше 30 процентов — добавляется еще 10 процентов.

Максимальная скидка ограничена 25 процентами.

В итоге в плохую погоду скидка может достигать 25 процентов. Это привлекает клиентов, которые в нормальных условиях не поехали бы.

Отображение клиенту

Когда клиент заходит на сайт и выбирает дату, он видит слоты с подсвеченными скидками:

- Скидка 5 процентов — голубой фон

- Скидка 10 процентов — желтый фон

- Скидка 15 процентов и выше — красный фон

Это визуально привлекает внимание и стимулирует выбирать менее загруженные слоты или дни с плохой погодой.

Защита от взлома: сделано по-серьезному

Безопасность я продумывал с самого начала. Вся система закрыта от несанкционированного доступа, и вот как это реализовано.

1. Сессии и декораторы

В Flask для защиты маршрутов используется механизм сессий и декораторов. Я сделал декоратор @Operator_required, который проверяет, авторизован ли пользователь. Все админские маршруты защищены этим декоратором. Если кто-то попытается зайти в панель оператора без авторизации — его перебросит на страницу логина.

2. Хранение паролей

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

3. Защита форм от CSRF

Я использовал Flask-WTF для защиты форм. Каждая форма содержит скрытый токен, который проверяется на сервере. Это предотвращает подделку межсайтовых запросов.

4. SQL-инъекции

Все запросы к базе данных я делаю через SQLAlchemy — это ORM, которая автоматически экранирует вводимые пользователем данные. Грубо говоря, если кто-то попытается ввести зловредный код в поле ввода, SQLAlchemy превратит это в строку, а не в часть SQL-запроса.

5. Пароль по умолчанию меняется

При первом запуске системы создается пользователь admin с паролем admin123. Но я настоятельно рекомендую сменить этот пароль при первом входе. В панели оператора есть отдельная страница для смены пароля.

Как я настраивал Beget (и что пошло не так)

Самый сложный этап — это деплой на хостинг. Beget — хорошая площадка, но для приложений на Flask она требует определенной конфигурации.

Моя схема подключения

Я подключался по SSH, создавал виртуальное окружение, активировал его, устанавливал Flask и другие библиотеки, копировал файлы приложения.

Настройка Passenger

На Beget используется Passenger — это веб-сервер для приложений на Ruby и Python. Чтобы он запускал мое приложение, я создал файл passenger_wsgi.py, который указывает на app.py, и добавил в .htaccess настройки для Passenger.

Грабли на Beget

Вот три вещи, которые заставили меня понервничать:

1. Кодировка. На Beget по умолчанию локаль — ru_RU.UTF-8, которая не поддерживает все символы. Чтобы русские названия не отображались кракозябрами, пришлось добавить в passenger_wsgi.py принудительную установку локали en_US.UTF-8.

2. Права на папку с БД. SQLite создает файл базы данных в папке проекта. Но Beget запрещает запись в некоторые папки. Пришлось создать папку instance и вручную дать права на запись.

3. Убийство процесса. Passenger иногда зависает при изменениях кода. Чтобы перезапустить приложение без перезагрузки сервера, достаточно создать пустой файл tmp/restart.txt.

Что делать при атаке?

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

- Неудачные попытки входа в панель (их можно отследить по логам Nginx).

- Подозрительные запросы — например, слишком частые запросы к API со одного IP.

- Попытки доступа к админским маршрутам без авторизации.

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

Итог

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

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

Как я парсил данные

1. Источники данных

Я использовал несколько источников:

Яндекс.Карты — основная база: названия, адреса, телефоны, сайты, часы работы, рейтинги.

2ГИС — дополнительная информация и проверка данных.

Авито — объявления об услугах, чтобы понять, что предлагают и за сколько.

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

Отзывы — с Карт, 2ГИС, ВКонтакте и Телеграм-каналов. Чтобы понять, что клиентов раздражает, а что хвалят.

2. Динамические парсеры

Сначала я писал простые статические парсеры. Загружаешь страницу, вытаскиваешь данные, сохраняешь. Но Яндекс.Карты и Авито подгружают данные через JavaScript. Если просто скачать HTML страницы, там будет неполная информация.

Пришлось осваивать динамический парсинг. Вместо обычного HTTP-запроса я использовал библиотеку Selenium — она эмулирует реальный браузер, загружает страницу, ждет, пока подгрузятся все элементы, и потом собирает данные.

Проблема: Selenium медленный. На парсинг всех 2700 сервисов уходило несколько часов. Я сделал так: разбил город на районы (около 600 районов) и запускал парсер для каждого района отдельно. Это ускорило процесс.

3. Сбор статистики с Авито

Авито — отдельная история. Там люди выкладывают объявления с ценами на услуги. Я парсил объявления в категории "Услуги автосервиса", собирал название услуги, цену, район, и выводил среднюю цену по каждой услуге.

Это помогло понять, сколько берут конкуренты за замену масла, диагностику или ремонт подвески.

4. Анализ отзывов

Это была самая интересная часть. Я собирал все отзывы о каждом сервисе (до 500 отзывов на каждый) и анализировал их с помощью нейросети.

DeepSeek API работал так: я загружал в модель 50-100 отзывов и просил выделить основные паттерны. Например, написать 5 самых частых жалоб клиентов в этом сервисе, определить какие услуги чаще всего упоминаются в отзывах, вычислить средний рейтинг на основе отзывов.

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

Как я организовал хранение данных

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

Как я вычислял долю рынка по каждой услуге для каждого автосервиса

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

Первый шаг — я сопоставил парсинг с официальной статистикой и живыми цифрами из Вордстата. Например, по запросу "замена масла" в Яндексе выходит около 56 тысяч запросов в месяц. Но не все, кто ищет, поедут менять масло в этом же месяце. Кто-то изучает цены, кто-то сравнивает сервисы, кто-то планирует на следующий месяц. По моей оценке, реальный спрос в Петербурге — около 15-20 тысяч замен масла в месяц, плюс еще часть аудитории ищет в Гугле. Общий объем рынка по замене масла я оцениваю примерно в 6-8 миллиардов рублей в год — и это только Петербург.

Второй шаг — я перевел спрос на услуги через пробег. Количество зарегистрированных автомобилей в Петербурге — около 1,8 миллиона. Средний пробег — 15-20 тысяч километров в год. Замена масла делается каждые 10-15 тысяч километров. Это дает 1,5-2 замены масла на машину в год, то есть примерно 2,7-3,6 миллиона замен масла в год по городу. Умножаем на среднюю цену 2500-3500 рублей — получаем те же 6-8 миллиардов рублей.

Третий шаг — я распределил этот спрос между сервисами, используя алгоритм, который учитывает несколько факторов. Каждый фактор имел свой вес. Количество отзывов — вес 0,4, потому что чем больше отзывов, тем больше клиентов. Количество объявлений на Авито — вес 0,2, потому что это показатель активности. Рейтинг — вес 0,2, потому что высокий рейтинг привлекает больше клиентов. Упоминаемость в соцсетях — вес 0,2, потому что это показатель узнаваемости. Район и плотность конкурентов — корректирующий коэффициент, который я добавил на основе анализа Вордстата по районам.

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

Четвертый шаг — я прогнал все это через нейросеть DeepSeek для валидации. Я загружал в модель список сервисов с их параметрами и просил проверить, насколько логично распределение. Нейросеть несколько раз корректировала коэффициенты, и после 3-4 итераций алгоритм вышел на стабильные значения, которые хорошо коррелировали с рыночной интуицией.

В итоге по каждому сервису я получил долю рынка по каждой услуге в процентах и в денежном выражении. Например, если сервис занимает 2% рынка по замене масла, а объем рынка по замене масла — 7 миллиардов рублей, то его выручка по этой услуге — 140 миллионов рублей в год. Конечно, это приблизительная цифра, но она дает понимание масштаба.

Сопоставление с Вордстатом

Я прогнал через Яндекс Вордстат несколько сотен запросов по автосервисной тематике и сопоставил с тем, что реально предлагают конкуренты. Получилась четкая картина структуры рынка.

Диагностика — 10-12 тысяч запросов в месяц по Яндексу. Реальный спрос я оцениваю в 3-5 тысяч диагностик в месяц, объем рынка — 2-3 миллиарда рублей в год. В моей базе диагностику предлагают 70% сервисов.

Замена масла — 56 тысяч запросов в месяц по Яндексу. Реальный спрос — 15-20 тысяч замен в месяц. Объем рынка — 6-8 миллиардов рублей в год. В базе замену масла предлагают 85% сервисов. Это самая массовая услуга.

Ремонт подвески — около 30 тысяч запросов в месяц в пиковые месяцы. Реальный спрос — 5-7 тысяч ремонтов в месяц. Объем рынка — 4-5 миллиардов рублей в год. В базе ремонт подвески предлагают 45% сервисов.

Замена колодок — около 20 тысяч запросов в месяц круглый год. Реальный спрос — 3-5 тысяч замен в месяц. Объем рынка — 2-3 миллиарда рублей в год. В базе — 65% сервисов.

Шиномонтаж — 80-100 тысяч запросов в апреле и октябре. Это абсолютный лидер по сезонности. Реальный спрос — 20-30 тысяч шиномонтажей в месяц в сезон. Объем рынка — 1,5-2 миллиарда рублей за сезон. В базе шиномонтаж предлагают 50% сервисов.

Эти цифры коррелируют с логикой: чем проще услуга, тем больше сервисов ее предлагают, но тем ниже маржинальность. Чем сложнее услуга, тем меньше сервисов, но выше чек. Разница между поисковыми запросами и реальным спросом составляет примерно 3-4 раза, и это важно учитывать при планировании.

Как все это автоматизировано

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

DeepSeek используется на этапе обработки отзывов и валидации расчетов. Я не храню в базе сырые отзывы — только их резюме, сгенерированное нейросетью. Это экономит место и упрощает анализ.

Система также отслеживает изменения: если у конкурента резко выросло количество отзывов или он добавил новые объявления на Авито, это фиксируется как событие. Я получаю уведомление и могу проанализировать, что изменилось.

Что я получил в итоге

База выросла до 2700 автосервисов в Петербурге. По каждому из них есть:

- Контактные данные (телефон, адрес, сайт, координаты)

- Список услуг и их средняя цена

- Количество отзывов и средний рейтинг

- Резюме того, что пишут в отзывах

- Доля рынка по каждой услуге в процентах и в деньгах

Как я использовал эти данные

1. Корректировка цен. Если средняя цена на замену масла у конкурентов — 2500 рублей, а я брал 3000 рублей — я скорректировал цену, чтобы быть конкурентным, но не демпинговать. При этом на более сложные услуги (ремонт подвески) я цены не трогал — там важнее квалификация, чем цена.

2. Добавление новых услуг. Оказалось, что многие конкуренты предлагают услугу "измерение биения тормозных дисков", а у меня ее не было. Пришлось добавить. Шиномонтаж я вообще не делал, но после анализа спроса решил добавить как сезонную услугу.

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

4. Выбор местоположения. В некоторых районах плотность сервисов меньше, а спрос большой. Это помогло принять решение, где открывать следующую мастерскую.

Что было сложнее всего

Борьба с антибот-системами. Яндекс.Карты и Авито не особо рады парсерам. Приходилось менять User-Agent, использовать прокси, делать паузы между запросами. Если сайт блокирует — ты вылетаешь на несколько часов.

Обработка неструктурированных данных. Цены в объявлениях могут быть написаны по-разному: "5000 руб", "5 т.р.", "от 5000" и так далее. Пришлось написать отдельный модуль для нормализации цен.

Затраты на нейросеть. DeepSeek — дешевый, но не бесплатный. На обработку всех 2700 сервисов ушло около 5 долларов. Много? По сравнению с тем, что я получил — копейки.

В следующем посте расскажу про SMS-шлюз и как я подключал уведомления по SMS. Если есть вопросы — пишите в комментарии.

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

Триггеры для отправки

SMS отправляются не всегда, а в трех случаях:

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

2. Напоминание за день — я добавил планировщик, который раз в день проверяет, у кого запись на завтра, и отправляет SMS-напоминание. Это снизило количество неявок примерно на 30 процентов.

3. Отмена записи — если оператор отменяет запись, клиент получает SMS с уведомлением, чтобы не приехал зря.

Это перекрывает все основные сценарии. Клиент всегда знает, что происходит.

Сколько это стоит

SMS-шлюз берет около 0.5 рубля за сообщение. В месяц я отправляю около 200-300 SMS, это примерно 100-150 рублей. За эти деньги я получаю:

- Минимум пропущенных записей (клиенты не забывают)

- Минимум недовольных клиентов (все знают, что делать)

- Экономию времени менеджера (не нужно обзванивать всех накануне)

Окупается с лихвой.

Telegram-бот для записи

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

Как он работает

1. Клиент пишет боту команду /start

2. Бот показывает кнопки: "Записаться", "Мои записи", "Контакты"

3. При выборе "Записаться" бот запрашивает мастерскую, услугу, дату и время

4. Проверяет свободные слоты через API системы

5. Подтверждает запись и отправляет уведомление оператору

Бот написан на библиотеке python-telegram-bot. Это очень гибкая библиотека, которая поддерживает и команды, и кнопки, и обработку callback-запросов.

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

Нейромодули: как я использую DeepSeek в программе

DeepSeek используется в нескольких местах системы. Я не просто вызываю API один раз — у меня есть четыре отдельных нейромодуля, каждый со своей задачей.

1. Модуль анализа отзывов (review_analyzer.py)

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

2. Модуль нормализации цен (price_normalizer.py)

Этот модуль решает проблему неструктурированных цен. На входе — текст из объявления на Авито или с сайта конкурента, например "замена масла от 2500 рублей" или "комплексная диагностика 3000-5000 руб". На выходе — нормализованная цена в рублях (одно число). Модуль использует DeepSeek для понимания контекста: если написано "от 2500", нейросеть понимает, что это минимальная цена, и возвращает 2500. Если указан диапазон, возвращает среднее. Это решило проблему, которую я не мог решить регулярными выражениями.

3. Модуль классификации услуг (service_classifier.py)

Самый сложный модуль. На входе — список услуг, которые предлагает конкурент (из объявлений, сайта, отзывов). На выходе — нормализованный список услуг из моей базы. Например, если у конкурента написано "замена масла в двигателе", модуль понимает, что это услуга "замена масла". Если написано "профилактика тормозной системы", это может быть "замена колодок", "замена тормозной жидкости" или "ремонт тормозной системы" — нейросеть определяет наиболее вероятный вариант. Без этого модуля я бы не смог сопоставлять услуги разных сервисов, потому что каждый пишет их по-разному.

4. Модуль валидации рыночных расчетов (market_validator.py)

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

Все модули работают через единый API-интерфейс DeepSeek, но с разными промптами. Я вынес их в отдельные файлы, чтобы можно было обновлять или заменять каждый независимо.

Мобильная версия: адаптивность с первого дня

Еще на этапе проектирования я решил, что сайт будет адаптивным. Сейчас 60 процентов клиентов заходят с телефона, и если сайт неудобный на мобилке — они уйдут.

Я использовал Bootstrap 5 с его grid-системой и готовыми компонентами. Все блоки корректно перестраиваются на мобильных экранах, кнопки увеличены для пальцев, шрифты читабельные.

Что я сделал специально для мобильной версии

1. Датапикер с Flatpickr. На мобильных устройствах системный календарь часто работает некорректно. Я использовал Flatpickr — легкий плагин для выбора даты, который работает и на десктопе, и на телефонах.

2. Опрос при неактивности. Если клиент начал запись, но не завершил (например, закрыл вкладку), через 60 секунд появляется опрос "Почему вы не записались?". Это помогло собрать много полезной обратной связи.

3. Сохранение данных в sessionStorage. Если клиент прервал запись, его данные (номер телефона, выбранная услуга) сохраняются в браузере. При повторном заходе он может продолжить с того же места, а не заполнять все заново.

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

Итог

SMS-уведомления, Telegram-бот и мобильная версия сделали систему максимально доступной для клиентов. Нейромодули сделали анализ данных полностью автоматическим и значительно более точным, чем ручная обработка. Все вместе это увеличило конверсию примерно на 20 процентов.

В следующем посте расскажу про систему лояльности и как я удерживаю клиентов без классических кешбэков. Если есть вопросы — пишите в комментарии.

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

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

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

Автоматические напоминания

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

Напоминания отправляются по двум каналам: email, если клиент указал почту, и Telegram, если подключил бота.

До внедрения этой системы у меня было много клиентов, которые забывали про ТО и уходили к конкурентам. Теперь я напоминаю им за 2 недели до предполагаемой даты, и они записываются ко мне. Это работает особенно хорошо для услуги "замена масла" — интервал 10-15 тысяч километров легко отслеживать по пробегу, если клиент указывает его при записи.

Бонусные баллы за отзывы

Единственная классическая механика, которую я оставил — бонусы за отзывы. Если клиент оставляет отзыв на Яндекс.Картах или 2ГИС, он получает скидку 5 процентов на следующее посещение. Это стимулирует не только лояльность, но и улучшает рейтинг сервиса.

Система работает так: после завершения записи клиенту приходит письмо с предложением оставить отзыв. Если он оставляет отзыв и указывает номер телефона в отзыве (или присылает скриншот), менеджер вручную активирует бонус.

Сейчас я думаю над тем, чтобы автоматизировать эту систему: подключить API Яндекс.Карт и проверять, появился ли новый отзыв от клиента. Но пока это ручной процесс — и это нормально, потому что количество клиентов пока позволяет.

Результаты

За 2 месяца работы системы лояльности:

- Повторные визиты выросли на 25 процентов

- Клиенты стали чаще выбирать комплексные услуги (диагностика + ремонт)

- Напоминания вернули около 15 процентов потерянных клиентов

- Количество отзывов выросло в 2 раза

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

Что не сработало

Я попробовал добавить реферальную систему — скидку за приведенного друга. Результат был почти нулевым. Люди не хотят рекомендовать автосервис друзьям, потому что это ответственность. Если что-то пойдет не так, дружба может пострадать. Я убрал эту механику через месяц.

Итог

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

Клиент не хочет думать о том, когда ему нужно делать ТО. Он хочет, чтобы кто-то напомнил ему об этом и предложил удобное время. Именно это я и реализовал. Система работает на доверии и удобстве, а не на попытке привязать клиента скидками.

В следующем посте расскажу про кастомизацию системы под любой бизнес — не только автосервис. Если есть вопросы — пишите в комментарии.

1. Гибкая структура услуг

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

2. Универсальные боксы

Вместо "боксов" я сделал абстрактные "рабочие места". Для автосервиса это боксы, для салона — кресла, для спортклуба — залы.

У них есть иерархия: можно создать группу "Зал силовой" и вложить в нее "Тренажеры 1-10". Или "Кабинет врача" — "Кресло 1, Кресло 2". Это работает для чего угодно. Поле parent_id, которое я добавил в таблицу work_bay, позволяет строить деревья любой вложенности.

3. Гибкие настройки для каждой мастерской

Каждая мастерская (локация) может иметь свои настройки:

- Часы работы (не обязательно 10:00-22:00)

- Рабочие дни (можно работать и по воскресеньям)

- Шаг записи (я сделал 1 час, но можно 15 минут или 30)

- Максимальное время бронирования

В config.py я вынес основные параметры, чтобы их можно было менять без переписывания кода: WORKING_HOURS_START, WORKING_HOURS_END, WORKING_DAYS, SLOT_STEP_MINUTES. Это позволяет адаптировать систему под любой график работы.

4. Динамические скидки — отдельный модуль

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

5. Уведомления — можно отключить что угодно

В системе три канала уведомлений: email, SMS, Telegram. Но они не обязательны. Если бизнес не нуждается в SMS (например, интернет-магазин), можно просто отключить этот канал через настройки в config.py. Каждый канал включается отдельным флагом.

Как добавить новую мастерскую

Это делается в панели оператора за несколько кликов:

1. Ввести название

2. Ввести адрес

3. Нажать "Сохранить"

Система автоматически создает набор боксов (по умолчанию — 6 штук, но можно изменить), настройки доступности услуг в этих боксах и пустую таблицу записей.

Кастомизация парсеров и аналитики под любые ниши

Самое крутое в этой системе — это не только онлайн-запись, а гибкость парсинга и аналитики. Парсеры, которые я написал для сбора данных о конкурентах, можно адаптировать под любой рынок и любую нишу. Я покажу, как это работает.

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

- Список ключевых слов для поиска (вместо "автосервис" — "парикмахерская", "стоматология", "фитнес-клуб")

- Географические границы (можно указать любой город или регион)

- Типы источников (Яндекс.Карты, 2ГИС, Авито, профильные сайты и форумы)

- Параметры для анализа (какие услуги искать, какие цены парсить, какие отзывы анализировать)

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

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

- Набор услуг для анализа (вместо "замена масла" — "стрижка", "окрашивание", "маникюр")

- Средние цены и их диапазоны (вместо 2500-3500 рублей — 500-1500 рублей)

- Сезонные коэффициенты (вместо шиномонтажа — предновогодний ажиотаж в салонах)

- Источники данных для Вордстата (запросы подбираются под конкретную нишу)

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

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

Почему самописное ПО — это вопрос безопасности, а не удобства

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

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

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

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

Финальная структура проекта

/var/www/booking/

├── app.py # Основной файл приложения (Flask)

├── models.py # Модели данных (SQLAlchemy)

├── config.py # Конфигурация (пароли, ключи, настройки)

├── passenger_wsgi.py # Точка входа для Passenger (Beget)

├── requirements.txt # Список зависимостей

├── instance/

│ └── bookings.db # База данных SQLite

├── static/

│ └── uploads/ # Загруженные картинки

├── templates/

│ ├── client/

│ │ └── index.html

│ └── operator/

│ ├── dashboard.html

│ ├── calendar.html

│ ├── services.html

│ ├── addons.html

│ ├── work_bays.html

│ ├── service_work_bay_config.html

│ ├── discounts.html

│ ├── dynamic_discounts.html

│ ├── bookings.html

│ ├── stats.html

│ ├── visitors_stats.html

│ ├── abandon_stats.html

│ ├── settings.html

│ └── login.html

├── parser/

│ ├── yandex_parser.py

│ ├── avito_parser.py

│ └── data_analyzer.py

├── scheduler.py

└── weather_service.py

Что я понял за время разработки

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

2. Гибкость важнее функционала. Лучше сделать систему, которую можно адаптировать под разные нужды, чем зашивать все "под себя".

3. Данные — это актив. Ваша клиентская база — это самое ценное, что у вас есть. И она должна храниться у вас.

4. Клиенты ценят простоту. Чем меньше шагов нужно сделать для записи — тем больше записей.

5. Автоматизация экономит время. Напоминания, скидки, уведомления — все это работает без моего участия.

Благодарность

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

Анонс следующей серии

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