Нейробариста своими руками: ИИ-агент приёма заказов с ROI-расчётом

1. Задача / для кого

Эта статья — для внедренцев и разработчиков, которые собирают ИИ-агента для общепита: кофейни, фастфуды, доставки, рестораны с приёмом заказов по телефону или через терминал самообслуживания. Это прикладное продолжение темы «нейробариста»: если в простом сценарии агент просто подбирает напиток, то здесь мы доводим его до полного цикла — приём заказа → апселл → оформление в кассовой (POS) системе.

Бизнес-боль, под которую мы строим решение, типична для любого заведения:

• Пик-часы. В обеденный или утренний пик касса не справляется: очередь растёт, гости уходят, а кассир физически не успевает обслуживать поток.
• Текучка и обучение персонала. Новый сотрудник путает модификаторы («без сахара», «на овсяном», «двойной эспрессо»), забывает пробить позиции и не знает, что к чему предложить.
• Несистемный апселл. Допродажа («сироп? десерт? соус?») происходит «по настроению»: в усталость или в спешке кассир её просто не делает, и заведение теряет выручку, которая лежала на поверхности.

Что должен уметь агент:

1. Принять заказ в свободной речи или тексте, включая модификаторы и нестандартные формулировки («как обычно, но без сахара»).
2. Предложить уместный апселл по правилам заведения — стабильно к каждому заказу, без навязчивости.
3. Сформировать корректный заказ с позициями и модификаторами и отправить его в POS-систему.
4. Передать «трудный» случай человеку (оператору или кассиру), а не выдумывать ответ.

Ориентир, что это реально работает на рынке: сеть кофеен «Дринкит» запустила нейробариста на платформе Yandex AI Studio — агент подбирает и кастомизирует напитки под предпочтения клиента, демонстрируя практическое применение LLM-агентов в розничном общепите.

Прежде чем переходить к архитектуре, важно зафиксировать границы кейса. Мы не строим «ИИ, который заменит весь персонал»: цель скромнее и реалистичнее — снять с кассира механическую часть (приём типового заказа и системный апселл), оставив человеку приготовление, нестандартные ситуации и финальный контроль. Именно такой кейс окупается и не вызывает отторжения у гостей и сотрудников. Также мы сознательно разделяем два режима внедрения: голосовой (телефон, терминал) и текстовый (мессенджер, виджет доставки) — архитектура у них общая, отличается только канальный слой, и начинать почти всегда дешевле с текстового.

2. Архитектура решения

Логически система делится на четыре слоя. Канал общения, «мозг» (LLM + правила), слой действий (инструменты к POS и складу) и слой данных/аналитики.

Ключевая идея: LLM не принимает финансовых и складских решений напрямую. Он лишь интерпретирует речь и вызывает строго описанные инструменты (function tools). Цена, наличие, итоговая запись чека — всё на стороне детерминированных функций и POS. Это снижает риск «галлюцинации цены» или продажи позиции из стоп-листа.

Для голосового сценария звонящий, по модели LiveKit, представлен как обычный участник комнаты (SIP-участник), а агент работает в той же сессии — это упрощает обработку входящих и исходящих звонков, поддержку DTMF (ввод с клавиатуры) и перевод на оператора.

Разберём слои подробнее, потому что именно границы между ними определяют надёжность системы:

• Канал. Точка входа гостя. Для голоса это телефонный номер (входящий звонок) или микрофон терминала самообслуживания; для текста — Telegram-бот или web-виджет на сайте/в приложении доставки. Канал отвечает только за транспорт: получить ввод гостя и доставить ответ агента. Никакой бизнес-логики здесь нет.
• «Мозг» агента. Связка LLM + системные инструкции + правила апселла. Его задача — понять намерение гостя, вести диалог, уточнять недостающее и решать, какой инструмент вызвать. Важно: «мозг» формулирует намерение («добавить капучино без сахара»), но не исполняет его сам.
• Слой действий (инструменты). Набор детерминированных функций, через которые агент влияет на внешний мир. Каждый инструмент имеет понятное описание для LLM и строгую внутреннюю логику. Именно здесь живут цена, наличие, формирование чека.
• POS и склад. Источник истины о меню, ценах, стоп-листе и оформленных заказах. Агент к нему обращается только через слой действий.
• Аналитика. Логи диалогов и метрики (конверсия апселла, частота передачи человеку, ошибки состава). Без неё пилот невозможно оценить.

