Это вторая статья из серии про то, что внедрение ИИ не всегда окупается. В первой мы разбирали, почему даже у крупных компаний автоматизация может не дать экономии, а иногда и влететь в копеечку. Сейчас - конкретный кейс: голосовой ИИ в драв-тру McDonald’s, который не просто ошибался, а стал мемом. На его примере покажем, как избежать таких же ошибок в своём бизнесе.
Как ИИ в драв-тру превратил заказ в абсурд
McDonald’s несколько лет тестировал голосовой ИИ для приёма заказов в драв-тру в США. Это был не тотальный запуск, а пилот: около 100 ресторанов из 40+ тысяч по миру, чёткий периметр и цель - ускорить приём заказов и разгрузить персонал.
На практике система стабильно путала реальные заказы. В новостях и TikTok всплывали истории, где:
- к обычному заказу добавлялись 260 наггетсов;
- вместо одного чая - девять;
- бекон добавлялся к мороженому;
- в заказ вставлялись соусы вместо десерта.
Для клиента это выглядело как абсурд: человек просит базовый набор, а бот упрямо докручивает то, что "услышал" из шума, обрывков фраз и разговоров на соседней полосе. В итоге - неправильный заказ, раздражённый клиент и вирусные видео.
Почему шум, акценты и бардак - это норма, а не исключение
Главный технический урок прост: то, что многие считают "редкими случаями", в реальном драв-тру - повседневная норма. Это максимально токсичная среда для распознавания речи:
- фоновый шум от мотора и выхлопа;
- ветер и музыка из салона;
- дети на заднем сиденье;
- параллельный заказ на соседней полосе;
- спешка и нечёткая речь.
В таких условиях даже людям иногда приходится переспрашивать по три раза. А от ИИ ожидали, что он будет стабильно понимать заказы и ещё успевать допродавать… Довольно наивно 😁
Проблема не в "качестве нейросети", а в постановке гипотезы. Если изначально считать чистый звук и аккуратную речь "дефолтным" сценарием, а весь бардак вокруг - случайностями, проект обречён. Для реального бизнеса базовый сценарий другой: сразу заложить, что значительная часть диалогов будет в тяжёлых условиях, а часть клиентов просто не станет повторять одно и то же десять раз ради разговора с ботом.
McDonald’s эту реальность получил в лоб: пользователи снимали диалоги с ИИ, выкладывали в TikTok, и каждый такой ролик делал эксперимент не только затратным, но и репутационно токсичным.
Как это выглядело бы в "минимальном боевом" сценарии
Если спустить эту историю на уровень малого и среднего бизнеса - условный n8n, Make, Node-RED или кастомный бэкенд, - минимальный рабочий сценарий вообще не выглядит как "ИИ общается с клиентом до победного конца". Вот как это можно организовать.
1. Чёткий контур эскалации
Бот пытается понять фразу ограниченное число раз (например, два-три), после чего обязан отдать разговор оператору, а не продолжать спрашивать одно и то же до истерики клиента. Каждый такой случай автоматически логируется в базу (Notion, Airtable, Postgres - неважно), но с максимально сырым контекстом:
- аудио;
- расшифровка;
- гипотеза модели;
- итоговое вмешательство человека.
Так можно реально разбирать фейлы, а не гадать по агрегированной статистике.
2. Fallback по SLA
Диалог не может длиться бесконечно: есть лимит, например 40-60 секунд на приём заказа ботом, после которого разговор автоматически уходит на человека. Это не даёт создавать очереди из-за глючащего сценария.
В n8n или любом другом инструменте это собирается в простую схему:
- входящий звонок/вызов из телефонии;
- модуль STT;
- таймер, счётчик попыток;
- ветка с эскалацией на оператора;
- логирование всех таких случаев в отдельный канал для последующего разбора.
3. Здравый выбор покрытия
Вместо того чтобы сразу пытаться поддерживать полный ассортимент и сложные комбинации запросов, минимальный боевой сценарий должен включать ограниченный набор позиций и фраз, где модель показывает стабильный результат. Всё, что выходит за рамки этой зоны уверенности, по умолчанию отдаётся на человека - не потому что "ИИ плохой", а потому что цена ошибки здесь выше потенциальной выгоды экономии пары минут операторского времени.
Мини-схема: как это собрать на n8n / low-code
Чтобы это не выглядело как общая болтовня, можно разложить примерную схему для SMB в понятные блоки. Ниже - авторский паттерн, а не описание того, как именно делал McDonald’s.
- Вход: интеграция с телефонией или виджетом -> HTTP Webhook в n8n/Make.
- Обработка: блок STT (внешний API), затем узел валидации по словарю меню (ID позиций, простые шаблоны "комбо N", "соус X").
- Контроль:счётчик непонятных реплик и таймер общего времени диалога, хранящиеся в переменных workflow.
- Эскалация:если превышен лимит попыток или времени, звонок/чат уходит оператору через отдельный узел (SIP, контакт-центр, internal API), а текущий state сохраняется.
- Логирование:отдельный поток пишет сырые данные (анонимизированные) в БД для последующего анализа ошибок, retrain-датасетов и т.п.
На уровне метрик "минимально приличный пилот" можно мерить:
- долю диалогов, ушедших в эскалацию;
- среднее время до эскалации;
- процент заказов, которые оператору пришлось править после ИИ.
Цель - не ноль эскалаций, а предсказуемое поведение системы и отсутствие "бекона на мороженом" в бою.
В чём McDonald’s всё-таки молодцы
Легко угорать над роликами с беконом на мороженом, но если смотреть на проект как на эксперимент, McDonald’s сделали несколько вещей очень правильно.
1. Пилот в ограниченной зоне
Компания сознательно держала пилот в рамках чуть больше сотни ресторанов на фоне 40+ тысяч точек по миру и десятков тысяч драв-тру. Они не понеслись ставить технологию во все драв-тру, пока нет ясности по точности, устойчивости и экономике - и это сильное управленческое решение.
2. Взрослый выход из пилота
Когда стало понятно, что текущая связка точности, реальной среды и формата внедрения не устраивает бизнес, пилот с IBM решили завершить в середине 2024 года. Официально McDonald’s формулирует это мягко - как завершение теста и пересмотр подхода, но по факту это взрослый выход: ограниченная зона, понятный период тестирования, честный вывод "в текущей конфигурации не летает" и отключение технологии, а не попытка бесконечно "дожать".
3. Сигнал рынку
После громкого теста и его остановки McDonald’s не сказали, что "ИИ - фигня и мы туда больше не пойдём". Компания параллельно готовит масштабный ИИ-перезапуск на 43 000 ресторанов по миру с партнёром Google Cloud, включая ИИ-драв-тру, умную кухонную технику, предиктивное обслуживание и виртуального ИИ-менеджера. Это нормальная взрослая позиция: не вера в "волшебный ИИ", а работа с гипотезами и конфигурациями так же, как с любыми другими инвестициями в инфраструктуру.
Как это переложить на бизнес с 10-50 точками
Теперь самое полезное для малого и среднего бизнеса. Условный владелец сети из 10-50 точек (розница, доставка или сервис) живёт в режиме ограниченного бюджета, чувствительной репутации и заметных пиковых нагрузок, где пара вирусных историй может легко убить доверие.
Здесь подход в духе McDonald’s можно повторить, но в миниатюре:
- пилот в 1-2 точках;
- один чётко описанный сценарий, а не "мы везде ставим голосового бота".
С чего начать
Вместо того чтобы перестраивать весь фронт-коммуникаций под голосового ассистента, можно начать со сценария "приём типовых заказов без сложных кастомизаций в определённые часы" с понятным KPI по точности и времени до завершения.
На уровне архитектуры это один или несколько workflow:
- интеграция с телефонией или виджетом;
- модуль распознавания;
- блок бизнес-логики;
- эскалация на оператора;
- логирование во внешнюю систему.
Это спокойно собирается на no-code/low-code, но с инженерной дисциплиной: мониторинг, алерты, владелец сценария, регламент на изменения. Кстати, если нужны детали по таким внедрениям - пиши или заглядывай в канал , там реальные кейсы без воды.
Два критичных принципа
1. Kill-switch. Если через две-три недели в реальном трафике сценарий не показывает приемлемую точность и экономику, его нужно либо радикально упрощать, либо выключать, а не пытаться "подшаманить ещё чуть-чуть" бесконечными правками.
2. Правило короткого пилота. McDonald’s заплатили за этот урок своими мемами и TikTok-скандалами, но при этом сохранили стратегию на масштабный ИИ-апгрейд сети; остальным вполне можно воспользоваться их опытом, не дожидаясь собственных "260 наггетсов" в ленте.
Чек-лист пилота, чтобы не повторить чужие фейлы
- Ограниченный периметр: 1-2 точки и один сценарий, а не весь бизнес сразу.
- Явный kill-switch: понятные критерии "выключаем пилот" по точности, времени и жалобам.
- Эскалация по дефолту:N неудачных попыток распознавания или лимит по времени - и разговор уходит человеку.
- Ограниченный словарь: ИИ работает только с теми позициями и фразами, где его точность подтверждена, сложные запросы сразу отдаются оператору.
- Логирование сырья: сохраняем аудио, текст и гипотезы модели для реального разбора, а не смотрим только на усреднённый "accuracy 90%".
- Короткий цикл проверки: через 2-3 недели честно отвечаем, что делать дальше - скейл, переработка сценария или выключение.