Нейросети для HoReCa: автоматизация, продажи, отзывы, команда

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

Дальше – четыре сценария. Для каждого: типовая структура данных, что обычно хотят посчитать, где люди ломаются, и какие промпты реально работают.

Сценарий A. Продажи: воронка, конверсия, выручка, план-факт

Типовые данные

Дата лида / сделки

Статус (новый, в работе, выигран, проигран, отменён)

Сумма

Менеджер

Источник/канал

Клиент/компания

Дата закрытия

Что обычно нужно

Воронка: сколько сделок на каждом этапе

Конверсия: доля переходов между этапами

Выручка: сумма выигранных за период

Скорость: среднее время от создания до закрытия

План-факт: сравнение с планом по менеджерам/месяцам

Качество пайплайна: сколько «зависших» сделок

Типовые ловушки

Статусы написаны разными словами («Won», «выиграно», «закрыто успешно»)

Дата закрытия пустая или криво заполнена

Суммы текстом («1 200 000», «$3000»)

Дубли по сделкам

Сделки «отменены», но всё ещё в данных как активные

Промпт-шаблон (воронка)

Данные: колонки: DateCreated, Stage, Amount, Owner, Source, CloseDate. Нужно: сводку-воронку по Stage за период [даты], отдельно по Owner. Исключить: Stage = [Cancelled/Refund/Spam]. Сделай:

структуру отчёта (какие сводные/таблицы)

формулы или шаги (Excel/Sheets)

проверки корректности (дубли, пустые даты, суммы текстом)

Промпт-шаблон (конверсия)

Хочу конверсию между этапами воронки: New → Qualified → Proposal → Won. Данные: каждая строка – сделка, колонка Stage содержит текущий этап. Как корректно посчитать конверсию по месяцам создания сделки? Предложи 2 подхода:

«по текущему этапу» (быстро)

«по истории этапов» (если нужна честная конверсия) Укажи ограничения каждого.

(важно: ИИ тут должен заставить вас осознать, есть ли у вас история изменений этапов. Без неё «конверсия» часто – иллюзия.)

Сценарий B. Финансы: P&L, cashflow, расходы по статьям, маржа

Типовые данные

Дата операции

Категория/статья

Контрагент

Сумма

Валюта

Тип (доход/расход)

Проект/центр затрат

Что обычно нужно

P&L по месяцам: выручка, COGS, OPEX, прибыль

Cashflow: притоки/оттоки, остаток

Расходы по статьям: топ категорий и динамика

Маржинальность: валовая и операционная

План-факт бюджета

Типовые ловушки

Одна и та же категория названа по-разному

Знак суммы: расход как отрицательное или отдельный столбец «тип»

Валюты смешаны, курсы не учтены

Даты «в тексте»

НДС/налоги учтены непоследовательно

Промпт-шаблон (нормализация категорий)

У меня категории расходов написаны хаотично. Примеры: «Marketing», «Маркетинг», «Ads», «Реклама FB», «SMM», «Performance». Я хочу привести их к 8—12 стандартным статьям (Marketing, Payroll, Rent…). Предложи правило группировки + таблицу соответствий. Затем предложи формулу/подход, как автоматически присваивать стандартную категорию по исходной.

(здесь ИИ полезен как «семантический группировщик», а таблица – как механизм применения правила.)

Промпт-шаблон (P&L)

Данные транзакций: Date, Type (income/expense), Category, Amount. Нужно P&L по месяцам:

Revenue (Type=income)

OPEX (Type=expense, исключая COGS)

COGS (Category in …)

Gross Profit, Operating Profit Сделай структуру табличного отчёта + формулы для Excel/Sheets. Добавь проверки: сумма доходов/расходов должна сходиться с общей.

Сценарий C. Маркетинг: CAC, ROAS, LTV, каналы, когортный анализ

Типовые данные

Расходы по каналам/кампаниям/датам

Лиды/регистрации/покупки

Доход по клиентам

Источник привлечения (UTM, канал, кампания)

Даты первого касания / первой покупки

Что обычно нужно

ROAS: доход / расходы по каналу

CAC: стоимость привлечения клиента

Конверсия: клик → лид → покупка

Когорты: удержание/повторные покупки по месяцам первой покупки

LTV: доход от клиента за период (30/90/180 дней)

Типовые ловушки

Источник не совпадает между системами (UTM потерян, канал “ (direct)»)

Дедупликация клиентов (email/телефон в разных форматах)

Смешение «лидов» и «клиентов»

Запаздывание дохода относительно расхода (атрибуция)

Промпт-шаблон (ROAS)

Есть две таблицы:

AdsSpend: Date, Channel, Campaign, Spend

Orders: OrderDate, Revenue, Channel, CustomerID Нужно: ROAS по Channel и по месяцам. Опиши, как объединить данные, какие ключи использовать, и как посчитать. Если есть риск некорректной атрибуции – перечисли и предложи упрощения.

Промпт-шаблон (кохорты)

Таблица заказов: CustomerID, OrderDate, Revenue. Нужно: когортный анализ по месяцу первой покупки:

размер когорты

выручка по месяцам жизни (M0, M1, M2…)

retention (доля вернувшихся) Предложи структуру в Excel/Sheets: какие вспомогательные колонки, как построить сводную, какие формулы. Добавь 3 проверки корректности.

(кохорты – отличный пример задачи, где ИИ ускоряет проектирование, но вы всё равно должны понимать определение.)

Сценарий D. HR: найм, текучесть, зарплаты, эффективность, кадровая аналитика

Типовые данные

Сотрудник, отдел, роль

Дата найма, дата увольнения

Зарплата, грейд, тип занятости

Вакансии, кандидаты, этапы найма

Оценки, performance, отпуска/больничные

Что обычно нужно

Headcount: численность по месяцам

Текучесть: увольнения / средняя численность

Time-to-hire: скорость найма по вакансиям/рекрутерам

Воронка найма: отклики → интервью → оффер → выход

Фонд оплаты труда: динамика и прогноз

Типовые ловушки

Увольнение без даты (или дата есть, но сотрудник «активен»)

Сотрудники с несколькими контрактами (дубли)

Разные «типы» увольнений (сокращение, по желанию)

Воронка найма без единого ID кандидата

Промпт-шаблон (headcount по месяцам)

Таблица сотрудников: EmployeeID, HireDate, TerminationDate (может быть пустой), Department. Нужно: headcount по месяцам и по Department – сколько было активных в каждом месяце. Предложи способ в Excel/Sheets:

какие вспомогательные столбцы

формулу или сводную

как обработать TerminationDate пустой и увольнение в середине месяца

Промпт-шаблон (turnover)

На основе тех же данных посчитай текучесть по месяцам: увольнения за месяц / средняя численность за месяц. Опиши, как корректно считать «среднюю численность» и какие варианты допустимы.

Универсальный приём для всех сценариев: «контрольные суммы» и тест-кейсы

Любой отчёт в таблицах должен иметь 2—3 «контрольных крючка», чтобы ловить ошибки:

сумма по деталям = сумма в итогах

число строк после фильтра = ожидаемое число (проверка исключений)

несколько ручных подсчётов на 5 строках

проверка крайних случаев (пустые даты, нули, отмены)

Промпт, который делает это привычкой:

Для этого отчёта предложи 5 проверок качества данных и 5 тест-кейсов, которые выявляют ошибки в формулах/логике.

ИИ редко сам добавит проверки, если не попросить. Но если попросить – он становится вашим QA-инженером.

Главная мысль главы

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

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