Такое разделение даёт два практических эффекта. Во-первых, тестируемость: слой действий можно покрыть обычными юнит-тестами без участия LLM. Во-вторых, безопасность: даже если гость попытается «уговорить» модель на скидку или несуществующую позицию, цена и наличие придут из POS-функции, а не из текста диалога.

3. Стек / инструменты

Конкретный выбор зависит от рынка, требований к данным и того, есть ли у вас телефония. Ниже — рабочий набор; имена пакетов, версии и флаги CLI version-volatile, сверяйте с актуальной документацией.

• Оркестрация голосового агента: LiveKit Agents (Python) — даёт AgentSession как ядро жизненного цикла, конфигурацию пайплайна STT-LLM-TTS, обработку перебиваний и turn detection из коробки.
• Телефония: LiveKit Phone Numbers или сторонний SIP-провайдер через trunk’и и dispatch-правила маршрутизации .
• LLM: под русскоязычный общепит разумно рассмотреть YandexGPT через Yandex AI Studio (как в кейсе «Дринкит») либо другую модель с поддержкой function calling.
• Инструменты/действия: function tools — кастомные Python-функции, и/или provider tools от LLM-провайдера; поддерживается интеграция с MCP и асинхронные вызовы.
• POS: API вашей кассовой системы (iiko, r_keeper, Poster, Presto и т. п.). Здесь без выдумок: точные методы создания заказа берите из документации конкретного POS.
• Чат-канал (без голоса): Telegram-бот или web-виджет — для заведений, где телефонный сценарий не нужен.

Если телефония не требуется, голосовой слой (STT/TTS/SIP) можно убрать и оставить чистый чат-агент — архитектура и слой инструментов не меняются.

4. Пошаговая сборка с кодом

Покажем скелет на примере LiveKit Agents. Код иллюстративный — API и сигнатуры сверяйте с актуальной документацией.

Шаг 4.0. Каркас: меню, корзина, правила

Прежде чем подключать LLM, соберём детерминированный каркас. «Мозг» агента формулирует намерение («добавить капучино без сахара»), но цена, наличие и правила апселла живут в этих трёх классах, а не в промпте. Это и есть граница, которая делает систему предсказуемой и тестируемой: всё, что про деньги и склад, — обычный Python с юнит-тестами, а LLM работает только через тонкие tool-обёртки поверх него.

POS-клиент — источник истины о меню и стоп-листе, с идемпотентным create_order. Цены — в копейках/центах (int), чтобы избежать float-погрешностей в чеке.

Ожидаемый результат: меню и стоп-лист — только из POS; повторный create_order с тем же ключом не создаёт второй заказ.

Корзина живёт ровно один диалог, валидирует SKU по меню POS и считает свой идемпотентный ключ — хеш от снапшота и временного «бакета».

Ожидаемый результат: неизвестный SKU или позиция в стопе — это исключение, а не «галлюцинация чек-листа»; одинаковая корзина в том же бакете даёт тот же ключ.

Движок апселла — чистые правила в коде, без LLM. match возвращает максимум один offer: архитектурный принцип «ровно один уместный доп, без давления».

Ожидаемый результат: правила правит маркетинг прямо в коде (а не в промпте); если ни одно не сработало — допа нет, и это нормально.

Итого у нас три детерминированных слоя: POS как источник истины, корзина с валидацией и идемпотентным ключом, движок апселла на правилах. В 4.1 мы навешиваем на них тонкие tool-обёртки, к которым имеет доступ LLM. Полный исходник модулей — в code/ (см. шаг 4.6), там же тесты и simulate.py.

Шаг 4.1. Описать инструменты (действия агента)

