Себестоимость и маржа клиентской AI-интеграции

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

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

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

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

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

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

Резерв добавляется к известной себестоимости до расчёта цены. Он покрывает неопределённость, но не должен заменять конкретные статьи. Целевая маржа считается как прибыль, делённая на цену продажи; поэтому цена при марже 25 процентов выше себестоимости не на 25, а на одну треть. Калькулятор использует именно эту формулу и показывает валовую прибыль отдельно.

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

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

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

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