Вопросы, которые стоит задать перед добавлением ИИ-функции в стартап

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

Стартапы часто начинают не с задачи, а с инструмента. Кто-то видит демо, слышит, что конкурент добавил ИИ, или хочет красивее рассказать об этом инвесторам. Команда спрашивает: «Где мы можем использовать ИИ?» вместо того, чтобы спросить: «Что каждую неделю тормозит нас больше всего?»

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

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

Работы по проверке тоже может стать больше, а не меньше. Это случается часто. Основатель рассчитывает, что ИИ сэкономит два часа в день, а теперь кто-то должен проверять каждый ответ, исправлять тон, убирать неверные факты и следить, чтобы в процесс не просочились личные данные. Старая ручная задача могла занимать 20 минут. Новая «автоматизированная» — 40.

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

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

Найдите рабочий процесс, который действительно мешает

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

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

Попросите команду описать задачу так, как она происходит сегодня, простыми словами. Кто её делает? Как часто? Что её запускает? Что происходит, когда что-то идёт не так? Эти ответы говорят гораздо больше, чем запрос на «ИИ-поддержку» или «ИИ для продаж».

Несколько проверок обычно быстро отсекают шум:

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

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

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

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

Определите, кто принимает финальное решение

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

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

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

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

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

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

Человеческая проверка в ИИ-процессах — это не деталь, которую можно добавить потом. Это часть продукта. Если команда не может объяснить, кто говорит: «Да, это безопасно использовать», — функция всё ещё слишком плохо определена.

Задайте границы данных до дизайна

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

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

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

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

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

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

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

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

Определите самый маленький полезный результат

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

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

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

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

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

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

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

Разберите идею по шагам

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

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

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

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

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

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

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

Простой пример для стартапа

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

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

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

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

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

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

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

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

Ошибки, которые тратят время впустую

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

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

Объём тоже создаёт проблемы. В ранние версии часто запихивают слишком много данных: всю базу знаний, каждую заметку клиента, каждый внутренний файл. Больше входа не всегда означает лучшее качество ответа. Чаще это значит больше шума, больше риска и более медленное тестирование. Меньшие границы работают лучше. Начните с одного источника, одной задачи и одной команды.

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

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

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

Быстрая проверка перед тем, как сказать «да»

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

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

Потом проверьте не только модель, но и весь процесс вокруг неё:

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

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

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

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

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

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

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

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

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

Эти цифры делают тест честным. Функция, которая экономит 20 минут, но добавляет 30 минут проверки, не помогает. Функция, которая работает только на самых чистых данных, ещё не готова к обычному стартап-хаосу.

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

Если команда не может прийти к единому мнению по идее, поможет внешний взгляд. Олег Сотников работает со стартапами как частичный CTO и советник, и именно такие вопросы по объёму он разбирает на oleg.is до того, как команда потратит недели на не ту функцию.

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