Проверка маржи AI-функций в одной таблице до запуска

Где у AI-проекта утекает маржа

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

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

Чаще всего маржу первой съедает человеческая проверка. Функция может стоить считаные центы за запуск, но короткая ручная проверка быстро меняет картину. Если сотрудник тратит 3 минуты на проверку каждого запроса при 100 запросах в день, затраты на труд очень быстро перекроют счёт за API.

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

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

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

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

Как настроить таблицу

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

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

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

В практичную структуру входят: функция или use case, ожидаемый месячный объём, цена за использование или за аккаунт, стоимость модели на один запуск, минуты на человеческое ревью, доля fallback, число обращений в поддержку на 100 использований, затем общая стоимость, gross margin и процент маржи.

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

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

Давайте понятные названия ячейкам, используйте один цвет для входных данных и добавляйте короткую пометку, откуда взялось число. «5% fallback из пилота» — этого достаточно. Вы не строите отчётность уровня finance. Вы строите таблицу, которую команда действительно будет открывать перед релизом.

Какие цифры собрать в первую очередь

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

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

1. Оцените число запросов на пользователя в месяц. Используйте реальные данные похожей функции, если они у вас есть. Если нет — сделайте низкий и высокий сценарий. Чат-бот, в который заходят один раз, и инструмент для ежедневной работы ведут себя совсем по-разному.
2. Запишите среднюю стоимость модели на один запрос. Учитывайте входные токены, выходные токены и дополнительные вызовы за кулисами. Если одно действие пользователя затрагивает две модели, считайте обе.
3. Оцените долю ответов, которые требуют человеческой проверки. Будьте строгими. Команда может сказать, что ревью нужно только в 5% случаев, а потом выяснится, что коммерческие предложения, юридические тексты или клиентские письма почти всегда должны проходить через человека.
4. Оцените долю запросов, которые ломаются и уходят на fallback. Это может быть повторный вызов модели, резервный сценарий на правилах или передача задачи человеку. Даже небольшой процент сбоев может уничтожить маржу по мере роста использования.
5. Оцените число тикетов в поддержку на 100 пользователей. AI-функции создают странную нагрузку, потому что пользователи жалуются на неверные ответы, медленные отклики, странный тон и потерянный контекст. Обычная продуктовая статистика поддержки часто это занижает.

После этого быстро проверьте здравый смысл. Если 1 000 пользователей делают 30 запросов в месяц, это 30 000 запросов. Даже крошечная стоимость модели на один запрос быстро превращается в реальный счёт. То же самое относится к ревью и fallback. Две минуты человеческой проверки на 10% ответов — это не мелочь.

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

Как посчитать время на ревью

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

Начните с месячного объёма запросов. Если вы ждёте 12 000 запросов в месяц, а человеку нужно проверить 8% из них, команда будет ревьюить 960 случаев.

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

Базовой таблице достаточно трёх формул:

• monthly reviews = monthly request volume x review rate
• monthly review hours = monthly reviews x minutes per review / 60
• monthly review cost = monthly review hours x loaded hourly team cost

Допустим, одна проверка занимает 4 минуты. При 960 проверках это 3 840 минут, или 64 часа в месяц. Если полная почасовая стоимость команды — $35, то ревью будет стоить $2 240 в месяц ещё до учёта fallback и поддержки.

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

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

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

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

Как оценить объём fallback

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

Сначала запишите жёсткое правило, что считается fallback. Если модель зависла по таймауту, дала ответ с низкой уверенностью, сломала форматирование, провалила проверку безопасности или заставила пользователя нажать «try again», это fallback. Если не учитывать такие случаи, таблица будет выглядеть лучше, чем реальность.

Разделяйте пути fallback. Повторный запуск означает, что система пробует ещё раз с новым промптом, другой моделью или более простым workflow. Ручной fallback означает, что человек читает, исправляет или завершает задачу. Частичный fallback означает, что модель делает часть работы, а человек дополняет остальное. Сюда же относится уход пользователя, потому что неудачные запросы часто превращаются в тикеты поддержки или churn.

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

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

