Навожу порядок в Bitrix24, CRM и рабочих процессах компании

• REST уже перегружает портал
• Стандартной настройки роботов недостаточно
• Нужны кастомные обработчики событий
• Тяжёлые операции тормозят CRM
• Нужны свои вкладки и действия в карточке
• Логика «размазана» и ломается при изменениях

• Стабильная логика внутри портала
• Понятные логи и диагностика
• Меньше нагрузки на REST
• Документация по точкам входа
• Поддерживаемая структура кода

• Не заменяю полноценного DevOps/SRE
• Для production-правок сначала смотрю логи и делаю бэкап
• Точную цену называю после доступа к порталу

• Нужен внешний продукт поверх CRM
• Нужен API или интеграционный хаб
• Логика не помещается в коробку
• Нужны очереди и фоновые задачи
• Нужна админка с ролями

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

• Инфраструктуру готовлю в рамках своего решения, не как DevOps-аутсорс
• Полная переработка старого проекта — отдельной оценкой

• Синхронизация работает «иногда»
• Появляются дубли
• Данные расходятся между системами
• Нет истории обмена
• Ошибка не видна пользователю
• Нужно связать CRM с внешним сервисом

• Не теряются данные
• Не создаются дубли
• Обмен не падает молча
• Понятные логи входящих/исходящих запросов
• Возможность повторить неудачную операцию

• Не отвечаю за сбои на стороне внешних сервисов и провайдеров
• Маскирую секреты, не логирую токены
• Сначала тестовый контур, потом production

• Данные переносят вручную
• Сверяют таблицы между системами
• Теряются заявки
• Согласования идут «на словах»
• Нет контроля сроков
• Отчёты собирают руками

• Меньше ручной работы
• Заявки и согласования не теряются
• Прозрачные сроки и статусы
• Отчёты собираются сами

• Сначала фиксирую текущий процесс, потом автоматизирую
• Сложные сценарии — поэтапно
• Зависит от доступов и данных систем

• Разработчик ушёл, код остался
• Нет документации
• Нет логов
• Процессы ломаются
• Страшно трогать production
• Нужна причина, а не «пофиксить симптом»

• Понятная карта проблем
• Приоритеты и план
• Оценка сроков
• Рекомендации по логам и архитектуре
• Понимание, что можно не переписывать

• Не трогаю production вслепую
• Делаю бэкап при риске потери данных
• Полная переработка архитектуры — отдельной оценкой

• Интеграции падают молча
• Нет истории обмена
• Нельзя повторить неудачную операцию
• Данные дублируются

• Интеграции
• Логи обмена
• Retry / backoff
• Encrypted secrets
• Health-check
• Очереди
• Админка

• Не заменяет ESB/iPaaS enterprise-класса
• Каждая система подключается отдельной задачей

• Дубли лидов и сделок
• Роботы и БП срабатывают не так
• Тяжёлые REST-запросы
• Нет логов и истории

• Обзор структуры
• Проверка логов
• Поиск рисков
• Карта проблем
• Таблица рисков
• План исправлений

• Исправления — отдельным этапом
• Без доступа к логам/коду точность ниже

• Непонятно, пришло ли событие
• Нет payload для разбора
• Ошибка не видна
• Нельзя переотправить

• Приём webhooks
• Хранение payload
• Проверка подписи
• Статус обработки
• Ошибки
• Ручной повтор

• Собирается на базе Integration Hub
• Обработка под каждый источник — отдельно

• Клиенты не видят статусы и данные сами
• Поддержка перегружена однотипными вопросами
• Заявки и обращения теряются в почте/мессенджерах

• Авторизация и роли
• Заявки и статусы
• Сообщения
• Документы и счета
• Уведомления
• Интеграция с CRM
• Админка

• Не SaaS с лицензией — это адаптируемая база
• Сложные кастомные модули оцениваются отдельно

• Клиентам негде смотреть статусы из CRM
• Менеджеры пересылают данные вручную

• Статусы заявок
• Обращения
• Счета
• Сообщения
• Связь с CRM-данными

• Зависит от редакции и доступов Bitrix24
• Тяжёлая логика выносится на D7 отдельно

• Сотрудники работают в разрозненных таблицах
• Нет единой точки для задач и заявок

• Авторизация и роли
• Задачи / заявки
• Доступ к данным процессов

• Проектируется под задачу — требует обсуждения объёма

• Партнёры не видят статусы заявок
• Документы и расчёты ходят вручную

• Авторизация партнёров
• Заявки и статусы
• Документы
• Расчёты

• Проектируется под партнёрскую модель

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