Инструмент — это обычная функция с описанием, которое видит LLM. Описание должно быть однозначным, а вся «жёсткая» логика (цена, наличие) — внутри функции, не в промпте.

Ожидаемый результат: агент получает три безопасных действия. Он не может «придумать» позицию вне меню — add_item примет только реальный sku, а get_menu отдаёт стоп-лист.

Шаг 4.2. Задать поведение агента (промпт + правила апселла)

Ожидаемый результат: апселл встроен как правило диалога — «ровно один уместный доп, без повтора при отказе». Это делает допродажу системной, но не навязчивой.

Шаг 4.3. Поднять сессию

Ожидаемый результат: агент здоровается голосом, слушает заказ, обрабатывает перебивания (гость может перебить — turn detection это учитывает) и ведёт диалог до оформления.

Шаг 4.4. Инструмент апселла и передачи человеку

Апселл стоит вынести в отдельную функцию, чтобы правила допродажи жили в коде и легко правились маркетингом, а не «зашивались» в промпт. Передача оператору — обязательный escape-hatch.

Ожидаемый результат: правила апселла редактируются вне промпта (например, «к холодному кофе летом — не предлагать горячую выпечку»), а спорные ситуации гарантированно уходят человеку с понятной причиной в логе.

Шаг 4.5. Локальная проверка перед телефонией

Сначала отлаживайте логику в текстовом режиме (или в консоли), не подключая SIP — так быстрее итерации и дешевле тесты.

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

Шаг 4.6. Запуск проекта локально

Полный воспроизводимый код всех сниппетов лежит в подпапке

code/ рядом со статьёй. Он не требует LiveKit-аккаунта и не ходит в

сеть — для итераций по логике заказа и апселла этого достаточно.

См. подробнее code/README.md. Подключение реального LiveKit и

LLM-провайдера — опциональный шаг (раскомментировать livekit-agents в requirements.txt и завести ключи).

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

5. Интеграции

• POS. Главная интеграция. create_order должен переводить корзину в формат конкретной кассы (позиции, модификаторы, скидки, тип оплаты). Оплату на терминале обычно подтверждает гость/кассир — не автоматизируйте списание без явного подтверждения.
• Меню и стоп-лист. Тяните из POS в реальном времени: позиция в стоп-листе не должна предлагаться и тем более продаваться.
• Телефония. Через SIP-trunk и dispatch-правила; DTMF — запасной ввод, если распознавание речи буксует.
• Передача оператору. Инструмент handoff_human — обязательный escape-hatch: спорные ситуации, жалобы, нестандартные запросы уходят человеку.
• Внешние действия через MCP. Если у вас уже есть MCP-серверы (CRM, лояльность), агент может вызывать их как инструменты.

Практический мини-разбор интеграции с POS

Типичная ошибка — считать POS «чёрным ящиком, куда просто шлём заказ». На деле здесь несколько нюансов:

• Маппинг позиций. В диалоге гость говорит «капучино», а в POS это sku с конкретным размером и базовым молоком. Заведите явную таблицу соответствий «фраза/синоним → sku», иначе агент будет путать варианты.
• Модификаторы. «Без сахара», «на овсяном», «двойной» — это модификаторы конкретного sku, и POS обычно хранит их как отдельные сущности с ценой. Передавайте их структурно, а не строкой в комментарии.
• Стоп-лист и доступность. Перед предложением и тем более перед create_order сверяйтесь с актуальным наличием: позиция могла «уйти в стоп» за время диалога.
• Идемпотентность. Сетевой сбой не должен приводить к двойному оформлению заказа. Используйте идемпотентный ключ заказа, если POS его поддерживает.

6. Запуск / метрики

Запускать стоит поэтапно, а не «сразу на весь зал»:

1. Пилот в одной точке / в одном канале (например, только Telegram-заказы навынос). Минимизируйте риск и соберите реальные диалоги.
2. Shadow-режим для апселла. Сначала агент логирует, какой доп он предложил бы, без показа гостю — оцените уместность правил до запуска вживую.
3. Постепенное расширение на телефон и терминалы после отладки.

