AI-дорожная карта для стартапов: как сортировать портфельные компании

Почему один план для портфеля не работает

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

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

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

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

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

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

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

Что измерить, прежде чем предлагать AI

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

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

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

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

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

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

Как оценить один процесс

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

Используйте простую шкалу от 1 до 5 для трех факторов:

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

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

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

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

С чего начинать, когда оценка высокая

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

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

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

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

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

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

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

Что делать, когда оценка низкая

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

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

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

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

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

Достаточно простого плана перезапуска:

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

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

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

Возьмем три компании в одном потоке акселератора. Всем нужна помощь AI. Но стартовые условия у них совсем разные.

Первая — B2B SaaS-команда из 12 человек. Она получает около 900 обращений в поддержку в месяц, и больше половины из них сводятся к одним и тем же 25–30 вопросам: сброс пароля, путаница с оплатой, настройка функций и баг-репорты, которые нужно куда-то передавать. Документация неплохая, продукт меняется каждые несколько недель, и большинство тикетов уже укладываются в понятные категории. Сортировка обращений в поддержку — очевидная первая задача.

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

Вторая компания — маркетплейс. На бумаге все выглядит идеально, потому что нагрузка на проверки огромная: 20 000 объявлений, 3 000 обновлений от продавцов в неделю и очень маленькая операционная команда. Проблема в каталоге. Примерно у 15% объявлений не хватает базовых полей, продавцы называют один и тот же товар пятью разными способами, а дубли товаров постоянно просачиваются внутрь.

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

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

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

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

Какие ошибки акселераторы совершают в начале

Большинство ранних AI-пилотов ломается по простым причинам. Акселератор сначала выбирает инструмент, а потом пытается втиснуть в него все стартапы. Обычно это не работает.

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

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

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

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

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

• Кто каждый день проверяет результаты?
• Сколько времени занимает эта проверка?
• Что происходит, когда модель ошибается?
• Может ли команда быстро остановить процесс?

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

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

Короткая проверка перед одобрением пилота

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

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

Перед тем как что-то одобрять, проверьте пять вещей:

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

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

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

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

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

Что акселераторам делать дальше

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

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

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

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

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

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