Не «сделал сайт», а постепенно собрал систему
Когда я начал глубже заниматься цифровыми процессами РЕТОН, отдельные задачи выглядели вполне локально: обновить магазин, связать каталог, передать заказ, автоматизировать один этап, сделать удобный отчёт
Но каждая рабочая задача быстро упиралась в соседнюю систему
Товар живёт в 1С. Менеджер работает в Bitrix24. Клиент приходит через сайт, чат, видео или звонок. Оплата проходит через платёжный сервис. Маркированный товар нужно связать с конкретной физической упаковкой. Руководителю нужна аналитика. Если интеграция перестала отвечать, об этом нужно узнать раньше клиента
Поэтому за несколько месяцев работа естественно выросла в набор связанных цифровых контуров
Они не собраны в один монолит и не обязаны разворачиваться одновременно. У каждого есть свои границы, состояние и способ восстановления, но вместе они продолжают общий бизнес-процесс
Моя роль
Вся работа выполняется в рамках моей роли в компании РЕТОН
Я проектирую архитектуру отдельных контуров, разрабатываю и связываю интерфейсы и интеграции, диагностирую существующие процессы, вывожу изменения в эксплуатацию и затем усиливаю их по реальному поведению системы
На публичной странице сознательно не показываю внутренние адреса, ключи, идентификаторы, персональные данные, закрытые показатели и детали, которые создают лишний риск для компании
Продажи и учёт
Основой стал интернет-магазин, но он не должен был превращаться в тонкую оболочку над 1С или CRM
Поэтому каталог получает подготовленное локальное представление данных, заказ сначала фиксируется в собственном контуре магазина, а уже затем передаётся в Bitrix24, 1С, оплату и дальнейшее исполнение
Вокруг этого появились отдельные рабочие ветки:
- импорт и нормализация каталога из 1С Fresh
- публикационный слой поверх учётной номенклатуры
- передача заказов в Bitrix24
- создание внутренних заказов менеджером
- привязка к существующей CRM-сделке без потери источника клиента
- ЮKassa и фискализация
- Data Matrix, сборка, реализация и закрывающий чек
- доставка и дальнейшая обработка заказа
Главный принцип один: пользовательская витрина не должна становиться заложником мгновенной доступности всех внешних систем
Интерфейсы для сотрудников
Не каждую задачу удобно решать стандартной карточкой CRM
Для заказов появилось собственное рабочее место менеджера: создание заказа, CRM-контекст, доставка, подготовка оплаты и коммуникации собраны вокруг реального сценария сотрудника
Для оптового направления есть другой маленький пример — собственный виджет план / факт, вынесенный прямо на главную страницу Bitrix24
Мне нравится этот кейс именно своей компактностью: он показывает, что поверх CRM можно написать удобный интерфейс под конкретную задачу, а не обязательно ограничиваться встроенными блоками
Аналитика постепенно вышла из CRM наружу
Когда вопросов к данным стало больше, чем удобно решать встроенными отчётами, появился отдельный аналитический слой
Он объединяет CRM и веб-данные и даёт самостоятельные экраны по воронкам, источникам, менеджерам, стадиям, деньгам, качеству данных и поведению на сайте
Bitrix24 при этом не заменяется. Он остаётся рабочей CRM, а аналитика получает свободу развиваться отдельно
Этот же принцип я хочу применять и дальше: сложную оркестрацию не обязательно запихивать внутрь одной платформы только потому, что она уже куплена
ИИ-консультант как часть операторской работы
На сайте работает Мария — консультационный контур, который опирается на реальное содержимое магазина, использует детерминированные маршруты там, где они надёжнее, и подключает генеративную модель для свободного ответа
Но важнее самой модели то, что происходит дальше
Когда нужен человек, диалог передаётся в Открытые линии Bitrix24, оператор видит контекст и может ответить обратно в тот же чат пользователя
То есть ИИ не создаёт отдельную тупиковую коммуникацию, а становится первым слоем существующего процесса поддержки
YouTube-комментарии тоже превращаются в операторский канал
Отдельно развивается SMM-контур
Уже работает двусторонняя ветка комментариев YouTube: сообщения собираются, классифицируются и при необходимости уходят оператору в Bitrix24. Ответ оператора возвращается в исходный тред, включая продолжение ветки
Параллельно существует более крупная система автопубликации видео в VK и YouTube. Она уже умеет часть сценариев, но пока остаётся развивающимся контуром и публично не позиционируется как законченный продукт
Долгосрочно я хочу вынести SMM-оркестрацию в отдельный интерфейс, а Bitrix оставить там, где он действительно удобен: CRM, задачи, сотрудники и Открытые линии
Мониторинг проверяет не сервер, а возможность работать
Когда систем становится много, недостаточно знать, что Nginx и процесс сайта запущены
Мониторинг постепенно стал проверять реальные точки бизнес-цепочки: доступность CRM и 1С, готовность оплаты, чат, Открытые линии, доставку, почтовую инфраструктуру и другие зависимости
Так можно различить ситуацию «сервер жив» и ситуацию «клиент реально может пройти нужный сценарий»
Отдельно фиксируются инциденты и восстановления, а сводные отчёты помогают видеть повторяющиеся проблемы
Почтовая инфраструктура выросла из реального сбоя
После серьёзной истории с прежним хостером и DDoS компания примерно два месяца оставалась без нормальной корпоративной почты, а значительную часть писем восстановить не удалось
После этого вокруг нового основного почтового провайдера появился резервный слой: собственный Roundcube, Postfix/Dovecot, автоматическое наблюдение за внешним SMTP, аварийный режим отправки и безопасная очередь
Было построено и почтовое зеркало, но его автоматическая синхронизация сейчас приостановлена после нестабильного поведения. Поэтому этот кусок я показываю честно: архитектура существует, но требует отдельного усиления перед повторным включением
Магазин одновременно является контентной системой
Отдельная большая работа — структура самого RETON-SHOP
Я сознательно не строил его как каталог, где единственный следующий шаг — кнопка покупки
Товары связаны со статьями, видео, вопросами, документами, ситуациями и сравнениями. Статья может привести к товару, товар — к видео, видео — к другому материалу, а пользователь может долго изучать тему и постепенно возвращаться к коммерческому сценарию
То есть SEO, внутреннюю перелинковку и пользовательский прогрев я рассматриваю как одну архитектурную задачу
Чувствительные сценарии требуют отдельной safety-архитектуры
В контуре самодиагностики генеративная модель не получает права самостоятельно определять, что безопасно
Сначала работает детерминированная оценка риска, затем модель получает уже заданные ограничения, а после генерации стоит дополнительный контроль
Это важный для меня принцип работы с ИИ: чем выше цена ошибки, тем меньше критических решений должно зависеть только от вероятностного ответа модели
Что объединяет все эти контуры
Технологии здесь вторичны
Общие принципы повторяются почти в каждом направлении:
- сначала фиксировать устойчивое внутреннее состояние, потом писать во внешние системы
- не повторять опасную операцию, пока не проверено, не выполнилась ли она уже
- не заставлять сотрудника вручную обслуживать связи между системами
- отделять интерфейс пользователя от конкретного поставщика данных
- держать чувствительные действия за явными проверками и ограничениями
- выносить сложный специализированный интерфейс из Bitrix24, если внутри CRM он превращается в костыль
- мониторить не наличие процесса, а способность выполнить бизнес-сценарий
Именно поэтому я называю РЕТОН не одним проектом, а цифровой системой из связанных рабочих контуров
Чего на этой странице намеренно нет
Я не публикую сервисную воронку ремонта как готовое внедрение: она ещё не прошла полноценный рабочий запуск
Не выдаю развивающийся автопостер за законченный продукт
Не использую неподтверждённые проценты роста, экономии или выручки
Для меня сильнее показать реальную архитектуру, состояние и границы системы, чем дорисовать красивый результат, которого нельзя доказать
