Кейс «до/после»: с 47 до 8 минут на обработку заявки

Это первая статья из серии кейс‑разборов «до/после». Название компании не раскрываем — NDA есть NDA. Зато покажем методологию, которая работает в любой отрасли. Цифры настоящие, подход можно повторить. Если думаете об автоматизации — этот разбор покажет, как мы работаем и чего реально ожидать.

Итак, сервисная компания с потоком 800+ заявок в месяц тратила в среднем 47 минут на обработку каждой. После внедрения AI‑автоматизации время сократилось до 8 минут — почти в 6 раз. Экономия — 520 человеко‑часов в месяц, а три сотрудника смогли переключиться с рутины на развитие бизнеса.

Контекст: что это за компания

B2B‑сервис — обслуживание промышленного оборудования. Клиенты — юридические лица на годовых контрактах. Масштаб: около тысячи заявок в месяц, пять диспетчеров на приёме, пятнадцать выездных специалистов. Основной канал — телефон (60%), потом WhatsApp (30%), и email для формальных запросов (10%).

Проблема была типичной: от момента «алло, у нас сломалось» до назначения специалиста проходило в среднем 47 минут. В пиковые дни — до двух часов. Клиенты нервничали, писали гневные письма, а диспетчеры работали в режиме вечного пожаротушения. Текучка среди них зашкаливала.

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

Этап 1: Диагностика — где теряется время

Прежде чем что‑то автоматизировать, мы всегда начинаем с диагностики. Это скучно, но критически важно. Без понимания, где именно утекает время, автоматизация превращается в «ускорение хаоса» — всё работает быстрее, но всё так же криво.

Что мы сделали: выгрузили 200 случайных заявок за последний месяц и разметили каждую по этапам — от приёма до назначения специалиста. Замерили время на каждом шаге. Плюс поговорили с диспетчерами: что отнимает больше всего сил? На что они жалуются? Где застревают?

Вот что получилось в цифрах:

Два главных «поглотителя времени» нашлись сразу. Первый — уточнение данных: клиенты не помнят номер договора, путают адреса объектов («это на Абая или на Тимирязева?»), не знают модель оборудования. Диспетчер превращается в детектива — ищет информацию, переспрашивает, сверяет.

Второй — выбор специалиста. Это самый долгий этап, 32% времени. Диспетчер вручную проверяет: кто свободен, кто умеет работать с этим оборудованием, кто ближе к объекту, у кого меньше нагрузка. Открывает Google Calendar, сверяется с Excel‑таблицей навыков, прикидывает маршруты. Каждый раз — как задачка на комбинаторику.

Третья проблема — информационный хаос. Договоры живут в 1С, история обслуживания — в Excel‑файле на сетевом диске, график специалистов — в Google Calendar. Чтобы собрать полную картину по клиенту, нужно открыть четыре окна и переключаться между ними.

Вывод был такой: 58% времени уходит на два этапа — уточнение и выбор специалиста. Именно их можно и нужно автоматизировать. Остальное — оптимизировать через интеграции, чтобы данные были в одном месте.

Этап 2: Проектирование решения

Имея на руках диагностику, мы начали проектировать решение. Главный принцип — не автоматизировать всё подряд, а закрыть конкретные узкие места.

Первый компонент — AI‑бот для приёма заявок через WhatsApp и виджет на сайте. Когда клиент пишет, бот автоматически определяет его по номеру телефона: подтягивает договор, список объектов, историю обращений. Никаких «назовите номер договора» — клиент просто подтверждает: «Да, это про офис на Тимирязева». Бот задаёт уточняющие вопросы по проблеме и сам классифицирует срочность: авария, плановое обслуживание или просто консультация.

Второй компонент — автоматический подбор специалиста. Система смотрит в календарь (кто свободен), в матрицу навыков (кто умеет работать с этим типом оборудования), и на карту (кто ближе к объекту). Алгоритм учитывает приоритеты: сначала срочность, потом навыки, потом расстояние, потом текущую загрузку. На выходе — готовая рекомендация: «Назначить Иванова, приедет к 14:30».

