Один из частых вопросов от ресторанов и служб доставки звучит так:
«У нас уже несколько лет работает сайт на базе конструктора iiko. Можно ли перенести его на новую платформу, чтобы сохранились личные кабинеты гостей, их данные, история заказов и бонусы iikoCard?»
Короткий ответ: да, в большинстве случаев такой переход возможен.
Но важно правильно понимать, что именно переносится, откуда берутся данные и какие сценарии нужно заранее проверить.
Для ресторана или доставки главное не просто “поменять сайт”. Главное — не потерять клиентскую базу, не сломать бонусную систему и сделать так, чтобы постоянные гости продолжили пользоваться сервисом без лишних действий.
Разберём по порядку.
Почему рестораны хотят перейти с типового сайта iiko на отдельный сайт или мобильное приложение
Типовой сайт или конструктор часто закрывает базовую задачу: показать меню и принять заказ. На старте этого может быть достаточно.
Но со временем бизнес растёт, и появляются новые требования:
нужен более удобный интерфейс для гостей;
хочется современный дизайн под бренд;
нужно мобильное приложение;
нужна гибкая работа с акциями и спецпредложениями;
хочется управлять баннерами, подборками, сторис, промокодами;
нужна более сильная маркетинговая механика;
важно лучше работать с повторными заказами;
хочется развивать прямые продажи, а не зависеть только от агрегаторов.
И тогда возникает логичный вопрос: можно ли перейти на новую платформу, но сохранить всё важное, что уже накопилось за годы работы?
Что важно сохранить при переносе сайта доставки
Для ресторана ценность старого сайта не только в самом сайте. Основная ценность — в данных гостей и истории взаимодействия с ними.
При переходе на новую платформу обычно важно сохранить:
имя гостя;
фамилию, если она была заполнена;
номер телефона;
e-mail;
адреса доставки;
историю заказов;
бонусный баланс;
уровень или статус в программе лояльности;
связь с iikoCard;
данные, которые нужны для повторных заказов.
То есть задача не в том, чтобы “скопировать страницы”.
Задача — перенести клиентский опыт так, чтобы гость не почувствовал обрыва.
Он уже заказывал у вас раньше, у него есть бонусы, история, любимые блюда, адрес доставки. Если после перехода всё это исчезает, для гостя это выглядит как шаг назад.
Можно ли сохранить бонусы iikoCard
Если программа лояльности работает через iikoCard, то бонусы обычно не нужно “переносить” вручную как отдельную независимую таблицу.
Правильная логика такая: новый сайт или мобильное приложение подключается к нужному контуру iiko/iikoCard, а после авторизации гостя система подтягивает его актуальные данные:
бонусный баланс;
доступные скидки;
статус в программе лояльности;
условия начисления и списания;
доступные механики лояльности.
То есть для гостя сценарий должен быть простым:
Он заходит на новый сайт или в приложение.
Авторизуется по номеру телефона.
Система находит его в клиентской базе.
Он видит свои бонусы и может продолжать ими пользоваться.
Это особенно важно, потому что бонусы — это уже не просто “маркетинг”. Для гостя это его накопленная ценность. Если при переходе бонусы пропадают или отображаются некорректно, доверие к бренду падает.
Можно ли сохранить историю заказов
История заказов — отдельный важный блок. Здесь всё зависит от того, где именно она хранится и в каком виде её можно получить.
Возможны разные сценарии:
1. История заказов доступна через учётную систему или API
В этом случае её можно отобразить в новом личном кабинете, если данные доступны для интеграции и корректно связаны с гостем.
2. История заказов есть в выгрузке
Если можно получить структурированную выгрузку по клиентам и заказам, её можно импортировать в новую систему или использовать для отображения данных в личном кабинете.
3. История заказов недоступна для полноценного переноса
Такое тоже бывает. Тогда можно сохранить клиентскую базу, бонусы и текущую авторизацию, а историю новых заказов уже начать вести в новой системе с момента запуска.
Главное — заранее провести аудит: где хранятся данные, в каком формате они доступны и что именно можно подтянуть в новый личный кабинет.
Что будет с логином и паролем от старого сайта
Это один из самых частых вопросов.
Теоретически, если у ресторана есть доступ к базе логинов и паролей в подходящем формате, можно отдельно проработать сценарий их переноса. Но на практике с паролями всё сложнее.
В нормальных системах пароли не должны храниться в открытом виде. Они обычно хранятся в зашифрованном или хэшированном виде. Поэтому часто их нельзя просто “выгрузить и загрузить” в новую систему.
И это нормально с точки зрения безопасности.
Но для гостя это не должно становиться проблемой, потому что современный личный кабинет можно построить без классической схемы “логин + пароль”.
Почему пароль чаще всего не нужен
Для ресторанной доставки удобнее использовать авторизацию по номеру телефона.
Это может быть:
SMS-код;
flash-call;
авторизация по звонку;
авторизация через Telegram;
авторизация через MAX;
другой сценарий подтверждения номера.
Гость вводит номер телефона, подтверждает его и попадает в личный кабинет.
После этого система связывает его с существующей клиентской базой и подтягивает нужные данные.
Такой сценарий даже удобнее, чем старые пароли:
не нужно вспоминать пароль;
не нужно восстанавливать доступ через e-mail;
меньше барьеров при заказе;
проще пользоваться с телефона;
удобнее для мобильного приложения.
Для ресторана это тоже плюс: чем проще вход, тем меньше гостей отваливается на этапе авторизации.
Как выглядит сценарий для гостя после переноса
Хороший перенос должен быть незаметным для клиента.
Идеальный сценарий такой:
Гость заходит на новый сайт или скачивает мобильное приложение.
Вводит номер телефона.
Подтверждает вход удобным способом.
Видит свои данные.
Видит бонусы.
Может использовать программу лояльности.
Может повторить заказ или оформить новый.
Дальше остаётся авторизованным на устройстве.
На сайте сессия может сохраняться в браузере достаточно долго, поэтому гостю не нужно каждый раз входить заново.
В мобильном приложении ещё проще: пользователь один раз авторизовался, и дальше приложение остаётся “его”. Повторная авторизация обычно нужна только после выхода из аккаунта, смены устройства или крупного технического обновления.
Что новый личный кабинет может дать сверх базового сайта
При переходе с типового сайта на более гибкую платформу задача не только в переносе данных.
Новый личный кабинет может стать удобнее и полезнее для гостя.
В нём можно реализовать:
личные данные;
адреса доставки;
историю заказов;
бонусный баланс;
QR-код или карту лояльности;
избранные блюда;
повтор заказа;
персональные акции;
промокоды;
пуш-уведомления;
спецпредложения;
статусы заказа;
удобную работу с доставкой и самовывозом.
То есть сайт и приложение становятся не просто витриной меню, а полноценным цифровым каналом для повторных продаж.
Что нужно подготовить ресторану перед переносом
Чтобы оценить возможность переноса, обычно нужно собрать базовую информацию:
Какая версия и конфигурация iiko используется.
Работает ли программа лояльности через iikoCard.
Где сейчас хранится клиентская база.
Можно ли получить выгрузку клиентов.
Можно ли получить историю заказов.
Какие поля есть в клиентской базе.
Какие способы авторизации используются сейчас.
Какие данные должны отображаться в новом личном кабинете.
Нужен ли только сайт или сайт + мобильное приложение.
Какие акции, скидки и бонусные механики нужно сохранить.
После этого можно понять, какой сценарий переноса подходит именно вашему проекту.
Какие есть ограничения
Важно честно сказать: не всё всегда можно перенести “один в один”.
Чаще всего ограничения касаются:
старых паролей;
неполной истории заказов;
нестандартных полей в базе;
старых адресов доставки;
данных, которые не были корректно связаны с номером телефона;
старых заказов, которые хранятся не там, где их можно удобно получить.
Но это не означает, что переход невозможен.
Обычно ключевая задача решается: клиентская база сохраняется, бонусы подтягиваются, авторизация работает, а новый личный кабинет становится удобнее старого.
Что важно протестировать перед запуском
Перед публикацией нового сайта или приложения нужно обязательно проверить реальные сценарии:
авторизация существующего гостя;
отображение бонусного баланса;
начисление бонусов;
списание бонусов;
оформление заказа;
повторный заказ;
самовывоз;
доставка;
применение акции;
корректная передача заказа в учётную систему;
работа с несколькими точками;
отображение истории заказов, если она переносится.
Особенно внимательно нужно тестировать всё, что связано с бонусами и оплатой. Это зона доверия гостя. Если человек видит неправильный баланс или не может списать бонусы, программа лояльности превращается из преимущества в источник раздражения.
Можно ли перейти постепенно
Да, в некоторых проектах переход можно делать поэтапно.
Например:
Сначала запустить новый сайт.
Проверить авторизацию и заказы.
Подключить личный кабинет.
Затем запустить мобильное приложение.
После этого развивать акции, пуши, лояльность и CRM-маркетинг.
Такой подход снижает риски, потому что ресторан не меняет всё одновременно, а аккуратно переводит гостей в новую цифровую среду.
Что в итоге получает ресторан
При корректном переносе ресторан получает не просто новый сайт.
Он получает более управляемую систему прямых продаж:
гости продолжают пользоваться своими бонусами;
клиентская база не теряется;
авторизация становится проще;
заказы оформляются удобнее;
появляются новые маркетинговые возможности;
личный кабинет работает на повторные покупки;
можно добавить мобильное приложение;
ресторан меньше зависит от ограничений типовой платформы.
Для гостя это выглядит как улучшение сервиса.
Для собственника — как переход от базового онлайн-заказа к полноценному цифровому каналу продаж.
Как РЕСТОЦРМ / RESTOCRM подходит к таким переходам
В РЕСТОЦРМ / RESTOCRM мы рассматриваем такой проект не как “переезд сайта”, а как перенос клиентского опыта.
Нам важно сохранить то, что уже накоплено:
базу гостей;
бонусы;
историю взаимодействия;
привычные сценарии заказа;
связь с учётной системой и программой лояльности.
И одновременно улучшить то, что ограничивало ресторан раньше:
интерфейс;
личный кабинет;
мобильное приложение;
акции;
повторные продажи;
маркетинговые механики;
удобство заказа.
Если ресторан уже работает на iiko, использует iikoCard и хочет перейти с типового сайта на более гибкую платформу, сначала нужно провести аудит данных и интеграций. После этого можно выбрать безопасный сценарий перехода: с сохранением клиентской базы, бонусов и удобной авторизацией для гостей.