Первый проект на ИИ: выберите одну больную очередь и исправьте её

Почему большие планы по ИИ застревают

Большинство команд не терпят неудачу потому, что ИИ сложен. Они терпят неудачу, потому что начинают слишком широко.

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

Когда эти ответы отсутствуют, проект превращается во встречи, схемы и демонстрации инструментов. Внешне выглядит занято, но в повседневной работе ничего не меняется.

Стоимость обычно тоже смазана. Команда понимает, что процесс неприятен, но никто не может сказать, сколько часов он съедает каждую неделю, сколько ошибок создаёт или сколько клиенты ждут из‑за этого. Если боль размытa, результат тоже будет размыт. Почти любой инструмент может казаться обещающим, когда проблему сначала не измерили.

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

Долгие сроки усугубляют ситуацию. Люди вдохновлены на первой неделе, затем наступает настоящая работа. К третьему месяцу команда смотрела слайды и, возможно, пилот, но ежедневных улучшений нет. Терпение по бюджету падает. Доверие падает быстрее.

Вот почему хороший внештатный CTO обычно сужает объём вместо того, чтобы расширять его. Одна ручная очередь с понятным объёмом побеждает грандиозный план каждый раз.

Малому бизнесу не нужен сразу «дек по ИИ‑трансформации». Ему нужна одна проблема, которая покажет явную экономию в пару недель. Когда это сработает, следующее решение становится намного проще.

Что делает хорошую первую очередь

Лучшая первая очередь обычно скучная. И это хороший знак.

Ищите работу, которая повторяется каждый день или каждую неделю, проходит примерно одинаковыми шагами и легко поддаётся учёту. Человек открывает элемент, проверяет пару деталей, принимает простое решение, затем обновляет систему или отправляет стандартный ответ. Такая работа даёт быстрый и честный тест.

Жалобы тоже важны. Если люди постоянно говорят: «Я теряю полуты дня на это», обратите внимание. Нудная работа часто делает лучший пилот, чем редкая высокорисковая задача, потому что можно быстро сэкономить время, не ставя бизнес на кон ради одного эксперимента.

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

Очередь обычно сильный кандидат, когда большинство из этих пунктов верны:

• Новые элементы приходят регулярно.
• Сотрудники в большинстве случаев выполняют одинаковые шаги.
• Команда уже не любит эту задачу.
• Можно отслеживать объём, время и долю ошибок.
• Один человек может проверить результат перед публикацией.

Последний пункт очень важен. Ручная проверка держит риск на низком уровне, пока система учится. Ревьюер должен просмотреть результат за секунды или несколько минут, а не переделывать задачу с нуля.

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

Измерьте боль прежде чем покупать инструменты

Команды часто догадываются на этом этапе, и именно так простая очередь превращается в дорогой пилот без явной победы.

Начните с объёма. Посчитайте, сколько элементов попадает в очередь в обычный день, в загруженную неделю и за полный месяц. Возьмите цифры из почты, системы тикетов, таблицы или логов чата. Если в спокойный день приходит 15 запросов, а к пятнице накапливается 90, это важно.

Потом засеките время. Посмотрите, как кто‑то обрабатывает 10–20 реальных элементов и запишите среднее минуты на элемент. Включите скучные шаги, которые люди забывают упомянуть: открытие лишних вкладок, проверка старых заметок, копирование ответа, обновление записи и исправление мелких ошибок перед отправкой. Задача, которая звучит быстро, может занимать намного больше, если учитывать весь поток.

Далее посмотрите на ошибки и задержки. Где люди застревают? Что приходится исправлять позже? Какие ошибки раздражают клиентов или создают лишние переписки? Очередь не обязана быть драматичной, чтобы быть дорогой. Повторяющиеся небольшие задержки по 200 раз в неделю быстро складываются.

На этом этапе вы должны уметь сказать что‑то простое и конкретное, например: «Эта очередь получает 300 элементов в неделю, занимает 12 человеко‑часов и создаёт 15 предотвратимых ошибок.» Это даёт реальную отправную точку. Без неё вы не поймёте, помог ли пилот.

Выберите одну задачу внутри очереди

Большинство ручных очередей на самом деле состоят из нескольких маленьких задач, сложенных вместе.

