Почему 18% заказов срывались и как кейтеринг вырос на 280 тыс ₽/мес
Пятница, 17:43. Завтра у клиента корпоратив на 80 человек, а он только что написал в WhatsApp: «Извините, отменяем». Восемнадцать процентов заказов — именно так и умирают. Не потому что клиент передумал, а потому что никто не напомнил, не уточнил детали, не зафиксировал вовремя.
Виктор, владелец кейтеринга в Петербурге, терял на этом 320 тысяч рублей каждый месяц. Его менеджер по бронированию четыре с половиной часа в день переписывал одни и те же данные из WhatsApp в таблицу, из таблицы в 1С. Повара узнавали о заказах с опозданием на полчаса. Доставки срывались. Клиенты уходили.
Проблема была не в людях — люди старались. Проблема была в том, как устроен процесс. И когда Виктор это понял, всё изменилось.
Контекст клиента
Виктор - директор кейтеринг-компании в Санкт-Петербурге. 28 сотрудников, оборот 8,5 млн ₽ в месяц, корпоративные мероприятия, свадьбы, бизнес-ланчи на выезде. Компания работала три года и выросла до нормального среднего размера - но процессы так и остались такими, как были в самом начале, когда заказов было в пять раз меньше.
Когда мы познакомились с Виктором, у него в ходу было три инструмента: Yclients для бронирований, WhatsApp для переписки с клиентами и поварами, 1С для учёта и бухгалтерии. Все три - нормальные, рабочие инструменты. Беда была в другом: они не разговаривали друг с другом. Между ними стоял живой человек - менеджер по бронированию - и весь день вручную перекладывал данные из одного места в другое.
---Что болело - в цифрах
Схема выглядела так: клиент оставлял заявку через Yclients, менеджер её видел, открывал WhatsApp, писал клиенту для подтверждения, ждал ответа, потом вручную заносил всё в гугл-таблицу (общий список для кухни), потом дублировал в 1С. На один заказ уходило в среднем 12 минут. Умножьте на поток входящих - и получите 4,5 часа в день на чистую перекладку данных.
Повара получали информацию о заказе с опозданием в 30-40 минут от момента подтверждения. Иногда позже. Это напрямую ударяло по логистике: закупки, подготовка, выезд - всё ехало следом.
Но главная потеря была в другом. 18% заказов отменялись за сутки до мероприятия. Клиенты просто не получали своевременного подтверждения - ждали, забывали, находили другого подрядчика. Менеджер физически не успевал прозванивать всех: он был занят вводом данных.
В деньгах это выглядело примерно так: при среднем чеке 3 200 ₽ компания теряла около 320 тыс ₽ в месяц на отменённых бронированиях. Плюс - менеджер, который мог бы вести 60-70 активных клиентов и искать новых, тянул только 45, потому что остальное время съедала рутина.
«По словам Виктора, главное было не автоматизация ради автоматизации - он хотел, чтобы менеджер наконец занялся клиентами, а не таблицами».
Вот здесь и начинается разговор про автоматизацию обработки заказов кейтеринга. Если коротко: новый заказ из любого канала сам попадает куда нужно - к повару, в учётную систему, клиенту уходит подтверждение - без участия человека. Звучит просто, но у большинства компаний этого нет, потому что системы не связаны между собой.
Способов связать их несколько. Можно нанять программиста и написать интеграцию с нуля - дорого и долго. Можно взять платформу-посредника, которая соединяет сервисы по готовым шаблонам. Можно настроить вебхуки напрямую - это в итоге и выбрали мы. Главный критерий: не трогать существующий стек клиента, не переучивать команду, не ломать то, что уже работает.
---Что мы предложили - наш стек
Мы не стали предлагать Виктору новые инструменты. Рабочий стек у него уже был - нужно было просто заставить его работать как единое целое. Вот из чего он состоял и почему мы оставили именно это.
Yclients
Что это: российская платформа для управления записями и бронированиями. Умеет хранить клиентскую базу, управлять расписанием, принимать онлайн-заявки, напоминать клиентам о визитах. Фактически стандарт для сервисного бизнеса в России - от салонов красоты до кейтеринга.
Кому подходит: компаниям с потоком бронирований от 20-30 в месяц, где нужна централизованная база клиентов.
Цена: от ~1 500 ₽/мес за базовый тариф, для команды 28 человек - порядка 5 000-8 000 ₽/мес (актуальные тарифы уточняйте на сайте).
Минусы: интерфейс местами перегружен; встроенной интеграции с 1С нет - нужна настройка через API.
WhatsApp Business
Что это: бизнес-версия мессенджера с возможностью отправлять автоматические шаблонные сообщения, подключать нескольких менеджеров к одному номеру, настраивать быстрые ответы.
Кому подходит: любому бизнесу, где клиенты уже общаются через WhatsApp - в кейтеринге это почти всегда так.
Цена: сама платформа бесплатна; платить придётся за исходящие шаблонные сообщения (ценообразование Meta - зависит от страны и объёма, лучше уточнять актуально).
Минусы: шаблоны сообщений нужно заранее регистрировать и согласовывать с Meta - это занимает время; у нового аккаунта есть лимит на количество уникальных получателей в сутки.
1С
Что это: объяснять не нужно - стандарт российского бухгалтерского и складского учёта. У Виктора стояла уже несколько лет, вся история по продуктам, поставщикам и финансам жила там.
Кому подходит: всем, у кого есть бухгалтер и склад.
Минусы: не заточена под оперативную работу с заказами в реальном времени; интеграция требует либо своего IT-специалиста, либо настройки HTTP-сервиса - это точно не «кнопка на сайте».
Мы оставили именно эти три инструмента, потому что они уже были в компании, команда умела в них работать, а замена любого потребовала бы переобучения 28 человек. Наша задача - автоматизация обработки заказов кейтеринга без разрушения того, что уже работает.
---Как мы это внедряли - шаги по неделям
День 1-3: аудит и картирование потоков
Для начала мы прошли весь путь заказа вручную вместе с менеджером. Зафиксировали: откуда приходят заявки, куда попадают, кто что делает руками и сколько на это уходит. Нашли три узких места: момент подтверждения заказа клиентом, передача данных на кухню и занесение в 1С.
Параллельно - технический аудит: проверили версию 1С, доступ к настройкам Yclients, статус WhatsApp - Business API или обычное приложение. Выяснилось, что WhatsApp был обычным. Пришлось переключать на Business API - это съело ещё один день.
День 4-7: настройка триггеров в Yclients
Настроили вебхуки на три события: создание нового заказа, изменение статуса и отмена. Каждое событие теперь автоматически отправляет данные дальше по цепочке. Определили, какие поля нужны поварам - тип блюд, количество порций, время доставки, адрес - и настроили, чтобы именно эти данные уходили в WhatsApp-сообщение на кухню.
На этом же этапе подключили IT-специалиста Виктора: нам нужен был доступ к серверу с 1С, чтобы опубликовать HTTP-сервис для приёма данных.
День 8-12: интеграция с 1С
Самый трудоёмкий блок. На стороне 1С настроили обработчик, который принимает данные о новом заказе и автоматически создаёт документ «Заказ клиента» с нужными полями: контрагент, состав, сумма, дата. Прогнали тесты на 30 тестовых заказах - проверяли корректность маппинга и крайние случаи: заказ без адреса, заказ с изменением состава после подтверждения.
Поймали баг: при редактировании заказа в Yclients данные в 1С не обновлялись, а создавался дубль. Потратили день на исправление - добавили проверку по уникальному ID заказа перед созданием документа.
День 13-16: автоматические уведомления клиентам
Настроили шаблоны в WhatsApp Business: подтверждение сразу после бронирования, напоминание за 24 часа до мероприятия, запрос с кнопками «Да, всё в силе» / «Нужно перенести». Последнее - ключевой момент для снижения no-show: клиент получает сообщение и одним нажатием подтверждает или просит перенос, вместо того чтобы просто не прийти.
Шаблоны регистрировали в Business Manager заранее - согласование с Meta заняло 2 дня.
День 17-18: обучение и запуск
Провели двухчасовую сессию с менеджером и шеф-поваром: показали, как выглядит новый поток с их стороны, что делать если что-то пошло не так и как вручную скорректировать заказ при необходимости. Запустили в боевом режиме - первые 48 часов держали под своим мониторингом.
---Что получили в цифрах
| Показатель | До | После |
|---|---|---|
| No-show (отмены за сутки) | 18% | 6% |
| Время обработки одного заказа | 12 минут | 2,5 минуты |
| Активных клиентов на менеджера/мес | 45 | 78 |
| Средний чек | 3 200 ₽ | 3 450 ₽ |
| Рутина менеджера в день | 4,5 часа | 45 минут |
| Скорость получения заказа поварами | 30-40 минут | 2,5 минуты |
| Рост выручки | - | +280 тыс ₽/мес |
Рост среднего чека - не прямое следствие автоматизации. Менеджер, освободив 3,5 часа в день, начал плотнее работать с существующей базой: предлагал допуслуги при подтверждении, перезванивал «тёплым» клиентам. Это и дало плюс 250 ₽ к среднему чеку.
Рост выручки на 280 тыс ₽ складывается из двух частей: около 180 тыс ₽ - деньги, которые перестали уходить через отменённые заказы, и около 100 тыс ₽ - дополнительный оборот за счёт того, что менеджер стал вести больше клиентов.
---Что мы бы сделали иначе
1. Раньше переключили бы WhatsApp на Business API. Переход с обычного приложения на API-версию съел лишний день - этого можно было избежать, уточни мы статус аккаунта ещё на этапе первичного брифинга. Теперь это первый вопрос в нашем чеклисте.
2. Протестировали бы сценарий изменения заказа отдельно. Баг с дублями в 1С при редактировании мы поймали на тестовых данных - хорошо, что не на боевых. Но он стоил дополнительного дня. Сейчас для этого сценария у нас есть отдельный тест-кейс, который запускается автоматически перед любым запуском.
3. Добавили бы напоминание поварам, а не только клиентам. Изначально автоматические уведомления настраивали только на клиентскую сторону. Уже после запуска Виктор попросил добавить утреннюю сводку для шеф-повара - список заказов на день с адресами и составом. Это заняло ещё три часа, но лучше было заложить сразу.
---Можем повторить у вас
Этот кейс - про автоматизацию обработки заказов кейтеринга, но та же схема работает для любого сервисного бизнеса, где есть поток бронирований, мессен
Что делать прямо сейчас
1. Посчитайте свой процент отменённых заказов за последние 30 дней. Не на глаз — выгрузите из CRM или таблицы. Если цифра выше 10%, у вас уже есть конкретная точка роста.
2. Запишите, на каком шаге чаще всего срывается сделка. Клиент не подтвердил? Менеджер не перезвонил вовремя? Заказ потерялся между мессенджером и таблицей? Один час честного разбора даст больше, чем неделя догадок.
3. Проверьте, что происходит с клиентом после первого касания. Напишите сами себе как клиент — посмотрите, что придёт в ответ и через сколько времени. Часто именно здесь и живёт потеря денег.
4. Набросайте, какие действия у вас повторяются каждый день. Напоминания, подтверждения, сводки — всё, что делается руками по одному и тому же сценарию. Это и есть список кандидатов на автоматизацию.
Когда зовут нас
FlowFrame занимается именно такими задачами: связываем мессенджеры, CRM и внутренние процессы так, чтобы заказы не терялись, а менеджеры занимались людьми, а не рутиной.
Если хотите разобрать свою ситуацию — на сайте есть AI-бот, он задаст пару вопросов и поможет понять, есть ли смысл копать глубже. Без давления, просто разговор.