Покажите инвесторам сложность продукта до привлечения инвестиций

Почему инвесторы не видят скрытую работу

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

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

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

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

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

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

Что на самом деле входит в сложность продукта

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

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

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

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

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

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

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

Соберите простую карту операционной нагрузки

Для этого не нужна сложная система. Достаточно таблицы с пятью столбцами.

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

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

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

Будьте честны в вопросе ответственности. Фаундеры часто пишут «support», когда на самом деле ответ звучит как «сначала support, потом senior engineer, а иногда CTO». Инвесторы быстро считывают эту разницу, потому что она показывает, добавляет ли рост рутинную работу или дорогую работу.

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

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

Отслеживайте исключения в общей таблице

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

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

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

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

Потом считайте, как часто каждый тип появляется в месяц. Случай, который возникает один раз, может быть шумом. Случай, который появляется восемь раз в месяц, уже часть вашей операционной нагрузки. Гораздо сильнее звучит фраза «Эта проблема затронула 14 аккаунтов в прошлом месяце», чем «Она иногда возникает».

Время тоже важно. Отмечайте, сколько занимает каждое исправление, даже если оценка грубая. Десять минут, 30 минут и два часа уже дают полезную картину. Проблема, которая случается часто и съедает по 25 минут каждый раз, может незаметно отнимать у roadmap половину человека.

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

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

Измеряйте нагрузку на поддержку простыми цифрами

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

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

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

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

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

Ещё одно сравнение делает картину яснее. Разделите клиентов на low-touch и heavy-touch группы. Клиенты с низким касанием почти не нуждаются в помощи после настройки. Клиенты с высокой нагрузкой продолжают возвращаться с вопросами, исключениями и срочными запросами. Если 20 процентов клиентов создают 70 процентов нагрузки на поддержку, скажите об этом прямо. Именно отсюда и идёт давление на маржу.

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

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

Пример небольшой SaaS-команды

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

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

Нагрузка на поддержку начинается сразу после настройки. Каждое кастомное правило создаёт новые вопросы в инбоксе: «Почему эта строка не прошла?», «Можно ли пропустить этот шаг для одного клиента?», «Почему теперь экспорт выглядит иначе?» Каждый тикет по отдельности кажется мелким. Вместе они могут съедать полдня.

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

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

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

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

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

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

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

Другая ошибка — прятать ручной труд под общим названием «operations». Когда фаундеры объединяют исправления онбординга, очистку аккаунтов, корректировку импортов и общение с клиентами в одну корзину, реальная нагрузка исчезает. Лучше назвать работу прямо, даже если цифра выглядит неприятно.

Средние значения тоже скрывают проблему. Если вы говорите, что настройка занимает «примерно 2 часа», вы можете прятать настоящую историю. Возможно, простые аккаунты занимают 20 минут, а сложные — 6 часов. Этот разброс важен, потому что инвесторы думают о масштабе.

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

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

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

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

Быстрая проверка перед встречей

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

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

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

Нагрузка на поддержку тоже становится понятнее, если разделить её по группам клиентов. Клиент self-serve, который раз в квартал задаёт один вопрос по биллингу, сильно отличается от крупного аккаунта, которому нужна еженедельная помощь. Даже грубое разделение полезно: self-serve клиенты — low-touch, малому бизнесу нужно больше подсказок на старте, а крупные аккаунты создают более тяжёлую нагрузку от исключений.

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

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

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

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

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

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

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

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

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

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

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

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