Рынок CRM для ресторанов устроен иначе, чем рынок CRM для отдела продаж. В классической B2B-схеме CRM сама является центром данных: менеджеры заводят сделки, система их хранит. В ресторане центр данных уже есть, это касса. Через неё проходят каждый чек, каждая скидка, каждый заказ на доставку. Любая система для работы с гостями либо встраивается в этот поток, либо остаётся надстройкой, в которую персонал забывает заходить.
Касса задаёт правила игры
Для ресторатора касса — критичная инфраструктура. Её не меняют ради маркетинга, на неё завязаны склад, кухня, смены и отчётность. Поэтому первый вопрос клиента к любому вендору CRM звучит одинаково: «Работаете ли вы с нашей кассой и нужно ли что-то менять?» Если ответ неуверенный, разговор о сегментации и триггерах обычно не начинается.
Поэтому интеграция с распространёнными ресторанными кассами, прежде всего iiko и r_keeper, для вендора CRM — входной билет, а не конкурентное преимущество само по себе. Различия начинаются в том, как именно эта интеграция сделана.
Три уровня интеграции
Условно можно выделить три уровня.
- Периодическая выгрузка. Данные о продажах забираются из кассы раз в какое-то время. Для аналитики этого хватает, для живой программы лояльности нет: гость оплатил, а бонусы появились позже.
- Обмен по API в реальном времени. Система получает события почти сразу, но логика начисления и списания всё равно живёт на стороне кассы или внешнего процессинга.
- Собственный модуль на рабочем месте кассира. Начисление и списание происходят в момент пробития чека, кассир не переключается между программами, баланс гостя обновляется сразу.
Чем глубже уровень, тем дороже его разработка и поддержка у вендора, но тем меньше трения у персонала в зале.
Где ломается интеграция
Проблемы на стыке CRM и кассы повторяются из проекта в проект. Бонусы начисляются с задержкой, и гость у стойки не видит своего баланса. При переносе старой программы лояльности появляются дубли карт. Бронь, принятая в CRM, не доходит до кассы, и стол оказывается занят. В сети из нескольких точек данные по каждому заведению живут отдельно, и гость, накопивший бонусы в одном ресторане, не может потратить их в другом.
Для интегратора это означает, что внедрение CRM в HoReCa — проект про данные и процессы, а не про установку коробки. Значительная часть работы — перенос базы, сопоставление гостей и обучение смены.
Как это решают вендоры: пример ReMarked
Показательный пример — подход, который описывает на своём сайте remarked.ru. Для iiko и r_keeper у сервиса есть собственный плагин на кассе: он ставится на рабочее место кассира и работает в момент пробития чека. Если в заведении уже настроен iikoCard, система работает через него, механика начисления остаётся прежней. С Tillypad и 1С выстроен обмен данными о гостях и продажах.
Интеграция не ограничивается лояльностью. Резервы и депозиты уходят прямо на кассу, заказы из разных каналов передаются в iiko или r_keeper, а при звонке через облачную АТС или Asterisk администратор видит анкету гостя. Для сетей предусмотрена одна база гостей на все точки и разграничение доступа: сотрудник видит данные только своего ресторана или всей сети.
Результат такой связки в цифрах есть у холдинга OKSMA: централизованная система резервов с полной интеграцией r_keeper снизила нагрузку на колл-центр на 30%.
Что это значит для рынка
Конкуренция вендоров CRM в HoReCa постепенно смещается от списка функций к качеству стыка с кассой и телефонией. Сегментацию и рассылки умеют делать многие. Выигрывает тот, у кого бонус начисляется в момент оплаты, бронь не теряется по дороге на кассу, а внедрение в сети не превращается в многомесячный проект. Для интеграторов, которые уже обслуживают iiko и r_keeper у ресторанных клиентов, это естественная точка расширения услуг: они лучше других понимают инфраструктуру заведения и могут взять на себя ту часть внедрения, где чаще всего возникают ошибки.
Источник: Пресс-служба ООО «ТОЧНО В ЦЕЛЬ»
