В одном из проектов я курировал процесс онбординга новых партнёров. Поток заявок поступал от внешнего аутсорс-партнёра, а задача команды — доводить этих партнёров до первой продажи. По условиям договорённостей, мы обязались укладываться в SLI 48 часов на обработку каждой реги.

Пока объём был стабильным, команда справлялась. Но в какой-то момент поток резко вырос — и всё начало буксовать.

Проблема

— Менеджеры не успевали обрабатывать входящий поток.   — Вырос бэклог до 4000 задач.   — Часть лидов приходилось перераспределять в смежные отделы, чтобы справиться с нагрузкой.   — Начали фиксировать случаи фрода: на стороне аутсорс-партнёра регистрировались нецелевые реги, а менеджеры тратили время на неконверсионные коммуникации.   — Нарушался SLI, партнёры ждали ответа по несколько дней.   Решение

В моём подчинении были две команды:   — менеджеры онбординга,   — колл-центр (до 12 человек).

Я принял решение:   — перенести первое касание с лидами в колл-центр, как я это делал в другом проекте,   — передавать на онбординг только тех, кто действительно готов размещаться в моменте.

Так я планировали разгрузить менеджеров и сократить количество нецелевых коммуникаций.

Технический барьер   Передача между командами была неудобной:   1. Тимлид колл-центра вручную отбирал лидов,   2. Передавал задачи в гугл-таблицах и чатах тимлиду онбординга,   3. Распределение шло вручную — с задержками и большим риском потерь.

Доработка CRM

Я инициировал изменения в CRM. Вместе с командой продукта мы:   — быстро собрали требования,   — описали новую логику передачи через статусы,   — реализовали её в интерфейсе.

Через 2 недели в проде была новая схема:   — все реги попадали в колл-центр,   — при достижении нужного статуса они автоматически попадали в очередь на онбординг,   — распределение задач стало простым и управляемым.

Результаты

— Полностью разгрузили беклог из 4000 задач.   — Снова стали укладываться в SLI 48 часов.   — Убрали ручную передачу задач.   — Повысили фокус команды на реально заинтересованных партнёрах.   — Снизили риски, повысили прозрачность процесса.   — Начали работать над фродом.

Выводы   — Когда растёт нагрузка — важно не просто усилить команду, а перераспределить ответственность.   — Даже минимальные доработки в существующей системе могут резко повысить эффективность.   — SLI — не просто цифра, а инструмент для оценки реального качества процессов.   — Удобный механизм передачи между подразделениями — must have, если вы работаете с большим объёмом входящих данных.      Если вы сталкивались с похожими историями — давайте сравним подходы.