• Смарт-процесс «Кредитные заявки» с 21 полем результата и правами по ролям: менеджер видит свои заявки, руководитель — свой отдел, администратор — все
• Отправка брокеру из карточки сделки: черновик, проверка обязательных полей и лимитов продукта, запрет подачи после согласования договора, защита от двойного нажатия
• Приём колбэков: авторизация по ключу, идемпотентность по eventId, толерантный разбор тела — колбэки 5 дней молча не писались из-за расхождения с ТЗ, найдено и исправлено
• Справочник статусов банка — 28 бизнес-статусов и 16 технических; окончательное решение ставит менеджеру «дело» и пишет в таймлайн сделки
• SMS клиенту со ссылкой на анкету банка по правилу «одна заявка — одна SMS», с приёмом отчёта о доставке
• Журнал обмена по 6 направлениям, робот БП «Отправить заявку» и утренний сторож заявок без событий дольше 3 дней

Модуль работает на проде с 10.08.2026, с 08.09 — на боевом контуре брокера, SMS клиентам уходят с 31.08. Логику без сети покрывают 192 CLI-проверки, а каждое событие обмена видно в журнале и в таймлайне сделки.

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

• Приём отчётов Bizon365 о присутствии: по дням эфира сделка двигается только вперёд по весам стадий и никогда не откатывается назад
• Отдельная ветка для кейсовых вебинаров — задача ответственному вместо новой сделки, идемпотентность по sha256-ключу события и режим dry_run без единой записи
• Перенос не пришедших в «Не пришли» пачками: запись только с --execute, защита от повторного и параллельного запуска, защита присутствовавших на эфире
• Приглашение за 10 минут до эфира через стадию-триггер с возвратом сделки на исходную стадию; покупатели курса исключаются из рассылки
• Вступление в WhatsApp-чат через ChatApp переводит сделку на нужную стадию — через файловую очередь с flock вместо создания новых сделок
• Обёртка над REST, которая не выдаёт ошибки за успех и сама ждёт, когда портал снова разрешит запросы

Приглашения на эфир ушли 628 участникам из 628 без ошибок, в «Не пришли» перенесены 451 сделка из 451, догнан накопившийся долг в 396 сделок; защита присутствовавших отсеяла 65 из 78 сделок. Ревизия контактов нашла 564 карточки с телефоном в поле «Имя» — источник неудаляемых дублей.

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

• Разведка только на чтение: пул папок, классификация каждой ссылки из карточек (рабочая, через сокращатель, старый портал, пустая, мусор), папки-сироты
• Слияние папок-дубликатов с приоритетом корневого дела: содержимое переносится в каноническую папку, источники не удаляются, подозрительные группы — на ручной разбор
• Синхронизация файлов из файловых полей карточки в папку дела без дублей по имени и размеру, починка ссылок и дозаполнение служебного поля с id папки
• Пересоздание недостающих папок для дел, у которых рабочей папки на диске не было вообще
• Итоговый пайплайн одной командой: по умолчанию три dry-run, боевой прогон — только с подтверждением, остановка на первой ошибке; ночной синк по cron

Разведка нашла 334 папки, 16 групп дубликатов и 298 исправимых ссылок через сокращатель. Боевой прогон обработал 750 элементов: скопировано 2544 файла, починено 302 ссылки, заполнено 250 id папок — 0 ошибок; повторная проверка подтвердила 7182 файла на своих местах по 780 элементам.

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

• Закрыты 6 мест выдачи админской сессии по анонимному запросу и обход авторизации в 6 API-эндпоинтах; из ответов убраны stack-trace
• Анонимные ручки получили rate-limit, ИИН валидируется до платных внешних вызовов; закрыты IDOR и CSRF в рабочих интерфейсах
• Пароль на форме входа шифруется в браузере (RSA-OAEP, ключ 4096 бит); около 50 захардкоженных доступов вынесены в .env
• Аудиторский след под флагами: неудачные входы, журнал API-обращений, зеркало в syslog; ежедневный сторож ротации логов и регресса обязательной 2FA
• Логгер маскирует ИИН, телефоны и карты; ротация 90 дней плюс архив 400 дней; ложное маскирование хэшей — с 5,1% до 0% на 200 000 значений
• Просмотрщик логов с графиками и сквозным поиском по id запроса; health-API ловит всплеск ошибок против медианы, тишину и молчащую ротацию

Накопленные логи заархивированы: 6344 файла на 2041 МБ сжаты в архив 120 МБ с контрольными суммами, каталог local/ уменьшился с 2,6 ГБ до 578 МБ. Критичные дыры доступа закрыты, а в логах виден инцидент, а не шум.

Живой поток — около 95 заявок в месяц, поэтому каталог строился по фактической частоте обращений, а не «как принято». Каталог должен править администратор без разработчика, а срок SLA — не поддаваться тихому растягиванию.

• Разобрана выгрузка OSTicket: отделён мониторинг, посчитаны частоты по темам — из них собран двухуровневый каталог из 11 направлений и 32 услуг, частые сверху
• Уточняющие вопросы услуги описаны JSON-схемой с зависимыми полями; одни правила проверки на сервере и в браузере сверяются общими тест-фикстурами
• Эффективный приоритет «услуга × срочность», нормативы реакции и решения в рабочих минутах; исходный срок фиксируется при подаче и не растягивается
• Автоназначение наименее загруженному исполнителю группы услуги и агент контроля SLA с уведомлениями
• Один движок каталога и мастера обслуживает 4 каталога: help-desk, HR-процессы, документооборот и запросы на разработку