Агент поддержки может прочитать запрос, понять его тему, скопировать пару деталей в систему, заметить недостающую информацию, а затем написать первый ответ. Если вы попытаетесь попросить ИИ сделать всё это в первый день, пилот быстро станет хаотичным.

Разделите очередь на отдельные действия. В почтовом ящике поддержки это часто означает четыре простые задачи:

• классифицировать сообщение: возврат, выставление счёта или доставка;
• извлечь данные: номер заказа, имя клиента, дату или сумму;
• подготовить черновой ответ для проверки человеком;
• пометить недостающие данные, например счёт или ID аккаунта.

Каждая задача имеет разный уровень риска. Сортировка сообщений обычно низкорисковая. Извлечение полей часто легко тестируется, потому что можно сравнить результат с источником. Подготовка ответов экономит больше времени, но людям всё ещё нужно проверять тон и факты.

Для первого проекта выберите один результат и остановитесь на нём. Не просите пилот одновременно классифицировать запрос, извлечь данные, написать ответ, обновить систему и отправить письмо. Это звучит эффективно, но усложняет отладку, потому что никто не поймёт, на каком этапе произошёл сбой.

Лучше начать просто и узко. Попросите систему вернуть одну метку категории. Или извлечь пять полей из входящих PDF. Или сгенерировать черновой ответ, который сотрудники утвердят перед отправкой.

Чем уже тест, тем проще оценить. Правильно ли выбрана категория? Правильно ли извлечён номер заказа? Сэкономил ли черновик 2 минуты без появления ошибок?

Многие команды гонятся за впечатляющим демо. Лучше первым выбором обычно является самая повторяемая задача.

Проведите небольшой пилот за недели

Пилот должен казаться почти скучным. Это хороший знак. Вы пока не пытаетесь автоматизировать весь рабочий поток. Вы проверяете, может ли одна маленькая задача в очереди сэкономить реальное время, не создавая лишней уборки.

Начните с реальных кейсов из прошлого месяца, а не идеализированных демо‑данных. Возьмите партию из 50–200 элементов очереди. Сохраните честную смесь: простые случаи, запутанные и те, что обычно тормозят. До того, как ИИ прикоснётся к чему‑то, отметьте правильный результат для каждого случая, чтобы было с чем сравнивать.

Держите задачу узкой. Попросите систему выполнить одну работу: классифицировать запрос, подготовить первый ответ, извлечь данные заказа или пометить недостающую информацию. Не просите читать, решать, писать и отправлять в одном пилоте.

Первые две недели пусть один опытный сотрудник проверяет каждый результат. Этот человек должен утверждать, править или отклонять вывод и фиксировать причину. Этот шаг проверки важнее, чем название модели. Он ловит плохие паттерны на ранних стадиях и показывает, где нужно править правила, подсказку или входные данные.

Отслеживайте несколько показателей в таблице:

• время на кейс до и после;
• как часто ревьюер принимает вывод «как есть»;
• как часто он вносит небольшие правки;
• какие случаи всегда должны идти человеку.

Качество важно не меньше скорости. Если ИИ быстрый, но порождает переделки, пилот провалился. Если он экономит 10 минут на кейс, а ревьюер исправляет только пару мелких ошибок, это сильный старт.

Хороший внештатный CTO часто помогает именно на этом этапе: держит объём в узде, устанавливает правила ревью и следит, чтобы результат был достаточно безопасен для использования в продакшене.

Простой пример: триаж писем о возвратах

Магазин получает около 300 писем о возвратах в неделю. Это уже достаточный объём, чтобы болеть, даже если каждое сообщение выглядит простым.

Саппорт открывает каждое письмо, ищет номер заказа, пытается понять причину возврата, оценивает срочность и вручную маршрутизирует обращение. Те же шаги повторяются весь день. Люди копируют номера заказов, ищут подсказки и делают небольшие маршрутизационные решения снова и снова.

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

Когда эти поля заполнены, команда решает следующее действие. Повреждённый товар идёт в поддержку. Дублированный платёж — в бухгалтерию. Поздняя доставка — в команду логистики. Сотрудники по‑прежнему принимают окончательное решение в сложных ситуациях.

