CRM для доставки еды и общепита: заказы и постоянные клиенты

CRM для доставки еды - это система для работы с обращениями и историей клиентов: вопросами, жалобами, повторными заказами и согласованной коммуникацией. Сам заказ - состав, цену, кухню, зону доставки, курьера и кассу - обычно ведёт ресторанная система, и CRM не обязана её заменять.

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

В выдаче по запросу «CRM для доставки» встречаются два разных продукта. Первый - система исполнения: приём заказа, кухня, зоны, курьеры. Второй - клиентский слой поверх неё: обращения, задачи, сегменты, коммуникация. Сравнивать их одним списком функций бессмысленно. Дальше разбираем второй слой и то, как он стыкуется с первым.

Нужна ли доставке отдельная CRM, если уже есть iiko или другая ресторанная система

Ресторанные системы давно вышли за пределы кассы и склада. iiko, например, заявляет профильные функции доставки и лояльности наряду с ресторанным учётом. Её сайт доставки учитывает зоны и график работы точек, направляет заказ в нужную точку сети, связывает меню со стоп-листом и поддерживает разные способы оплаты. Там же заявлены электронные карты гостей, бонусная система и акции по сегментам. Сайт доставки подключается отдельной подпиской, а набор возможностей разделён по тарифам, поэтому перед любым решением проверьте, что входит именно в ваш.

Если встроенная лояльность уже закрывает задачу, вторая система добавит только обмен данными, который придётся поддерживать. Бывает и обратный сценарий: CRM покупают «для повторных заказов», а затем выясняется, что бонусы и акции уже работают в ресторанной системе, и CRM дублирует их с запаздыванием.

Встроенного контура обычно достаточно, если:

• заказы приходят в основном через собственный сайт, приложение и телефон, подключённые к ресторанной системе;
• повторные покупки стимулируются бонусами и акциями, которые уже настроены;
• жалоб немного, и их разбирает один управляющий, который видит заказ в той же системе.

Отдельный клиентский слой стоит рассматривать, если:

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

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

Что остаётся в системе заказов, а что передаётся в CRM

Прежде чем настраивать обмен, договоритесь, какая система чем владеет. Ресторанная система владеет заказом: составом, ценой, исполнением и кассой. CRM владеет обращением, задачей и клиентской коммуникацией в согласованном объёме. Если обе системы считают себя хозяином одного и того же, данные начинают расходиться уже на первой неделе.

Отдельно о каналах. Фраза «CRM собирает заказы из всех каналов» обещает больше, чем можно знать до проверки подключений. Откуда заказ попадёт в учёт, зависит от подключений и от прав, которые даёт площадка. Заказы с агрегатора могут приходить в ресторанную систему, но данные его покупателей не стоит считать свободно доступными для импорта в свою базу и рассылок. Что именно передаёт агрегатор и на каких условиях, проверяется по договору с ним.

Переписка из мессенджеров - другой случай: её обычно и нужно вести в CRM, потому что туда пишут с вопросами и жалобами. Как свести переписку в одно окно, описано в статье о мессенджерах в CRM.

Из этой схемы следует частый вопрос: делать ли из каждого заказа сделку. Для потоковой доставки - обычно нет. Десятки заказов в день превращают воронку в журнал, который никто не читает, а менеджеру нечего делать с заказом, который уже доставлен. Удобнее хранить заказ как покупку в истории клиента, а сделку открывать тогда, когда есть работа: жалоба, корпоративный запрос, договорённость. В amoCRM для такой модели есть режим «Покупатели» с данными о покупках в карточке и сегментацией, доступный не на всех тарифах. В Битрикс24 ту же логику проектируют своими средствами; выбор платформы зависит от того, какие ещё процессы компания собирается вести в CRM.

Клиент, заказ, история и согласия: какие данные передавать

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

Телефон кажется удобным ключом клиента, но общий номер не означает одного человека. Один телефон бывает у семьи, у офиса, где обед заказывает секретарь, у сотрудника, который заказывает для коллег. Если склеивать всё по номеру, история смешивается, а дубли расползаются. Правила распознавания дублей лучше определить заранее; общая логика описана в статье о дублях в amoCRM.

Отдельная тема - сведения, которые клиент сообщает о себе: аллергии, ограничения по здоровью, особенности питания. Хранить их автоматически в общей CRM, видимой всем операторам, не стоит. Такие данные могут требовать особого правового анализа и ограниченного доступа. Основания для обработки персональных данных и рекламных сообщений должен проверить ответственный специалист до запуска, а не после первой жалобы.

Отмены, повторы и потеря событий

Обмен ломается не на типичном заказе, а на исключениях. Заказ отменили через пять минут после оформления. Курьер вернул часть позиций. Событие пришло дважды. Связь пропала на час в пятничный вечер. На каждый случай нужно правило.

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

Повторные заказы: сегменты по завершённым заказам

Общая методика сегментации базы по давности, частоте и сумме покупок описана в статье об RFM-сегментации. Для доставки к ней добавляются три правила. Считается только завершённый заказ. Отмены и возвраты учитываются в итоге. Писать можно только тем, с кем коммуникация разрешена и не заблокирована открытой претензией.