Вместо пяти категорий и одного срока на всё — каталог по фактическому спросу, свои нормативы у каждой услуги (от 15/60 минут на сброс пароля до 480/4800 на доработку портала) и срок, который нельзя незаметно подвинуть.

Виджет должен встраиваться на внешние сайты объектов сети (в том числе на WordPress) без авторизации Bitrix, при этом статус занятости не должен расходиться с реальными данными CRM.

• Встраиваемый конструктор интерактивных планов этажей — публичный iframe/JS-виджет без авторизации Bitrix (CSP/CORS настроены на встраивание с внешних доменов)
• Внутренняя админка загрузки и редактирования планов
• Автосинхронизация статуса занятости, арендатора и даты окончания аренды из CRM по cron — картинки планов грузятся вручную, данные о занятости обновляются сами
• Дашборды занятости по объектам сети: процент занятости по площади (м²), количество кабинетов, выручка по занятым площадям
• Виджет уже встроен на внешних сайтах объектов сети

По сети: 93 этажа, 1087 офисов и 152 загруженных плана — с занятостью, которая обновляется из CRM автоматически, а не сверяется вручную по каждому объекту.

Робот работает кампаниями — своя на каждый шаг заявки; у одного клиента бывает несколько карточек; повторный запуск cron не должен давать второй звонок, а звонить можно только в дневное окно.

• Cron каждые 15 минут выбирает сделки без движения 30+ минут по штатной истории стадий: смена стадии сбрасывает таймер
• Карта стадий воронки: каждый шаг заявки ведёт в свою кампанию робота, финальные, отказные и служебные стадии не отправляются; окно звонков 08:00–21:00
• «Один клиент — один звонок»: карточки сводятся по телефону, в обзвон уходит самая свежая, а негативный исход снимает с обзвона все карточки этого номера
• Идемпотентность в три слоя: flock от параллельных запусков, поля заказа на сделке и стабильный import_id на стороне робота
• Вебхук результата звонка находит сделку, пишет исход без затирания полей пустыми значениями и запускает бизнес-процесс; есть тестовый режим на отдельной кампании
• Логика отбора вынесена в чистые функции без ядра Bitrix и покрыта 66 smoke-проверками

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

Часть классических метрик колл-центра (SL/ASA/ATA) физически не считается без данных телефонии; разные источники дат (лид/визит) искажают проценты, если их не развести явно.

• 20 параметризованных SQL-отчётов поверх live-данных CRM с безопасной подстановкой фильтров
• Воронка «лид → визит → сделка → продажа» с промежуточными метриками (Contact Rate, Occupancy и др.)
• Многоуровневый кеш с TTL, stale-fallback и блокировками — дашборд не кладёт CRM тяжёлыми запросами
• 33 whitelisted AJAX-действия с проверкой прав и sessid
• Честная документация ограничений каждой спорной метрики — вместо рисования цифр
• Дашборд РОПа по автоцентру: метрики считаются по автоцентру самой сделки, любая цифра раскрывается кликом в список сделок
• Маркетинговый дашборд по направлениям и источникам трафика; сравнение с теми же датами прошлого месяца на всех страницах
• Общий кеш отчётов с проверкой доступа до кеша: первая сборка — 7,2 с, следующему пользователю — 0 мс
• Реестр доступов «кто видит какой отчёт» с источником каждого доступа, выдача без деплоя и единая шапка навигации по отчётам

Руководство, колл-центр, РОПы и маркетинг получили набор дашбордов поверх live-данных CRM вместо выгрузок в Excel: воронка, автоцентр, маркетинг — с общим кешем, расшифровкой цифр кликом и явно задокументированными ограничениями метрик. Доступы к 6 отчётам управляются из одного реестра без деплоя.

• Дубли лидов и сделок
• Грязные телефоны
• Потерянные связи
• Расхождение CRM и склада
• Неактуальные остатки

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

• Роботы не срабатывают
• Бизнес-процессы зависают
• Согласования идут вручную
• Нет контроля сроков
• Менеджеры обходят CRM

• Смотрю, на каком шаге процессы встают и по какому условию
• Сверяю, что должно запускать робота и что запускает его на самом деле
• Переношу хрупкую логику из конструктора в код с логами
• Добавляю контроль сроков и уведомления ответственным
• Убираю ручные шаги, из-за которых менеджеры обходят CRM

• Нет логов
• Нет retry
• API падает
• Данные приходят частично
• Ошибка не видна пользователю

• Включаю логирование входящих и исходящих запросов с маскированием токенов
• Добавляю повторы с задержкой на временные ошибки чужого API
• Развожу «данные не пришли» и «пришли частично» — это разные поломки
• Вывожу ошибку туда, где её увидит человек, а не только сервер
• Оставляю режим проверки: прогнать обмен, ничего не записывая в боевую базу