Третий компонент — единая панель диспетчера. Вместо четырёх окон — одно. Все заявки в очереди, вся информация по клиенту на экране, готовые рекомендации от системы. Диспетчер кликает «Подтвердить» или корректирует, если знает что‑то, чего нет в системе. Один клик — и заявка назначена.

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

Главный принцип: AI берёт на себя 70% типовых заявок, а диспетчеры фокусируются на сложных случаях и контроле качества. Не заменяем людей — освобождаем их от рутины.

Этап 3: Внедрение — шесть недель до результата

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

Первые две недели ушли на подготовку данных. Это самая скучная и самая важная часть. Выгрузили справочники из 1С: клиенты, договоры, объекты обслуживания. Создали матрицу навыков — таблица 15 специалистов на 12 типов оборудования, где галочками отмечено, кто что умеет. Подключились к Google Calendar, чтобы видеть графики в реальном времени. Написали сценарии диалогов для бота и FAQ по типичным вопросам.

Недели три‑четыре — разработка и настройка. Тут уже интереснее: настраивали промпты для бота, чтобы он правильно классифицировал заявки. Прописывали алгоритм подбора специалиста — это не просто «ближайший свободный», а система весов: срочность важнее расстояния, навыки важнее загрузки. Собрали панель диспетчера: дашборд с очередью заявок, статусы, рекомендации. Прогнали систему на сотне исторических заявок — посмотрели, как бы она сработала.

Пятая неделя — пилот. Запустили на 20% трафика: только WhatsApp, только один сегмент клиентов. Каждый день разбирали диалоги: где бот понял клиента неправильно? Какие формулировки вызывают ступор? Что люди спрашивают, а бот не знает? Параллельно обучали диспетчеров работать с новой панелью — им тоже нужно было привыкнуть.

Шестая неделя — масштабирование. Расширили на весь WhatsApp‑трафик, подключили виджет на сайте, настроили алерты (если бот не справляется — эскалация). К концу недели система работала на полную мощность.

Главный урок этого этапа: половина времени ушла на подготовку данных. Не на AI, не на интерфейсы — на то, чтобы собрать и почистить информацию. Без актуальных справочников и матрицы навыков автоматизация просто невозможна. Мусор на входе — мусор на выходе, как бы умна ни была нейросеть.

Результаты: что получилось на самом деле

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

* Данные подтягиваются автоматически по номеру телефона — клиент только подтверждает.
** Диспетчер видит готовую рекомендацию и подтверждает одним кликом.

Теперь про деньги — потому что именно это интересует руководство:

При стоимости внедрения 2,8 млн ₸ и ежемесячной подписке 180 000 ₸ — система окупилась за четыре месяца. Дальше — чистая экономия. Три диспетчера, которые раньше тонули в рутине, теперь занимаются развитием: работают с крупными клиентами, улучшают процессы, обучают новичков.

Что пошло не так: честные уроки

Не всё было гладко. Было бы нечестно рассказывать только про успехи — вот что пошло не по плану и чему это нас научило.

Первые две недели были зоной турбулентности. Клиенты не сразу поняли, как общаться с ботом. Кто‑то отправлял голосовые сообщения — бот их не понимал и молчал. Кто‑то писал просто «Перезвоните» — а бот ждал описание проблемы и задавал уточняющие вопросы. Раздражение копилось. Пришлось быстро добавить обучающее сообщение в начало диалога («Опишите проблему текстом, и я помогу») и подключить распознавание голосовых через транскрипцию.

Матрица навыков устаревала быстрее, чем мы думали. Специалист прошёл обучение по новому типу оборудования, но в системе это не отразили. В итоге бот назначал человека за 40 километров, хотя ближайший справился бы. Решение: назначили ответственного за актуализацию и ввели еженедельный аудит матрицы. Скучно, но необходимо.

VIP‑клиенты оказались чувствительнее, чем ожидали. Несколько крупных заказчиков прямо написали: «Мы не хотим общаться с роботом, переключите на человека». Пришлось срочно делать white‑list: телефоны из этого списка сразу попадают к живому диспетчеру, минуя бота. Урок: не все клиенты равны, и для некоторых «живое общение» — часть ценности, за которую они платят.

