Портфолио-кейс: продукт с ИИ · Максим Поципух · Сентябрь 2025
ИИ-ассистент для федеральной сети быстрого питания: как спроектировать продукт не имея данных заказчика
Видение продукта для тендера: ИИ-ассистент в мобильном приложении сети, который разбирает обращения гостей вместо контакт-центра. Автор — Максим Поципух. Объёмы обращений и цена проекта изменены по соображениям конфиденциальности; логика расчёта сохранена. Модель и данные — в репозитории проекта.
Предпосылки
Заказчик — федеральная сеть быстрого питания: сотни ресторанов в десятках регионов и мобильное приложение с миллионами установок. Гости пишут и звонят в контакт-центр по одним и тем же поводам: где заказ, почему в нём чего-то не хватает, куда делись баллы. Сеть объявила тендер на ИИ-ассистента в приложении, который возьмёт эти вопросы на себя.
В техническом задании были требования к инфраструктуре и безопасности, но не было главного для продукта: сценариев, статистики обращений и данных об активной аудитории. Заказчик пообещал передать базу знаний и схемы после переговоров, а видение продукта нужно было сдать вместе с предложением.
Когда данных нет, продукт проектируется от того, что умеет модель. Так в фастфуде появились голосовые боты в окне выдачи — и так же они закрывались. Я собрал картину обращений из открытых источников и проектировал от гостя. Главным решением в этом продукте оказалось не то, что ассистент делает, а то, чего он не делает.
Моя роль. Я подготовил видение продукта и всё предложение целиком: исследование заказчика и конкурентов, разбор обращений, функциональность и сценарии, оценку нагрузки, а также защиту предложения на тендере.
пишет вопрос на своём языке в разделе поддержки
определяет язык и тему, берёт заказы и баллы гостя из CRM
статус заказа, баллы, состав блюда, ближайший ресторан, возврат
сложные случаи — с историей диалога и переводом на русский
1. Где брать данные, если заказчик их не даёт
Без статистики контакт-центра продукт легко спроектировать «от технологии»: взять возможности языковой модели и придумать, что ещё она могла бы делать. Я пошёл от другого вопроса — с чем гости приходят в поддержку — и собрал ответ из трёх открытых источников. Каждый закрывает слабое место другого.
| Источник | Что даёт | Ограничение |
|---|---|---|
| Открытые жалобы, отзывы и FAQ сетей быстрого питания | Темы обращений и их примерная частота, типовые формулировки | Это оценка по отзывам, а не статистика контакт-центра |
| Отзывы гостей и сотрудников о самом заказчике | Местная специфика: неполные заказы, возвраты, акции, скорость поддержки | Отдельные отзывы, а не репрезентативная выборка |
| Решения конкурентов | Что уже сделано на рынке и где технология ломается | Компании почти не раскрывают эффект |
Ни одна крупная сеть быстрого питания не публикует разбивку обращений в контакт-центр по темам. Поэтому доли тем в этом кейсе — оценка, которую я сделал для предложения, а не данные заказчика. Её задача — не точность до процента, а порядок приоритетов: что делать в первой версии, а что потом.
2. С чем обращаются в контакт-центр
Оценка для предложения по открытым жалобам, отзывам и FAQ сетей быстрого питания; публичной статистики контакт-центров сети не раскрывают. Три верхние темы — 65–80% потока. Данные — data/topics.csv.
Картина получилась сильно неравномерной. Три темы — заказы, жалобы на еду и обслуживание, программа лояльности — дают от двух третей до четырёх пятых всего потока. Отзывы о самом заказчике подтвердили ту же тройку и добавили местную специфику: неполные заказы, деньги, которые списались, а возврат не пришёл, вопросы о кэшбэке по акциям банков-партнёров и медленная поддержка в приложении и соцсетях.
Но темы — это рубрикатор контакт-центра, а не то, чего хочет гость. «Где мой заказ» — не вопрос, а тревога: я заплатил, еды нет, курьер не звонит. Успех для гостя — не получить ответ в чате, а знать, что еда придёт, или вернуть деньги без спора. От такой формулировки и зависит, что должен уметь ассистент.
| Задача гостя | Что делает сейчас | Что для него успех | Что делает ассистент |
|---|---|---|---|
| Я заплатил, еды нет, курьер не звонит | Звонит в контакт-центр и ждёт на линии | Знать, когда приедет еда, или вернуть деньги | Статус и время из CRM; при сбое — возврат или передача оператору |
| В заказе не хватает позиции | Пишет в поддержку и доказывает, что её не было | Получить недостающее или деньги без спора | Показывает состав заказа и оформляет возврат или довоз |
| Еда холодная или испорчена | Оставляет жалобу и не знает, услышали ли её | Чтобы жалобу приняли и компенсировали | Фиксирует жалобу с привязкой к заказу и передаёт оператору |
| Не начислили баллы или кэшбэк | Ищет в приложении, потом пишет в поддержку | Увидеть баллы и понять, когда они придут | Показывает баллы и операции из CRM, правила акции — из справочника |
3. ИИ-решения у конкурентов по отрасли заказчика
Ассистентов для гостей в приложениях у крупных мировых сетей почти нет. Искусственный интеллект в фастфуде пока ушёл в две другие стороны: голосовой приём заказа в окне для автомобилистов и помощники для персонала. И там, и там видно, где технология ломается.
| Сеть | Что сделали | Когда и чем закончилось |
|---|---|---|
| McDonald's | ИИ-бот Olivia для найма персонала на платформе McHire. Ассистента для гостей в приложении нет | Июнь–июль 2025: исследователи нашли тестовый доступ с паролем «123456» к данным до 64 млн кандидатов ↗ |
| McDonald's и IBM | Голосовой приём заказа в окне для автомобилистов, около 100 ресторанов в США | Тест с 2021 года закрыт в июне 2024-го; точность — около 80% при цели 95% (оценка BTIG) ↗ |
| Burger King | Бот в Facebook Messenger: заказ из меню, ближайший ресторан, оплата | Запущен в 2016 году ↗ |
| Burger King, Новая Зеландия | ИИ-приём заказа в окне для автомобилистов, ассистент Patty | Тест с марта 2024 года в 4 ресторанах Окленда; к июлю 2026-го — 40 ресторанов ↗ |
| Burger King, США | Patty — голосовой помощник в гарнитурах сотрудников: рецептуры, стоп-лист, разбор диалогов | Объявлен в феврале 2026 года, пилот в 500 ресторанах ↗ |
| Taco Bell, KFC, Pizza Hut | Голосовой ИИ в окне для автомобилистов вместе с NVIDIA | 500 ресторанов во втором квартале 2025 года; в августе 2025-го Taco Bell признал проблемы — например, троллинг заказом 18 000 стаканов воды ↗ |
| KFC, Тайвань | Цифровой человек Kala на экранах в ресторанах: меню, вопросы, помощь с заказом | Апрель 2024 года, более 70 ресторанов ↗ |
| KFC и Baidu, Китай | «Умные рестораны»: голосовой робот-ассистент, распознавание лиц и подсказка заказа | Пилоты 2016 года ↗ |
Для нашего продукта отсюда два вывода. Первый: голосовой приём заказа — самая рискованная зона, там ошибка сразу превращается в лишнюю позицию в чеке. Второй: чат-бот — это ещё и риск безопасности. История с ботом для найма, где тестовая учётная запись с паролем «123456» открывала доступ к данным миллионов кандидатов, — прямой аргумент за требования заказчика к закрытому контуру и обезличиванию.
4. Чего ассистент не делает
Самое важное продуктовое решение — границы. Ассистент работает в авторизованной зоне приложения, читает из CRM историю заказов и баллы гостя и отвечает на вопросы. Но заказы он не оформляет и оплату не принимает: это уже делает само приложение, и дублировать его в чате — значит удвоить поверхность для ошибок там, где ошибка стоит денег. Опыт конкурентов с голосовым приёмом заказа показывает, чем это заканчивается.
- Статус и состав заказа, история последних заказов
- Баллы, списания и действующие акции
- Состав и калорийность блюд; аллергены — только из справочника
- Ближайший ресторан и часы работы
- Возврат или довоз при неполном заказе
- Рекомендации по истории заказов
- Жалобы на качество еды и обслуживание
- Чистота и гигиена в ресторане
- Спорные возвраты и компенсации
- Всё, что не распознал уверенно
- Не оформляет заказы и не принимает оплату
- Не сообщает о готовности заказа — это делает приложение
- Не показывает данные других пользователей
- Не отвечает на темы вне сервиса
Сложные случаи — жалобы на качество еды, гигиену, спорные возвраты — ассистент не решает сам, а передаёт в омниканальную платформу контакт-центра вместе с историей диалога. Гостю не нужно пересказывать всё заново, а оператор сразу видит заказ и суть претензии. Запросы вне темы, например просьбу показать данные другого пользователя, ассистент отклоняет.
5. Что войдёт в первую версию
Полное дерево по десяти темам — 64 сценария: десять базовых и 54 вариации, по которым обращения внутри темы расходятся, например «где мой заказ» и «в заказе не хватает картошки». В предложении срок разделён на две части: первая рабочая версия за 11 месяцев с подписания договора и полный запуск ещё за 6–12 месяцев. Значит, нужно решить, что войдёт в первую версию, — и решать это по доле потока, а не по объёму придуманного.
Полное дерево — 64 сценариев (10 базовых и 54 вариаций); после приоритизации — 45. Доля потока — по серединам оценок. Данные — data/topics.csv.
Релиз 1 — три верхние темы и надёжная передача оператору на всём остальном. Это две трети потока и проверка главной гипотезы при минимуме разработки: по допущениям модели ассистент закрывает без оператора около 36% всех обращений. Релиз 2 — меню, рестораны, доставка и оплата: ещё около четверти потока, и доля закрытых без оператора вырастает примерно до половины. Переход ко второму релизу — по метрикам из раздела 8, а не по календарю.
У редких тем — технические проблемы, чистота, корпоративные вопросы и прочее — ветвления нет. Все их варианты заканчиваются одинаково: ссылкой или передачей оператору, так что отдельные ветки диалога там ничего не дают. А доставка и оплата, наоборот, получают пять вариаций: статус, задержка, неудачная оплата, двойное списание, возврат за отмену. В итоге в работе 45 сценариев вместо 64, из них 20 — в первой версии.
Мультиязычность — моя инициатива: сеть работает во многих регионах, и для части гостей русский — не родной язык. В первой версии ассистент определяет язык и, если не поддерживает его, честно отвечает по-русски или переключает на оператора. Языки регионов — татарский, башкирский, чеченский, якутский и другие — входят во второй релиз по правилу: язык добавляется, если на нём приходит заметная доля обращений или регион входит в приоритетные для сети. Число сценариев от языков не растёт, но разметка и тестирование растут: каждую ветку проверяют на каждом языке. Поэтому ответы на каждом новом языке выборочно проверяют носители.
6. Обращения как сигнал о сбоях
Если треть потока — «где мой заказ», а заметная часть жалоб — неполные заказы и невернувшиеся деньги, это не вопросы, а следствие сбоев в приложении и в ресторанах. Ассистент на них — обезболивающее: он снижает нагрузку на контакт-центр, но не уменьшает число недовольных гостей.
Зато ассистент видит причину каждого обращения. Значит, он может работать датчиком сбоев: ежемесячный отчёт о том, какие сбои приложения и операций порождают обращения, какие рестораны чаще других собирают жалобы на неполный заказ, какие акции ломают начисление баллов. Для сети это вторая ценность продукта — не только дешевле отвечать на жалобы, но и знать, где их источник, чтобы жалоб становилось меньше.
7. Нагрузка и инфраструктура
Данных об активной аудитории заказчик не дал, поэтому в предложении нагрузка оценена сверху, по установкам приложения, — это предел, под который проектируется отказоустойчивость. Рядом с ним нужен базовый сценарий, посчитанный от причины обращения: в поддержку пишет не каждый гость, а гость с проблемным заказом.
| Шаг воронки | Значение | Откуда |
|---|---|---|
| Гостей в день | 2 000 000 | порядок масштаба федеральной сети |
| Заказов через приложение | 400 000 | 20% заказов — допущение |
| Проблемных заказов | 12 000 | 3% — допущение, ориентир 2–5% |
| Обратились в поддержку | 6 000 | 50% — допущение |
| Обращений в день | ≈ 10 000 | проблемы с заказом — 60% всех обращений, по темам |
| Сценарий | Обращений в день | Сообщений в день | Сообщений в минуту в пик |
|---|---|---|---|
| Базовый: пиковый час ×4, запас ×3 на промо | 10 000 | 50 000 | ≈ 625 |
| Предельный: оценка предложения по установкам | 525 000 | 2 625 000 | ≈ 10 500 |
В одном обращении 4–6 сообщений гостя, нагрузка распределена на 16 часов. Объёмы предложения уменьшены на 30% по соображениям конфиденциальности. Расчёт — scripts/model.py, data/load.csv.
Базовый сценарий на порядок-два ниже предельного: около 10 тысяч обращений в день против полумиллиона. Поэтому сайзинг считается в двух вариантах: базовый с запасом на промо-кампании и предельный. Для инфраструктуры важны не обращения, а сообщения: в одном обращении 4–6 реплик гостя.
Диалоговая платформа сама число обращений не ограничивает — бесперебойность определяет железо, на котором она стоит. Поэтому в расчёт заложено несколько серверов, в том числе для георезерва. Требования заказчика к размещению были жёсткими: собственный контур без выхода в интернет, резервирование в двух географических зонах с переключением меньше чем за минуту, защита персональных данных по 152-ФЗ. Ассистент хранит только идентификатор пользователя, а журналы диалогов — в обезличенном виде. Решение строится на готовой диалоговой платформе подрядчика, а не разрабатывается с нуля.
8. Метрики, экономика и проверка оценки
В предложении цель — снизить обращения в контакт-центр на 30–50%. Отраслевого источника для такой цифры нет: сети быстрого питания эффект своих ботов не раскрывают. Поэтому это гипотеза, и проверять её нужно не одной цифрой, а набором метрик с порогами, которые управляют решениями.
| Метрика | Как считается | Порог |
|---|---|---|
| Доля обращений, закрытых без оператора | Закрытые ассистентом ко всем обращениям | Релиз 1 — около 36% всего потока: по допущениям модели 70% по заказам и лояльности, 20% по жалобам |
| Передачи оператору по теме | Передачи к обращениям — отдельно по каждой теме | Больше 50% — сценарий дорабатывается; больше 70% после двух доработок — тема уходит сразу к оператору |
| Оценка гостя после диалога | Короткий опрос в конце диалога | Ниже, чем у операторов на тех же темах, — провал: релиз не расширяем |
| Повторные обращения по той же теме | Гость вернулся с тем же вопросом в течение недели | Не выше, чем после операторов |
| Точность темы и языка | Ручная разметка выборки диалогов | Не ниже 90% — ориентир предложения |
| Обращения в контакт-центр по темам ассистента | До и после запуска, по тем же темам | Снижение на 30–50% — гипотеза, которую проверяет пилот |
Главная метрика — доля обращений, которые ассистент закрыл без оператора. Если она растёт, а оценка гостей падает, значит, бот не решает проблему, а просто не пускает к человеку. Поэтому оценка гостя и повторные обращения по той же теме стоят рядом с ней, а не отдельно.
Чтобы цель «30–50%» не висела лозунгом, её стоит перевести в деньги. Диалог с оператором чата на аутсорсинге стоит около 66 рублей. Проект стоит около 8 млн рублей, так что за год он окупается, если ассистент закрывает без оператора около 330 обращений в день.
| Стоимость обращения у заказчика | Обращений в день без оператора | Доля базового потока |
|---|---|---|
| 40 ₽ | ≈ 548 | 5,5% |
| 66 ₽ | ≈ 332 | 3,3% |
| 100 ₽ | ≈ 219 | 2,2% |
| 150 ₽ | ≈ 146 | 1,5% |
Стоимость диалога — цена чат-консультанта сверх пакета у Kolocall. Цена проекта округлена; эксплуатация и сопровождение в порог не входят.
Это 3% базового потока — порог, который выдерживает даже ошибку в оценке нагрузки в несколько раз. Заказчик может подставить свою стоимость обращения и получить свой порог. Важная оговорка: экономия реальна, если стоимость контакт-центра переменная, как на аутсорсинге. Со своим штатом операторов она появляется, только когда штат сокращают или не расширяют.
Вся картина в этом кейсе построена на оценке по открытым источникам. Поэтому первое, что нужно сделать после доступа к данным заказчика, — проверить её, а не начинать разработку:
| Что делаем | Что получаем | |
|---|---|---|
| 1 | Выгрузить обращения контакт-центра за 3–6 месяцев | Реальный поток и пики вместо оценки по установкам |
| 2 | Вручную разметить выборку 300–500 обращений по тем же десяти темам | Фактические доли тем |
| 3 | Сверить доли с оценкой из раздела 2 и пересобрать релизы | Состав первой версии по данным, а не по отзывам |
| 4 | Оценить долю обращений, вызванных сбоями приложения и ресторанов | Размер второй ценности — отчёта о сбоях |
| 5 | Пересчитать базовую нагрузку и порог окупаемости на фактических цифрах | Сайзинг и экономика без допущений |
9. Риски
| Риск | Чем опасен | Что делаем |
|---|---|---|
| Неверный ответ об аллергенах | Вред здоровью гостя и ответственность сети | Только точная выдача из справочника, без генерации; при сомнении — оператор; оговорка о следах аллергенов |
| Ассистент как стена перед оператором | Гость не может дойти до человека | Кнопка «позвать оператора» в каждом диалоге; оценка гостя и повторные обращения как антиметрики |
| Статус заказа в CRM отстаёт | Уверенный неверный ответ по главной теме | Показывать время обновления статуса; если данные устарели — сказать об этом и передать оператору |
| Выдуманные цифры по баллам и акциям | Ошибка в деньгах гостя | Цифры только из CRM и справочника акций; спорные начисления — оператору |
| Пики: обед, вечер, промо-кампании | Деградация в момент наибольшего спроса | Сайзинг с запасом на промо; при перегрузке — очередь и передача оператору, а не отказ |
| Ответы на языке, который некому проверить | Ошибки, которых никто не заметит | Выборочная проверка ответов носителями на каждом новом языке |
Самый серьёзный риск — аллергены. Неверный ответ о составе блюда — это вред здоровью гостя и юридическая ответственность сети. Поэтому здесь ассистент не формулирует ответ сам: только точная выдача из справочника, при любом сомнении — отказ и переход к оператору, и всегда — оговорка о возможных следах аллергенов на производстве.
10. Результат
Итог тендера не раскрывается.
Другие кейсы автора
Источники
- McDonald's: ian.sh
- McDonald's и IBM: www.nrn.com
- Burger King: fortune.com
- Burger King, Новая Зеландия: thespinoff.co.nz
- Burger King, США: www.nrn.com
- Taco Bell, KFC, Pizza Hut: techcrunch.com
- KFC, Тайвань: www.prnewswire.com
- KFC и Baidu, Китай: www.nasdaq.com
- Стоимость чат-консультанта на аутсорсинге: Kolocall, прайс-лист
- Видение продукта и коммерческое предложение (не публикуются): требования заказчика, функциональность, сценарии, оценка нагрузки, сроки
Расчёты и данные для графиков — scripts/model.py и data/.