Что измерять (по реальным данным вашего пилота, без выдуманных цифр):

• доля заказов, доведённых агентом до оформления без вмешательства человека;
• доля заказов с принятым допом (конверсия апселла) и влияние на средний чек;
• частота handoff_human — индикатор пробелов в сценарии;
• ошибки в составе заказа (модификаторы, стоп-лист) — целевой показатель близок к нулю.

Чтобы было нагляднее, как выглядит целевой диалог в проде, вот короткий сценарий приёма заказа с апселлом (текстовая расшифровка голосового звонка):

Агент:  Здравствуйте! Готов принять заказ. Что желаете?
Гость:  Капучино, средний, на овсяном.
Агент:  Капучино средний на овсяном молоке. Сахар добавить?
Гость:  Без сахара.
Агент:  Принял. К капучино отлично идёт сырник — добавить? (апселл: 1 доп)
Гость:  Давайте.
Агент:  Итого: капучино средний на овсяном без сахара и сырник, сумма N руб.
        Оформляю? (проговаривание состава и суммы)
Гость:  Да.
Агент:  Заказ №1234 оформлен, можно оплатить на терминале.
        (вызов create_order → POS)

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

Развёртывание и эксплуатация

При выводе в прод учтите эксплуатационные моменты: агент-воркер должен переживать перезапуски без потери активных диалогов, нужен мониторинг доступности POS-API (если касса недоступна — агент обязан честно сказать об этом и/или передать человеку, а не «оформлять в пустоту»), и стоит заложить graceful-деградацию голосового канала на DTMF, если распознавание речи в шумном зале сбоит. Конкретные параметры развёртывания (масштабирование воркеров, регионы) сверяйте с актуальной документацией платформы.

Важно: метрики должны отражать реальный исход для гостя, а не легко-«накручиваемый» прокси. Известный антипример — чат-боты контакт-центров, которые оптимизировали KPI в ущерб клиенту (сбрасывали звонок до негативной оценки) и в итоге его раздражали. Цель апселл-агента — уместная допродажа и удобство, а не «максимизация чека любой ценой».

7. Безопасность и данные (ИБ-блок)

• Персональные данные. Имя, телефон, история заказов, а для голосового канала — запись голоса — это ПДн. Обрабатывайте их по требованиям 152-ФЗ: основание обработки, согласие, сроки хранения, ограничение доступа. Для звонков предупреждайте о записи.
• Минимизация и хранение. Храните только нужное; записи голоса — минимальный срок. Учитывайте региональные ограничения для комплаенса и шифрование трафика (SRTP для SIP) — упоминается в документации телефонии.
• Разграничение прав. Создание заказа, скидки и тем более операции оплаты должны выполняться от ограниченных, аудируемых учётных записей. Никаких «полных прав» у агента к POS.
• Решения принимает человек. Возвраты, спорные суммы, жалобы, отмена оплаты — за оператором/кассиром. Агент только готовит и передаёт.
• Защита от prompt injection. Свободная речь гостя — недоверенный ввод. Не позволяйте репликам гостя менять цены или правила: цена и наличие — только из POS-функций, не из текста диалога.

Дисклеймер: финальное решение по меню, ценам, скидкам и спорным ситуациям всегда принимает человек; обработка ПДн — в рамках 152-ФЗ и с авторизацией доступа.

8. ROI (в цифрах)

Этот блок заменяет качественный раздел ROI. В моём понимании правильно считать не «среднюю отдачу по рынку» (её не существует), а три модельных сценария, в которых видно, что и как на окупаемость влияет. Все цифры — оценочные, помечены как модель/ориентир. Полноценную окупаемость для своего заведения считайте на цифрах своего пилота — модели ниже нужны, чтобы откалибровать ожидания и понять, где у проекта самые «хрупкие» допущения.

8.1. Допущения и границы модели

Прежде чем подставлять числа, фиксируем рамки — иначе любой ROI превращается в «нарисуем под бюджет».

