Готовность стартапа к ИИ: 3 теста, которые стоит пройти

Почему стартапы слишком рано берутся за ИИ

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

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

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

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

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

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

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

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

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

Тест 1: Проверьте стабильность процесса

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

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

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

У стабильного процесса обычно четыре признака:

• Он каждый раз начинается с одного и того же триггера.
• Люди идут примерно в одном и том же порядке.
• Они используют один и тот же источник правды.
• В конце получается один и тот же результат.

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

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

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

Тест 2: Измерьте объем исключений

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

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

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

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

Очередь возвратов — хороший пример. На бумаге черновики ответов на возврат кажутся простыми. После недели наблюдения команда обнаруживает, что 4 из 10 обращений требуют человека, потому что отсутствует запись о покупке, политика написана слишком расплывчато или клиент в одном запросе просит и частичную компенсацию, и изменение плана. Это высокий объем исключений.

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

Тест 3: Проверьте ресурс на проверку

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

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

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

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

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

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

Небольшой стартап может проверить это за одно утро. Руководитель операций проверяет 12 ответов поддержки, написанных ИИ, и находит, что 4 нужно править, 2 — полностью переписывать, а сама проверка занимает 35 минут. Это полезно. Это показывает команде, что пилот возможен только если сузить его рамки или освободить больше времени.

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

Как пройти все три теста за одну неделю

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

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

Пятидневного прохода достаточно:

• День 1: Опишите процесс одним предложением, затем отметьте, где он начинается, где заканчивается и кто за него отвечает.
• День 2: Посмотрите от десяти до двадцати недавних случаев и отметьте, какие из них шли по стандартному пути.
• День 3: Отметьте каждое исключение и запишите, почему оно случилось.
• День 4: Посчитайте время проверки для каждого случая. Считайте только минуты человеческой проверки, а не время ожидания.
• День 5: Примите одно решение: запускать, подождать или сначала исправить.

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

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

Сделайте это до сравнения инструментов. После неудачного пилота команды часто винят софт. Во многих случаях процесс просто никогда не был готов.

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

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

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

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

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

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

Поэтому первая версия должна оставаться маленькой. Пусть ИИ делает две задачи: классифицирует входящие письма и готовит черновики ответов на частые вопросы. Основатель утром проверяет эти черновики и при необходимости правит их. Запросы на особые цены по-прежнему уходят сразу человеку.

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

Ошибки, которые искажают результат

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

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

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

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

Проверка не может зависеть от свободной минуты

Многие стартапы говорят, что будут «проверять результаты вручную», но на практике это значит, что кто-то смотрит их только тогда, когда у него появляется свободная минутка. Это не проверка. Это удача.

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

Покупать софт до того, как вы определили стоп-правила, — еще одна дорогая ошибка. Как только деньги уже потрачены, команды начинают давить вперед, чтобы оправдать покупку.

Напишите стоп-правила до старта пилота:

• Останавливайте пилот, если очередь на проверку превышает два дня.
• Останавливайте пилот, если доля исключений остается выше, чем в ручном процессе.
• Останавливайте пилот, если сотрудники тратят больше времени на исправления, чем инструмент экономит.

Так вы сохраните честность теста. И еще это не даст поспешному эксперименту превратиться в стандарт работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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