Ручная проверка делает пилот безопасным. Если в письме нет номера заказа, смешаны два запроса или используется расплывчатая фраза вроде «это случилось снова», человек проверяет это прежде, чем что‑то отправлять. ИИ обрабатывает скучную первую проходку, команда — странные случаи и вопросы по суждениям.

Экономия появляется быстро, потому что очередь предсказуема. Если сотрудники экономят всего 2 минуты на каждом из 300 писем, это возвращает примерно 10 часов в неделю. При 4 минутах — около 20 часов. Этого достаточно, чтобы сократить задержки с ответами или перевести одного человека на более сложную работу.

Ошибки, которые губят первый пилот

Большинство первых проектов по ИИ терпят неудачу по скучным причинам, а не техническим.

Самая частая ошибка — выбрать задачу, которая почти не происходит. Если дело появляется два раза в неделю, вы будете ждать обратной связи и сэкономите почти ничего. Начинайте с загруженной очереди, где стоимость видно в часах, задержках или пропущенных ответах.

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

Объём тоже причиняет много вреда. Один пилот должен тестировать одну очередь и одну задачу внутри неё. Если вы смешаете письма о возвратах, сопоставление счётов, оценку лидов и тегирование поддержки в одном эксперименте, никто не поймёт, что сработало.

Грязные входные данные тихо портят хорошие модели. Общие почтовые ящики часто содержат сломанные шаблоны, недописанные заголовки, пересланные цепочки, скриншоты и отсутствующие номера аккаунтов. Если игнорировать этот беспорядок, модель будет выглядеть хуже, чем есть на самом деле.

Небольшой шаг по очистке помогает. Удалите дубликаты, разделите длинные переписки, определите поля, которые нужны модели, и отправляйте элементы с пропущенными данными на ручную проверку.

Команды также забывают про путь резервного варианта. У каждой модели есть случаи с низкой уверенность. Когда это случается, работа должна идти к человеку, а не застревать в скрытой папке или отправлять рискованный ответ.

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

Быстрая проверка перед запуском

Пилот часто ломается до старта, потому что никто не зафиксировал основы.

Перед включением ответьте на пять простых вопросов:

• Сколько элементов попадает в эту очередь каждую неделю и сколько эта работа сейчас стоит в человеко‑часах или внешних расходах?
• Может ли один ревьюер быстро заметить неправильные выводы?
• Есть ли у вас 50–100 реальных примеров с входом и правильным результатом?
• Будет ли команда использовать вывод на следующей неделе в обычной работе?
• Выбрали ли вы один критерий прохождения/провала, например «сокращает время сортировки на 30 процентов» или «попадает 90 процентов кейсов в правильную корзину»?

Большинство первых пилотов ломаются по одной и той же слабой части: нет владельца. Кто‑то должен проверять выводы, отвечать на крайние случаи и решать, достаточно ли хороший результат для использования. Если этот человек не назначен, проект уйдёт в сторону.

Небольшая очередь поддержки упрощает тестирование. Скажем, команда сортирует 70 писем о возвратах в день. Они знают, что это занимает около 90 минут работы, один тимлид может проверить ошибки за 10 минут, и агенты будут пользоваться отсортированным ящиком завтра утром. Это рабочая отправная точка.

Если вы не можете ответить на один из этих вопросов, остановитесь и заполните пробел. Короткая задержка сейчас дешевле, чем тратить три недели на пилот, который некому оценивать.

Что делать после первой победы

Хороший результат на второй неделе не значит, что работа закончена. Держите ту же метрику ещё месяц и следите за ней в обычных условиях. Если время ответа упало с 18 часов до 4, или один человек вернул себе 6 часов в неделю, проверьте, остаётся ли это при изменении объёма, ротации персонала и накоплении крайних случаев.

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

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

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

После этого переходите к следующей ручной очереди с похожими входными данными. Если первая победа пришла от сортировки писем о возвратах, следующая очередь может быть запросами по гарантии или сообщениями об обновлении аккаунта. Похожие входы упрощают второй разворот, потому что команда уже понимает, где появляются ошибки и как их проверять.

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

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

Oleg Sotnikov проводит подобные практические проверки через oleg.is. Если у вас уже идёт один пилот и нужен второй взгляд на объём, контроль или следующую очередь, короткая консультация может не дать маленькой победе превратиться в дорогой беспорядок.