• Валюта и горизонт. Расчёт в ₽ по тарифам РФ-провайдеров на горизонте 2026 года. Ставки персонала, цены LLM-токенов, минуты SIP-телефонии и подписки на хостинг — version-volatile: сверяйте с актуальными прайсами на момент пилота. Никаких «среднерыночных» процентов не выдумываем.

Полная стоимость владения (TCO), как в прошлой статье. В OPEX обязательно входят: токены LLM, минуты телефонии (для голосового канала), инфраструктура (LiveKit-агент/воркеры/мониторинг), время инженера на поддержку правил и стоп-листов, время эксперта на ревью диалогов. Зарплата «замещаемого кассира» в расчёте экономии не фигурирует — мы не заменяем человека, мы снимаем механический ввод и системно делаем апселл.

• Канал. Голос дороже текста в разы — за счёт STT/TTS и SIP-минут. В сценариях «малое кафе» и «сеть» — голос+чат, в «тёмной кухне» — только чат. Голосовая доля в общей нагрузке резко двигает OPEX и поэтому отдельно вынесена в sensitivity.
• LLM-токены. Модель оценки: один заказ-диалог = 1500–3000 input + 500 output токенов (на голосе чуть больше из-за повторов и уточнений). Кириллица токенизируется хуже латиницы примерно в 1.5–2 раза — в стоимости это уже учтено через верхнюю границу диапазона. Цена токенов взята как ориентир для русскоязычных LLM (YandexGPT-класс или совместимая модель через API): ~30–80 ₽ за 1 млн input-токенов и ~120–240 ₽ за 1 млн output-токенов. Это диапазон, а не факт; реальный счёт от провайдера может отличаться.
• Телефония. SIP-минута РФ-провайдера: 0.5–1.5 ₽/мин входящих, плюс ежемесячная плата за номер 300–800 ₽. Средняя длина голосового заказа — 1.5–2 минуты.
• Ставка кассира. 250–400 ₽/час в зависимости от региона. Берём 300 ₽/час как ориентир для расчётов экономии часа в пик.
• Конверсия апселла — главный рычаг и главный риск. Три сценария: 2–5% (пессимистичный), 7–10% (базовый), 12–15% (оптимистичный). Конверсия — это доля заказов, к которым системно добавился доп. Средняя цена допа берётся как 15% от среднего чека (булочка к кофе, соус к блюду — это типичная пропорция, но проверяйте на своём меню).
• Снижение ошибок ввода. Консервативно: 1–3% от выручки в месяц, которая до автоматизации уходила на возвраты, корректировки, перепечатывание чека. Берём 2% как базу.

И отдельно — что мы НЕ считаем:

• Имиджевый эффект, «современность бренда», PR — это не операционная экономика.
• Сокращение ФОТ — мы не закладываем увольнение кассира. Экономия идёт через прирост пропускной способности в пик и системный апселл, а не через минус сотрудника. (Это прямой урок из № 91: «увольнения под автоматизацию» — самая частая причина отсутствия ROI.)
• Рост лояльности от «удобства приёма заказа» — слишком зыбкая величина, чтобы строить на ней бизнес-кейс.

8.2. Сценарий 1. Малое кафе (1 точка, голос+чат)

Профиль: 1 точка, 150 заказов/день, средний чек 350 ₽, голосовой канал на входящие заказы навынос + чат-виджет. Месячный объём: ~4500 заказов, выручка ~1.58 млн ₽/мес.

CAPEX (единоразово)

OPEX (в месяц)

Главное здесь: токены — почти ничего, а 70% OPEX — это люди, которые поддерживают и проверяют систему. Именно это «забывают» в бизнес-кейсах и потом удивляются, что ROI ушёл в минус.

Выгода (в месяц)

Пояснение по пропускной способности: мы НЕ считаем «сэкономленные часы кассира» как минус ФОТ. Мы считаем дополнительные заказы, которые в пик сейчас теряются (гость уходит из очереди). Это умножаем на маржу, а не на выручку — иначе завысим эффект.

Окупаемость

