Что не стоит автоматизировать с помощью AI в компании с AI-first подходом

Почему это быстро идёт не так

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

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

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

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

Плохие входные данные быстро распространяют ущерб. Неверное имя поля, устаревшая заметка в CRM, пропущенный статус или наполовину очищенная таблица могут протащить маленькую ошибку через несколько шагов, прежде чем это кто-то заметит. Короткое неверное резюме превращается в неправильный тикет. Неправильный тикет запускает неверный ответ. А потом кто-то доверяет этому, потому что это сделала «система».

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

Вот почему сильная работа в AI-first компании может сначала выглядеть медленнее. Сложность не в том, чтобы написать промпт. Сложность в том, чтобы убрать нестабильные области продукта, очистить слабые потоки данных и добиться, чтобы команда согласилась, как выглядит правильный результат. До этого автоматизация может превратить локальную проблему в общекомандную.

Не автоматизируйте работу с размытыми правилами

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

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

Неписаные исключения — ещё один тревожный сигнал. Сотрудники держат их в голове: «Обычно делаем X, если только клиент не на продлении» или «Пропускаем этот шаг для старых аккаунтов». Люди какое-то время могут подстраиваться. Модель обычно не может, и команда может не заметить ошибки, пока не начнут жаловаться клиенты.

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

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

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

Чёткие правила экономят больше времени, чем когда-либо сэкономит спешно собранный бот.

Пока оставьте в покое меняющиеся области продукта

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

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

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

Новые функции требуют той же осторожности. В начале открытые вопросы нормальны, но для автоматизации это плохой материал. Если команда всё ещё спрашивает: «Кто это утверждает?» или «Показывать это пользователю до оплаты?», подождите. Человеческое решение дешевле, чем каждые несколько дней перестраивать хрупкие сценарии.

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

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

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

Стабильная работа — это скучно, и в этом её плюс. Обычно именно там автоматизация начинает приносить пользу.

Следите за слабыми потоками данных

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

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

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

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

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

Если путь под задачей ненадёжен, проблема не в модели. Проблема в пути.

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

Оставляйте важные решения людям

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

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

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

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

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

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

Как проверить задачу до автоматизации

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

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

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

Потом попросите трёх сотрудников объяснить правило самостоятельно. Делайте это по отдельности, а не на общем созвоне. Если один говорит: «Одобряй, если клиент выглядит серьёзным», а другой — «Одобряй, если бюджет понятен», у вас нет правила. У вас есть суждение, привычки и догадки.

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

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

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

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

Простой пример стартапа

Команда из пяти человек в SaaS-компании решает использовать AI для писем пробным пользователям. Звучит просто. Новые пользователи регистрируются, через несколько дней получают напоминание, а потом видят предложение перейти на платный тариф.

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

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

Поэтому команда не начинает с автоотправки. Она начинает с черновиков. AI пишет первую версию каждого письма, включая тему и текст предложения. Затем человек проверяет цену, сегмент и время отправки, прежде чем что-либо уйдёт наружу.

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

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

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

Ошибки, которые команды совершают в начале

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

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

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

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

Разрастание инструментов быстро проявляется в AI-first командах. Компания подключает чат, почту, CRM, документы, тикеты и биллинг в первый же день, потому что всё кажется простым в настройке. Потом меняется одно поле, падает один webhook или упирается один лимит API, и вся цепочка начинает терять контекст. Слабые потоки данных не становятся безопаснее от того, что между ними стоит больше инструментов.

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

Лучший темп намеренно скучный. Сначала очистите процесс. Проверьте одну узкую задачу. Несколько недель измеряйте ошибки. Оставляйте человека в контуре, пока ошибки не станут маленькими, предсказуемыми и дешёвыми в исправлении.

Проверки перед автоматизацией

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

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

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

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

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

Нужна и быстрая кнопка остановки. Если AI-агент может отправлять письма, обновлять записи или утверждать действия, кто-то должен уметь немедленно поставить его на паузу.

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

Простой тест всё подытоживает: можете ли вы ясно объяснить работу, доверять входным данным, быстро остановить процесс и отменить ущерб? Если ответ нет, вы пока не экономите время. Вы просто перекладываете риск.

Что делать дальше

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

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

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

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

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

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

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