Интервалы «давно не заказывал» у каждой доставки свои. Пиццерия у бизнес-центра и сервис праздничных тортов живут в разных ритмах. Поэтому границы в таблице ниже - условный пример: свои стоит посчитать по фактическому интервалу между заказами в вашей базе.

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

Вторая ошибка - сегмент, который не обновляется. Клиент вчера заказал снова, а сегодня получил письмо «мы скучаем». Перед запуском проверьте, через какое время завершённый заказ меняет сегмент и что происходит, если обмен в этот момент не работал.

Сервисное уведомление и рекламное предложение

Сообщение «заказ передан курьеру» и сообщение «скидка на роллы до воскресенья» - разные виды коммуникации. Первое связано с исполнением конкретного заказа. Второе - реклама, и для неё нужно предварительное согласие получателя. Факт покупки сам по себе такого согласия автоматически не даёт. Поэтому «разослать всем покупателям» - не стратегия возврата клиентов, а риск. Какие согласия у вас есть и как фиксируется отказ от сообщений, проверяет ответственный специалист.

Технически автоматические сообщения в CRM настраиваются без труда, сложнее решить, когда они уместны. Подробнее о границе между пользой и раздражением - в статье о триггерных рассылках в amoCRM. Работа с клиентами на паузе в целом описана в материале о работе с базой клиентов.

Повторную покупку удобно измерять как долю клиентов, у которых за выбранный период появился второй завершённый заказ. Считать стоит до и после изменений, с учётом сезона, меню и акций конкурентов. Без исходного замера любое улучшение остаётся ощущением.

Жалоба: обращение с ответственным и связью с заказом

Условный пример. Клиент пишет в мессенджер вечером: роллы приехали через полтора часа и тёплыми. Оператор смены отвечает «разберёмся», смена заканчивается, утром никто не помнит, что обещали. Через неделю клиент оставляет отзыв на площадке, а повторного заказа нет.

Проблема здесь не в отсутствии программы, а в том, что у жалобы нет владельца и проверяемого итога. CRM полезна тем, что превращает сообщение в обращение с ответственным, сроком и записью о решении.

Решение о компенсации остаётся за правилами ресторана, а не за автоматикой. CRM фиксирует, что обещали и выполнено ли обещание. Если в правилах есть стандартные варианты, их можно вынести в список, чтобы операторы не придумывали ответ каждый раз заново.

Отзывы на внешних площадках попадают в CRM только если такое подключение есть и разрешено площадкой. Если нет, достаточно договориться, кто их читает и как вручную создаёт обращение. Понятный ручной порядок полезнее подключения, которое никто не проверяет.

Причины жалоб полезно разбирать по итогам недели или месяца. Если половина претензий связана с упаковкой, это задача для кухни, а не для CRM. Система здесь только показывает, где повторяется проблема.

Пилот: как проверить связку до запуска на всю сеть

Начните с одной точки и одного-двух каналов обращений. Цель пилота - не показать красивую воронку, а проверить исключения: отмену, повтор события, потерю связи, жалобу и запрет коммуникации. Если они проходят правильно, обычный заказ пройдёт тем более.

Каждый сценарий стоит проверить вместе с управляющим и оператором смены. Если они по-разному объясняют, где сейчас жалоба и кто за неё отвечает, правило нужно исправить до того, как подключать остальные точки. Автоматизация, запущенная поверх неясного порядка, просто быстрее создаёт записи, которыми никто не пользуется.

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

Следующий шаг: найти один разрыв, который не закрывает ресторанная система

Перед разговором о внедрении ответьте на четыре вопроса. Какая ресторанная система стоит у вас и что входит в ваш тариф. Из каких каналов приходят заказы и обращения и какие данные вы вправе получать от агрегатора. Кто сейчас ведёт претензии и где хранится обещанное клиенту. Какую задачу встроенная лояльность не решает.

Если ответ на последний вопрос пустой, отдельная CRM, возможно, не нужна. Если разрыв есть, разобрать его можно на диагностике: смотрим каналы, путь жалобы и данные, которыми реально располагает компания. Проектирование клиентского контура входит во внедрение amoCRM или внедрение Битрикс24 - платформу выбираем под задачу, а обмен с ресторанной системой оцениваем отдельно в рамках интеграций.

Частые вопросы

Вывод

CRM для доставки еды полезна как клиентский слой рядом с ресторанной системой: она даёт жалобе ответственного, связывает обращение с заказом и строит сегменты по завершённым покупкам с учётом запретов. Начинать стоит с проверки того, что уже умеет ресторанная система, и с одного разрыва, который она не закрывает. Затем пилот на исключениях и только после него рассылки.

Источники

• iiko: функции доставки, лояльности и ресторанного учёта
• iiko: сайт доставки - зоны, график, направление заказа в точку, стоп-лист
• iiko: состав тарифов
• amoCRM: тарифы и режим «Покупатели»
• amoCRM: справочник методов API
• amoCRM: сущности и права доступа в API