• Чистая месячная выгода (база) = 64 000 − 33 000 = 31 000 ₽/мес
• Payback при CAPEX 350 000 ₽ = 350 000 / 31 000 ≈ 11 мес
• ROI 12 мес = (12×31 000 − 350 000) / 350 000 ≈ +6%

Без иллюзий: для малого кафе с чеком 350 ₽ голосовой канал окупается едва-едва, и почти весь резерв ROI висит на конверсии апселла. Уберёте телефонию — payback падает в 1.5–2 раза.

8.3. Сценарий 2. Сеть кофеен (5 точек, общий контакт-центр)

Профиль: 5 точек, 250 заказов/точка/день, средний чек 380 ₽, общий голосовой контакт-центр на сеть + чат-канал. Месячный объём: ~37 500 заказов, выручка ~14.3 млн ₽/мес.

CAPEX (единоразово)

OPEX (в месяц)

Выгода (в месяц)

Окупаемость

• Чистая месячная выгода (база) = 594 000 − 175 000 = 419 000 ₽/мес
• Payback при CAPEX 800 000 ₽ = 800 000 / 419 000 ≈ 1.9 мес
• ROI 12 мес = (12×419 000 − 800 000) / 800 000 ≈ +528%

Сеть — главный бенефициар. CAPEX размазывается на 5 точек, апселл умножается на объём, а единый QA-контур держит качество. Это типичный паттерн: юнит-экономика общепита разворачивается в плюс именно на масштабе, а не на одной точке.

8.4. Сценарий 3. Доставка / тёмная кухня (1 точка, только чат)

Профиль: 1 точка, 400 заказов/день, средний чек 700 ₽, только чат-канал (приложение/мессенджер/виджет на сайте). Голоса нет — нет и SIP-расходов. Месячный объём: ~12 000 заказов, выручка ~8.4 млн ₽/мес.

CAPEX (единоразово)

OPEX (в месяц)

Выгода (в месяц)

Окупаемость

• Чистая месячная выгода (база) = 332 000 − 72 000 = 260 000 ₽/мес
• Payback при CAPEX 450 000 ₽ = 450 000 / 260 000 ≈ 1.7 мес
• ROI 12 мес = (12×260 000 − 450 000) / 450 000 ≈ +593%

Тёмная кухня — лучший кейс для чисто чат-агента: высокий чек, чистый канал, нет SIP-расходов, объём приличный. Здесь окупаемость самая быстрая.

8.5. Сводная таблица сценариев

Три сценария чувствительности к конверсии апселла. Конверсия — главный рычаг, поэтому ставим её в основу.

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

8.6. Sensitivity: что сильнее всего двигает payback

Три параметра, к которым модель чувствительна сильнее всего (по убыванию влияния):

1. Конверсия апселла. Сдвиг с 3% до 13% меняет ROI 12 мес на десятки и сотни процентных пунктов. Для малого кафе это разница между «убыток» и «прибыль». Поэтому правила апселла, состав предложения и оценка уместности — главная инженерная и продуктовая работа на пилоте.
2. Доля голосового канала. Голос дороже чата в разы: SIP-минуты + длиннее диалог = больше токенов. Если 100% заказов идут голосом, OPEX малого кафе растёт примерно вдвое и проект может не окупиться даже в оптимистичном сценарии. Лекарство: начинайте с чата, голос подключайте после доказанной экономики.
3. Стоимость интеграции с POS. CAPEX в нижнем углу диапазона (230 000) vs верхнем (510 000) — это разница в payback в 1.5–2 раза. Если у вашего POS есть готовый коннектор и публичное API — берёте нижнюю границу. Если интегратор «напишет с нуля под вашу старую кассу» — верхнюю, и стоит сначала спросить себя, не дешевле ли сменить POS.

Дополнительные факторы второго порядка (влияют, но слабее):

• Средний чек и средняя цена допа (на тёмной кухне с чеком 700 ₽ доп даёт 100+ ₽, на кофейне с чеком 350 ₽ — 50 ₽).
• Доля заказов, требующих handoff к человеку (если >20% — апселл-эффект ниже, время на эскалации съедает OPEX).
• Цены токенов LLM (волатильны, но в общем OPEX-балансе общепита это пока меньшая статья по сравнению с людьми и SIP).