Интеграция с 1С споткнулась о задержки. Оказалось, что данные о новых договорах появляются в 1С с задержкой день‑два. Клиент только подписал договор, звонит с первой заявкой — а бот его не находит: «Вы не в нашей базе». Неловко. Пришлось настраивать real‑time синхронизацию через API и добавлять fallback: если клиент не найден, бот спрашивает данные вручную и передаёт диспетчеру.

Главный урок из всего этого: 70% проблем были не в AI, а в данных и процессах. Автоматизация как рентген — высвечивает все скрытые проблемы, которые раньше компенсировались человеческой смекалкой. Это больно, но полезно.

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

Этот кейс — не уникальный. Методология работает для любого процесса, где много однотипных операций: обработка заявок, поддержка клиентов, документооборот, согласования. Вот как это устроено.

Шаг первый — диагностика. Выгрузите сотню‑две случаев за последний месяц. Разметьте каждый по этапам: что происходило от начала до конца. Замерьте время на каждом шаге. Найдите три главных узких места — именно их будете автоматизировать. Без диагностики всё остальное — стрельба вслепую.

Шаг второй — проектирование. Определите, какие этапы можно автоматизировать (обычно 50–70% — это рутина). Спроектируйте архитектуру: что делает бот, какие правила им управляют, какие интеграции нужны. Обязательно продумайте эскалации — что остаётся человеку и когда система должна передавать управление.

Шаг третий — подготовка данных. Это займёт больше времени, чем вы думаете. Выгрузите справочники, почистите их, создайте недостающие матрицы (навыки, правила приоритизации, SLA). Настройте интеграции с другими системами. Здесь нельзя срезать углы — на плохих данных ничего не взлетит.

Шаг четвёртый — пилот. Запустите на 10–20% трафика. Каждый день анализируйте ошибки: где бот ошибся? Какие формулировки не понял? Что клиенты спрашивают, а он не знает? Итерируйте: правьте промпты, уточняйте правила, улучшайте UX. Пилот — это про обучение системы на реальных данных.

Шаг пятый — масштабирование и мониторинг. Когда пилот показал стабильные результаты — расширяйте на весь трафик. Настройте метрики и алерты, чтобы видеть, если что‑то идёт не так. И да, это не финиш — систему нужно регулярно обновлять: база знаний устаревает, появляются новые типы запросов, меняются процессы.

Как понять, что получилось? Три критерия: время сократилось минимум вдвое, система окупилась за полгода или быстрее, клиенты стали довольнее (NPS вырос). Если все три — вы на верном пути.

Что в итоге

Главный вывод из этого кейса: автоматизация — это не магия и не «подключили AI, и всё заработало». Это методология: диагностика, проектирование, подготовка данных, пилот, итерации. Скучно? Возможно. Но работает.

Если выделить ключевые уроки:

Без диагностики автоматизация слепа. Нельзя автоматизировать «всё» — нужно точно знать, где теряется время. Иначе рискуете ускорить то, что не имеет значения, и пропустить настоящие узкие места.

Данные — это фундамент. Половина усилий уходит на то, чтобы собрать, почистить и структурировать информацию. Это неинтересная работа, но без неё всё остальное бессмысленно.

AI сам по себе не решает проблемы. Эффективное решение — всегда комбинация: AI для понимания и классификации, правила для принятия решений, интеграции для действий. Любой компонент в отдельности — слабее, чем система в целом.

Пилот покажет 80% проблем. Не пытайтесь всё предусмотреть заранее — запустите на малом трафике и учитесь на реальных ошибках. Это быстрее и дешевле, чем месяцы проектирования.

Результат должен быть измеримым. Время, деньги, NPS — конкретные цифры, которые можно показать руководству. «Стало лучше» — это не аргумент. «В 6 раз быстрее, окупаемость 4 месяца» — аргумент.

Для этой конкретной компании результат получился таким: время обработки сократилось с 47 до 8 минут. Экономия — 10,5 млн тенге в год. Три человека освободились от рутины и занялись развитием. Окупаемость — четыре месяца.

Это первый кейс из серии «до/после». В следующих разберём автоматизацию продаж, поддержки и внутренних процессов — с той же детализацией и той же честностью про то, что пошло не так.