100% звонков в реестре через 1-2 минуты после сделки: RPA-робот контроля качества для автодилера

Отдел качества собирал звонки руками: выгрузка из CRM, поиск записей разговоров, перенос в Google Sheets. На это уходило 3-4 часа в день одного сотрудника, а на прослушку попадали только 20-30% звонков. Единого реестра «сделка - менеджер - звонок» не было, найти разговор через месяц было почти невозможно. Комиссию менеджеров считали в Excel, с ошибками и спорами.

Ограничение, которое определило решение: у CRM нет полного API. Стандартная интеграция не работала, нужен был устойчивый RPA-контур под выделенной учётной записью.

Цели: 100% доступных звонков в реестре, задержка от сделки до аналитики 1-2 минуты, ноль ручной выгрузки.

1. Браузерный робот на Playwright. Робот на Python работает в headless-браузере внутри Docker. Выбрали Playwright за встроенное ожидание элементов вместо ручных пауз, перехват сетевых ответов и сохранение сессии в файл. Робот заходит в CRM под сервисной учётной записью с минимальными правами. Если видит экран входа, переавторизуется и продолжает с того же места.

2. Данные из сетевых ответов, а не из вёрстки. Интерфейс CRM подгружает списки сделок внутренними запросами. Робот перехватывает JSON этих ответов: данные приходят структурированными и не зависят от CSS. Разбор страницы оставлен запасным путём, селекторы строятся по тексту, роли и атрибутам и собраны в одном модуле. Когда CRM меняет интерфейс, правка делается в одном месте.

3. Курсор и окно повторного просмотра. В PostgreSQL хранится курсор: время и id последней обработанной сделки. Каждый прогон дополнительно пересматривает последние трое суток, потому что запись разговора иногда появляется в CRM позже сделки. Перед стартом берётся блокировка: ручной запуск из Telegram и плановый не обрабатывают одно и то же одновременно. Параллелизм ограничен, нагрузка распределена по дню, для CRM робот выглядит как обычный сотрудник.

4. Дедупликация через upsert. CRM может показать одну сделку несколько раз, процесс может перезапуститься. Ключ crm_deal_id + call_id и upsert вместо insert позволяют спокойно переобрабатывать окно без дублей в аналитике.

5. Очистка и нормализация. Звонки короче 30 секунд (недозвоны и проверки) отсекаются. ФИО менеджера восстанавливается из строк вида «ВЛ Иванова Мария Менеджер ОРБ»: сначала правила, затем сопоставление со справочником менеджеров с порогом уверенности, чтобы не перепутать однофамильцев. Даты, суммы и модели авто приводятся к единому формату, записи без обязательных полей помечаются для ручной проверки.

6. PostgreSQL как источник истины, Sheets как витрина. Таблицу Google Sheets редактируют люди: удаляют строки, пересортировывают. Если бы дедупликация шла по ней, робот начал бы плодить дубли. Поэтому реестр, журнал прогонов и ошибки живут в PostgreSQL, а в Sheets пакетами уходят только новые и изменённые строки. Упёрлись в квоту API - повтор с паузой, данные не теряются.

7. Управление и мониторинг. В Telegram-боте: статус последнего прогона, запуск, остановка, повторная обработка ошибок. Доступ по белому списку, каждая команда пишется в журнал. В 9:00 руководитель и контролёр получают сводку за вчера: найдено, обработано, отфильтровано, требует проверки. В Prometheus и Grafana: длительность прогона, ошибки по типам, отставание от CRM. Отдельный алерт на «обработано ноль записей в рабочее время»: робот, который не падает, но после смены интерфейса ничего не находит, иначе молчал бы днями. При ошибке сохраняются скриншот и HTML страницы.

8. Три направления. Кроме реестра звонков работают ещё два робота на той же основе: контроль чатов с клиентами и автоматический расчёт комиссии менеджеров по сделкам.

• 25 950+ звонков обработано.

• 100% доступных звонков в реестре для прослушки вместо 20-30%.

• 1-2 минуты от сделки в CRM до строки в аналитике вместо конца дня или недели.

• 15-20 часов в неделю освобождено у контролёра качества (было 3-4 часа в день на ручной сбор).

• Работает круглосуточно, с автоперезапуском при сбое.

• Комиссия менеджеров считается автоматически.

Частые вопросы

Почему RPA, а не интеграция по API? Полного API у CRM не было. RPA оправдан, когда процесс критичен, а интерфейс единственный доступный канал. Мы заложили в него мониторинг изменений интерфейса и быстрый ремонт.

Что будет, если CRM поменяет интерфейс? Растут ошибки «элемент не найден» или падает число обработанных записей, срабатывает алерт со скриншотом. Селекторы в одном модуле, после правки робот догоняет пропущенное за счёт курсора и окна в трое суток.

Почему не писать сразу в Google Sheets? Таблицу правят люди, она не годится как источник для дедупликации. Источник истины PostgreSQL, Sheets только витрина.