8.7. Антипаттерны, обнуляющие ROI

Если хотите гарантированно потерять деньги — вот четыре способа.

1. Агрессивный апселл. Два-три допа подряд, повтор после отказа, давление на гостя — и вы оптимизировали средний чек ценой оттока. Через месяц-два конверсия возвращается на дно, а NPS падает. Это та же ловушка, что у чат-ботов поддержки в статье № 91: оптимизировали прокси-метрику, потеряли реальную. Правило в промпте раздела 4.2 выше (один уместный доп, без повтора) — это не вежливость, это юнит-экономика.
2. Оптимизация под прокси-метрику. «Доля заказов с допом» как KPI без учёта возвратов и повторных визитов — путь к тем самым «контакт-центрам, которые сбрасывают звонок до негативной оценки». Меряйте реальный исход (повторные визиты, NPS, доля жалоб), а не «процент апселла на демо».
3. Отсутствие синхронизации со стоп-листом. Агент бодро продаёт «авокадо-тост», авокадо в стопе с обеда, гость уходит без позиции и с раздражением — а вы получаете возврат, корректировку чека и испорченную репутацию. Стоп-лист в реальном времени — критическая интеграция, без неё вся «экономия на ошибках ввода» из расчёта выше превращается в новую статью расходов.
4. Попытка автоматизировать ВСЁ. Дорогой long-tail редких запросов («у меня аллергия на лактозу и фруктозу, что у вас можно?») съест больше токенов и времени экспертов на «дообучение» правил, чем принесёт денег. Эти 5–10% случаев должны уходить в handoff_human — это не провал, это правильное архитектурное решение. Прямой урок из № 91: автоматизируйте частое и шаблонное, остальное оставляйте людям.

8.8. Дисклеймер

Все числа в этом разделе — модельные ориентиры, а не факт и не «средняя отдача по рынку». Они нужны, чтобы понять, на каких допущениях стоит ваш бизнес-кейс, и где модель ломается. Реальную окупаемость по своему заведению вы посчитаете только на цифрах своего пилота: фактическая конверсия апселла, фактическая стоимость интеграции с вашим POS, фактический счёт от LLM-провайдера и SIP-оператора. Любая попытка взять цифры из этой таблицы и подставить в защиту бюджета без поправки на свою реальность — это та же ошибка, от которой предостерегает базовая статья про оценку ROI: покупка обещанной автономности вместо измеримого эффекта.

Соберите honest pilot на 4–6 недель в одной точке или одном канале, снимите baseline до старта, считайте полную стоимость владения с учётом времени людей — и только потом принимайте решение о расширении.

9. Ошибки

• Вся логика в промпте. Цены и наличие в системном промпте → галлюцинации и продажа из стоп-листа. Держите это в функциях/POS.
• Агрессивный апселл. Несколько допов и повтор после отказа раздражают гостя и бьют по лояльности. Правило — один уместный доп.
• Нет handoff на человека. Без escape-hatch агент «выкручивается» в трудных случаях. Передача оператору обязательна.
• Оптимизация под прокси-метрику. Гонитесь за KPI вместо реального исхода — получите эффект «ботов контакт-центров».
• Запуск сразу на весь поток. Без пилота и shadow-режима ошибки бьют по выручке и репутации сразу.
• Игнор ПДн. Запись голоса и контакты без правовой базы и информирования — нарушение 152-ФЗ.

10. Источники

• Yandex Cloud — нейробариста «Дринкит» на Yandex AI Studio: https://yandex.cloud/ru/blog/yandex-ai-studio-drinkit
• LiveKit Docs — Building Voice Agents: https://docs.livekit.io/agents/build
• LiveKit Docs — Telephony Integration (SIP): https://docs.livekit.io/agents/start/telephony
• LiveKit Docs — Tool Definition & Use: https://docs.livekit.io/agents/build/tools
• AI Happens — критика чат-ботов, оптимизирующих метрики: https://t.me/AIhappens/392