Как согласиться с клиентом и испортить два года разработки

Ниже приведён отредактированный текст доклада. Сохранена техническая детализация и последовательность изложения, убраны обращения от первого лица и к аудитории, устранены повторы и разговорные вставки.

Принцип «клиент всегда прав»

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

О компании и продуктах

Компания AITEC более десяти лет занимается IP-аутсорсингом и разработкой программных продуктов для колл‑центров. В портфеле четыре ключевых решения:

1. Дайлер — автоматизированная система исходящего обзвона;
2. Антибот — модуль для фильтрации автоответчиков;
3. Spiket — платформа для голосовых сценариев, позволяющая заменять оператора автоматической речью;
4. WFM-система — решение для интеллектуального планирования и управления персоналом.

Архитектура дайлера

Схематично система представляет собой интеграцию трёх компонент:

1. Телефония (сервер Asterisk);
2. ARM оператора (софтфон + CRM в браузере);
3. CRM-модуль планирования.

Последовательность работы:

• В CRM настраиваются «воронки» кампаний и расписание обзвона (модуль построения расписания).
• Лиды попадают в виртуальный список (bucket) для пакетного управления.
• Планировщик выбирает первое правило для лида и записывает его параметр в сущность «лид».
• Календарь ограничивает время обзвона, маршрутизация определяет номер, с которого будет совершён вызов (годовой номер, региональный, операторский и т. д.).
• В назначенное время коннектор к серверу телефонии инициирует звонок: сначала абоненту, затем распределяет вызов в операторские очереди.

Для обработки миллионов лидов используется процесс «батчинга»: каждую минуту заранее отбираются все доступные для обзвона лиды, а в реальном времени — по свободным агентам и времени следущего контакта; весь пул хранится и перебирается в памяти, без частых обращений к БД.

Задача «callback» и возникающие проблемы

Заказчик запросил новую стратегию «callback» — отложенный обратный вызов конкретному оператору в заданное время, закреплённое в CRM. Оценка нагрузки — около десяти пользователей данной фичи — позволяла рассчитывать на быструю реализацию по прототипу за две недели.

Основная идея архитектуры:

• В сущности лида появилась дополнительная «задача» с оператором и временем звонка.
• При попытке снять паузу оператором система проверяет наличие «callback»-задачи и удерживает оператора в паузе, если время ещё не наступило.
• В батчинге отдельно («каждую секунду») отбираются задачи, и прямые вызовы делаются на операторов с готовыми задачами.

Накопившиеся кейсы:

• «Зависание» статуса ожидания задачи из‑за несинхронизированных сущностей.
• Удаление лида при наличии связанной callback‑задачи.
• Перенос лида, изменения правил планировщика и манипуляции с операторами приводили к рассинхронизации и ошибкам снятия паузы.

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

Переход на третью версию продукта

Архитектура второй версии не масштабировалась под растущие требования, поэтому началась разработка третьей версии дайлера. Стратегию callback решили не переносить «как есть», чтобы не усугублять проблемы.

Для минимизации простоя клиентов была реализована двусторонняя маршрутизация запросов в CRM: обе версии приложения работали параллельно, переключаясь по отделам и операторам; при необходимости — откаты и миграции данных в обе стороны.

Итоговая реализация «callback»

1. При создании callback-вызова в сущности лида сразу рассчитывается время следующего звонка (минимум из пользовательского и планировочного расписания).
2. Лиды для каждого оператора закреплены в отдельном bucket, что упростило логику батчинга.
3. Каждую минуту «батчер» выбирает для каждого оператора несколько лидов в статусе «callback», сохраняя логику общего процесса.
4. При снятии паузы оператору отправляется код паузы, а расчёты батчинга учитывают только воркеры, устраняя задержки.

Дополнительный бонус:

Внедрение промежуточного статуса «ожидание снятия с паузы» позволило сгладить переход на паузу и выход в работу в сценариях предиктивного обзвона. Операторы получают «пенальти» в очереди (например, +10 000), что гарантирует им приоритет на текущих звонках и защищает от «потерянных» вызовов, если статус меняется.

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

Результаты

• Повышена отказоустойчивость и скорость реакции системы — все задержки и рассинхронизации выведены из критического пути.
• Сокращены трудозатраты на сопровождение стратегии — единая точка расчёта батчинга в воркере.
• Выработаны ценные навыки стресс‑тестирования, анализа логов, отладки SQL‑запросов и веб‑сервисов.
• Неожиданно получены дополнительные фичи: гибкое управление очередями и продвинутый механизм пауз.