Как выбрать AI-пилот, который быстро обучит вашу команду

Почему первые AI-пилоты буксуют

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

Они начинают с чего-то эффектного, например «AI-ассистент для продаж» или «бот для каждого вопроса поддержки», ещё до того, как выберут задачу, которая повторяется почти одинаково каждую неделю. Демонстрация может выглядеть отлично десять минут. Повседневная работа куда менее прощающая.

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

Потом появляются исключения. Люди говорят: «У большинства счетов-фактур один и тот же порядок» или «Большинство заявок простые». Слово — «большинство» — и прячет проблему. Кто-то в финансах знает, какой поставщик всегда ломает формат. Кто-то в поддержке знает, какому клиенту нужен особый подход. Если эти правила живут только в головах сотрудников, пилот выглядит нормально на первой неделе и разваливается, как только появляются крайние случаи.

Слабые пилоты обычно похожи друг на друга:

• Задача звучит впечатляюще, но люди делают её каждый раз по-разному.
• Исходные материалы непоследовательны, неполные или разбросаны по разным инструментам.
• Особые случаи есть, но никто их не записал.
• Команда так и не договорилась, что значит «работает».

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

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

Как выглядят стабильные входные данные и известные исключения

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

Стабильные входные данные не обязаны быть идеальными. Им просто нужно быть достаточно похожими, чтобы кто-то мог сказать: «Когда это приходит, сначала проверяем вот эти несколько вещей». Если каждый случай приходит в разном формате, команда потратит больше времени на разбор хаоса, чем на понимание, помогает ли пилот.

Чаще всего это и есть самый ясный ответ на вопрос, как выбрать первый AI-проект: берите работу с повторяющимися входами и коротким набором правил. Во многих командах эти правила уже существуют. Они живут в привычках, старых цепочках писем или в памяти человека, который делает эту задачу каждый день. Этого достаточно, чтобы начать. Если кто-то может простыми словами объяснить, почему один запрос одобряют, перенаправляют или отклоняют, значит, процесс, скорее всего, готов к первому тесту.

Исключения важны не меньше. В реальной работе необычные случаи всегда есть. Разница в хорошем пилоте в том, что люди могут их назвать. «Нет номера заказа». «Клиент использовал не ту форму». «Сумма заказа выше лимита согласования». Когда у исключений есть названия, их можно посчитать. А когда их можно посчитать, можно решить, должен ли AI обрабатывать их сам, помечать их или передавать человеку.

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

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

Какая работа обычно подходит для первого пилота

Если вы пытаетесь выбрать первый AI-проект, пропустите эффектные идеи. Начинайте с работы, которая повторяется каждый день, идёт по понятному сценарию и уже включает проверку человеком. Скучная работа часто учит больше всего.

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

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

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

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

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

Они ещё и дают полезные ошибки. Возможно, у поставщика два названия. Возможно, клиент смешивает в одном сообщении вопрос по оплате и баг-репорт. Возможно, лид пишет «просто смотрю», но на деле выглядит серьёзно. Такие исключения помогают команде писать более хорошие правила, подсказки и шаги проверки.

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

Как выбрать один пилот шаг за шагом

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

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

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

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

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

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

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

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

Простой пример из повседневной работы

Хороший первый AI-проект часто прячется в скучном ящике входящих.

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

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

Большая часть такой сортировки не требует глубоких решений. Она следует нескольким шаблонам:

• Малые компании идут к менеджеру SMB-продаж.
• Лиды из крупных компаний идут в старшую аккаунт-команду.
• Запросы из неподдерживаемых регионов попадают в лист ожидания или получают ответ от партнёра.
• Срочные сообщения с недостающими деталями уходят на проверку человеком.

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

Разумный пилот в первый день не отправляет ничего автоматически. Модель читает форму, предлагает маршрут и даёт короткое объяснение, например: «Компания enterprise, Северная Америка, срочный запрос». Сотрудник одобряет или исправляет это. Этот дополнительный клик важен. Он снижает риск и создаёт чистую петлю обратной связи.

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

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

Поставьте границы до запуска

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

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

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

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

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

Достаточно короткого чек-листа:

• Запишите точную задачу одним предложением.
• Перечислите правила, когда нужен человек.
• Выберите один или два показателя успеха.
• Используйте небольшой образец с чистой разметкой.
• Проверяйте результаты ежедневно в первую неделю.

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

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

Ошибки, которые зря тратят время

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

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

Разрастание объёма съедает время очень быстро. Команда начинает с одного процесса, а потом в первый же день добавляет CRM-данные, историю писем и таблицы. И вот работа уже не про проверку одной идеи. Она превратилась в интеграционный проект.

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

Краевые случаи игнорируют до тех пор, пока пользователи не сталкиваются с ними в реальной работе. Кто-то проверяет чистые примеры, видит неплохой результат и объявляет, что всё готово. Потом система встречает дублированный заказ, отсканированный PDF или заметку клиента, написанную сокращениями, и доверие падает.

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

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

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

Представьте пилот по сортировке входящих. Если AI правильно распределяет 80% сообщений, но путается на спорах по возвратам, такие случаи нужно направлять человеку. Работа продолжается, пока команда учится.

Короткая проверка перед тем, как вы решитесь

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

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

Перед тем как что-то строить, прогоните короткий фильтр:

• За работу должна отвечать одна команда от начала до конца.
• Входные данные большую часть времени должны быть похожими.
• Правила должны помещаться на одной странице простыми словами.
• Странные случаи должны помещаться в короткий список.
• Один человек должен быстро проверять первые результаты.

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

Хорошо работает простое упражнение. Попросите команду принести десять свежих примеров этой задачи. Положите их рядом и ищите закономерности. Появляются ли одни и те же поля каждый раз? Следуют ли люди одному и тому же правилу в девяти случаях из десяти? Может ли кто-то объяснить исключения без долгой встречи?

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

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

Лучшая ранняя победа — не самая крупная задача. Это та, которую команда может объяснить, протестировать и исправить без драмы.

Что делать после первого результата

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

Пусть пилот работает, пока вы не сможете ответить на три простых вопроса:

• Какие исключения повторяются снова и снова?
• Какие входные данные сбивают модель или набор правил?
• Где людям всё ещё приходится вмешиваться вручную?

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

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

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

Если перед расширением вам нужен взгляд со стороны, Oleg Sotnikov на oleg.is работает как Fractional CTO и советник для стартапов. Он помогает стартапам и небольшим командам разбирать варианты пилотов, улучшать передачу задач и строить практичные AI-first процессы вокруг тех процессов, которые они уже понимают.