Переезд из SalesForce в Битрикс24 за 1.5 месяца

В 2022 году крупный зарубежный CRM‑вендор перестал работать в России, и одна из крупнейших российских интернет‑компаний была вынуждена в кратчайшие сроки выбрать новую платформу для обслуживания входящих и исходящих звонков. За полтора месяца было принято решение о переходе с Salesforce на облачный Bitrix24. Проект стартовал более двух лет назад и продолжается до сих пор, однако первый этап миграции был успешно завершён в установленный срок без простоев в работе сервиса.

Контекст и масштаб проекта

• Компания‑клиент: крупный интернет‑сервис с закрытым контуром (нет доступа в интернет извне).
• Инфраструктура: несколько сотен менеджеров по продажам, десятки тысяч звонков в сутки.
• Интегратор: опытная команда, привлекшая профильного вендора коннектора IT‑игрикс (интеграция Asterisk ↔ CRM).
• Продукт: коннектор третьего поколения, разработка с 2017 года, более 300 партнёров, используется в 20+ странах, ежедневно обрабатывает 100 000+ звонков.

Основные задачи первого этапа

1. Перенос базовых бизнес‑процессов из Salesforce в Bitrix24.
2. Сохранение непрерывности работы: дозвон, обработка, учёт звонков — без единой минуты простоя.
3. Встроенная кастомизация: обеспечение любых доработок бизнес‑логики на уровне фаз звонка (дозвон, ответ, перевод, завершение).
4. Закрытый контур: решения по офлайн‑установке, офлайн‑лицензированию и авторизации.

Технические решения и доработки

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

Суперинструмент кастомизации:

• 20+ точек внедрения на каждой фазе звонка, где можно запускать PHP‑скрипты.
• Возможность менять данные перед отправкой, обращаться к сторонним базам, обогащать события.

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

Плеер записи разговора:

• Ссылки на WAV‑записи хранятся в отдельной таблице.
• Коннектор извлекает URL из БД и помещает в кастомное поле «Дело».
• В интерфейсе дела встроен HTML‑плеер для прослушивания записи без сохранения файлов в Bitrix.

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

Автозамена внутренних номеров Bitrix24 допускает не более четырёх цифр в внутреннем номере. При отправке в CRM убирается префикс, а при click‑to‑call он восстанавливается, чтобы Asterisk мог корректно выполнить исходящий звонок.

Обработка пропущенных звонков на IVR попадают на системного пользователя.

Пакетные запросы и управление нагрузкой Bitrix24 API в облаке ограничивает до 2 запросов в секунду. Внедрён механизм пакетных (batch) запросов по 50 команд, что даёт до 100 реальных операций в секунду. Реализована очередь запросов с учётом rate‑лимита и последующим переходом на параллельную обработку batch‑пакетов — производительность выросла почти в 10 раз, протестированная нагрузка достигла 12 000 звонков/день.

Решения для закрытого контура

1. Офлайн‑установка: коннектор разворачивается локально, без связи с внешним интернетом.
2. Офлайн‑лицензия: после оплаты выдаётся ключ, привязанный к конкретному серверу.
3. Офлайн‑авторизация: вместо штатного Bitrix‑сервера авторизации развёрнут собственный, генерирующий токен на 10 лет.
4. Мониторинг и алерты: API‑метод отдаёт JSON‑статус коннектора. Клиент настраивает агрегатор алертов в корпоративном мессенджере. Дополнительный мониторинг понятия «число ошибок в логах за последний час» с порогом срабатывания.

Результаты первого этапа

• Успешный запуск Bitrix24 без остановок и задержек.
• Бизнес‑логика в полном объёме перенесена и сохранена.
• Внедрённые доработки затем включены в стандартную поставку коннектора для всех клиентов.
• Слаженная работа команд интегратора, технической поддержки и разработчиков коннектора.

Второй этап: борьба за стабильность

Изначально ~3 % звонков обрабатывались с ошибками (сотни звонков в сутки).Цель — снизить до 0,1 % некорректных обработок при живом режиме.

Процесс:

1. Автоматизированный разбор логов с выявлением типовых ошибок.
2. Для каждого типа разработаны сценарии обработки и регламенты.
3. Механизм переобработки «постфактум» — скрипты автоматически ищут и реобрабатывают некорректные звонки, собирая в отчёт только исключения, требующие ручной проверки.
4. Еженедельная ревизия переобработки оператором поддержки занимает минимальное время.