Небольшой пример показывает разницу. Допустим, функция обрабатывает 10 000 запросов в месяц. Если 6% требуют одного дополнительного вызова модели по $0.03, это $18. Если 2% уходят к сотруднику поддержки на 6 минут при $0.50 за минуту, это $600. И то и другое — fallback, но только одна строка почти не двигает маржу.

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

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

Fallback — это не только показатель качества. Это ещё и строка расходов.

Как добавить стоимость поддержки

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

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

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

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

Подойдёт простая формула:

support cost per 100 users = total ticket time x hourly rate

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

Например, если 4 из 100 пользователей получили плохой результат, один попросит кредит на $15, а двоим понадобится по 10 минут человеческой доработки. Учитывайте и кредит, и труд.

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

Простой пример до запуска

Небольшая SaaS-команда хочет добавить AI-инструмент для ответов в свой help desk. Они планируют брать за него $6 в месяц с одного аккаунта. У них 300 платящих аккаунтов, и каждый, вероятно, будет отправлять около 8 запросов в месяц. Значит, функция будет обрабатывать примерно 2 400 AI-ответов в месяц.

Голая стоимость модели выглядит безобидно. Если один запрос стоит $0.05 с учётом модели и инфраструктуры, команда платит всего $120 в месяц. Многие основатели на этом и останавливаются, и это обычно ошибка.

Таблица становится честнее, когда в неё добавляют время на ревью и обработку сбоев.

В итоге остаётся $880 до учёта остальных расходов, то есть примерно 49% gross margin по функции. Для одних команд это нормально. Для других — уже слишком тонко, если добавить возвраты, усилия продаж и дополнительный мониторинг.

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

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

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

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

Хорошей проверке маржи нужны некрасивые цифры, а не демонстрационные. Основатели часто подставляют best case accuracy из внутренних тестов, чистые промпты или примеры от вендора. Реальные пользователи пишут расплывчатые запросы, вставляют сломанный текст и спрашивают одно и то же тремя разными способами. Небольшое падение точности может превратить дешёвую функцию в ручной сервис.

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

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

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

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

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

Проверки перед релизом

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

Относитесь к этому как к release gate, а не как к финансовому упражнению. Выручка с каждого использования всё равно должна покрывать стоимость модели, время на ревью, обработку fallback и поддержку. Если вы зарабатываете только в лучшем случае, запуск уже выглядит шатко.

Проверьте способность команды выдерживать короткий всплеск. Добавьте 25%–50% к числу ревью на два или три дня и посмотрите, успевает ли команда уложиться в обещанное время ответа. Смотрите на объём fallback в часах, а не только в процентах. Fallback на 6% может звучать нормально, но 6% от 4 000 задач может похоронить маленькую команду.

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

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

Простой пример помогает в это поверить. Допустим, функция приносит $2 000 в месяц в базовом сценарии, но всплеск использования поднимает ручное ревью с 8 часов в неделю до 28. Если эти дополнительные часы стоят $1 200, а поддержка добавляет ещё $500, маржа может исчезнуть, даже если adoption выглядит сильным.

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

Что делать, если таблица выглядит слабой

Не режьте цену первой. Дешёвое использование не исправляет плохую unit economics. Сначала сузьте use case, чтобы функция хорошо делала одну задачу, а не пыталась закрыть все крайние случаи в первый же день.

Чёткое обещание часто экономит больше денег, чем низкая цена. Если ваш инструмент пишет follow-up письма, версия 1 может работать только с короткими sales-коллами и фиксированной структурой. Если он суммирует документы, можно принимать только файлы определённой длины. Это само по себе снижает время на ревью, объём fallback и число тикетов поддержки.

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

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

Перед открытием всем запустите небольшой beta-тест. Даже 20–50 активных пользователей могут рассказать очень много. Сравните таблицу с реальностью: сколько минут уходит на ревью, какой процент запросов уходит на fallback и сколько тикетов поддержки приходится на 100 использований. Когда реальные данные заменяют догадки, таблица становится намного точнее.

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

Если хотите ещё один взгляд на допущения, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями над планами запуска, архитектурой продукта и экономикой AI-driven development до того, как они переходят в production. Такой разбор может уберечь команду от запуска функции, которая хорошо выглядит в демо, но слаба по марже в реальности.