Себестоимость проекта с нейросетью: как считать в агентстве
Агентство отличается от продуктовой команды одним: расход нужно относить на конкретного клиента. Пока проект один, это неважно. На третьем возникает вопрос, который без подготовки решается только на глаз.
Разделение должно быть заранее
Восстановить разбивку постфактум невозможно. Если все проекты ходили через один ключ, у вас есть общая сумма и ничего больше.
Самый надёжный способ — отдельный ключ на каждого клиента. Выгрузка из личного кабинета сразу даёт разбивку, никаких расчётов вручную. Дополнительный плюс: завершение работы с клиентом означает отзыв одного ключа, а не правку общей конфигурации.
Метка проекта внутри одного ключа тоже работает, но требует дисциплины. На практике часть вызовов остаётся без метки, и точность теряется.
Из чего складывается смета
Четыре строки, и первая обычно не самая большая.
**Запросы к моделям.** Считаются по выгрузке. Единственная строка, которую можно измерить точно.
**Время разработчика.** Интеграция, отладка промптов, обработка ошибок. Как правило, доминирует на старте.
**Поддержка решения.** Разбор жалоб, правка промптов при обновлении модели, мониторинг. Регулярная величина, которую забывают закладывать.
**Проверка результатов людьми.** Там, где ответы модели проверяются перед отправкой, это прямые часы.
Как считать на этапе предложения
До запуска точных цифр нет, но порядок величины оценить можно.
- Возьмите десять типичных запросов клиента.
- Прогоните их и посмотрите фактический расход.
- Умножьте на ожидаемое количество обращений в месяц.
- Добавьте запас в полтора раза — реальные запросы всегда объёмнее тестовых.
- Отдельной строкой посчитайте часы на интеграцию и поддержку.
Пятый пункт важнее первых четырёх. Проекты становятся убыточными не из-за запросов, а из-за недооценённой поддержки.
Что закладывать в поддержку
Три регулярных статьи, которые возникают в любом проекте.
Разбор обращений: часть ответов клиенту не понравится, и кто-то должен посмотреть, что произошло.
Реакция на обновления моделей: версии выводятся из обращения, поведение меняется, промпты требуют подгонки.
Изменение данных клиента: обновился регламент — нужно переиндексировать базу знаний и проверить, что ответы не поехали.
Договоритесь с клиентом заранее, что входит в поддержку, а что оплачивается отдельно. Без этого любая правка промпта превращается в спор о том, была ли она изначально обещана.
Как выставлять счёт
Два подхода, и оба рабочие.
**Фиксированная плата за сопровождение.** Проще для клиента, предсказуемее для вас, но требует запаса на случай роста нагрузки.
**Перевыставление расхода плюс работа.** Прозрачнее, но означает, что клиент видит колебания и задаёт вопросы каждый месяц.
Смешанная схема обычно удобнее: фиксированная часть покрывает поддержку, переменная — фактический расход сверх оговорённого объёма.
Что показывать клиенту
Выгрузку расхода по его ключу и разбивку по сценариям. Это снимает большинство вопросов: видно, что именно потребляет бюджет.
Не показывайте внутреннюю кухню в виде названий моделей и параметров, если не готовы обсуждать их каждый раз. Достаточно уровня «поиск по базе знаний», «подготовка ответов», «разбор документов».
Когда проект перестаёт быть выгодным
Три признака, при которых стоит пересмотреть условия.
Доля проверки людьми не снижается со временем — значит, качество не выросло и автоматизация не состоялась.
Каждое обновление модели требует дня работы — промпты слишком хрупкие, нужен тестовый набор.
Расход растёт быстрее объёма задач — скорее всего, разбух контекст, и это чинится один раз.
Как объяснять цифры клиенту
Разговор о стоимости упрощается, если заранее договориться, в каких единицах вы её обсуждаете. Технические величины вроде токенов клиенту ничего не говорят и вызывают ощущение, что его запутывают.
Переводите в понятное: стоимость одного обработанного обращения, одной подготовленной карточки, одного разобранного документа. Такие единицы клиент сопоставляет с тем, что раньше делали люди, и разговор становится предметным.
Отдельно объясните, почему расход колеблется. Причины обычно простые: сезонность обращений, изменение длины документов, добавление нового сценария. Если проговорить это до старта, ежемесячные вопросы не возникают.
Что фиксировать в договоре
Четыре пункта, которые предотвращают большинство споров.
Границы поддержки: что входит в ежемесячную плату, а что оплачивается отдельно.
Порядок действий при обновлении модели: кто оплачивает подгонку промптов, если поставщик вывел версию из обращения.
Оговорённый объём и условия при его превышении.
Принадлежность промптов, тестового набора и данных по окончании работ. Этот пункт забывают чаще остальных, а он определяет, сможет ли клиент уйти к другому подрядчику без потерь.
Четыре абзаца в договоре экономят несколько неприятных разговоров в год.
Коротко
Разделяйте доступ ключами до старта, а не после. Считайте не только запросы, но и часы: интеграцию, поддержку и проверку. Договаривайтесь о границах сопровождения письменно. И раз в квартал сверяйте фактическую себестоимость с той, что закладывали в предложение, — расхождение обычно обнаруживается там, где его не ждали.