Онлайн-заказ и r_keeper: как сделать, чтобы оплаченный заказ сам попадал на кассу
Во многих заведениях онлайн-заказ до сих пор выглядит так: гость оформляет заказ на сайте или в мессенджере, администратор видит уведомление и вручную набирает его на кассе. Это работает, пока заказов мало. Когда их становятся десятки в час, начинаются ошибки: потерянные позиции, перепутанные модификаторы, заказ, который приготовили, но не оплатили.
Правильная схема убирает человека из середины цепочки. Расскажем, как она устроена и что важно проверить до старта.
Как выглядит схема без ручного ввода
- Гость собирает заказ на сайте, в приложении или в корпоративном кабинете. Меню, цены и стоп-лист берутся из учётной системы, а не ведутся отдельно.
- Оплата проходит через Kaspi или Halyk. Сервис ждёт подтверждения от платёжной системы, а не просто факта перехода на страницу оплаты.
- После подтверждения заказ передаётся в r_keeper через официальный интерфейс для внешних заказов и появляется на кассе и на кухне.
- Статусы приготовления возвращаются обратно, и гость получает уведомление, когда заказ готов.
Что проверить до начала разработки
- Лицензии. Для приёма внешних заказов в r_keeper обычно нужен отдельный модуль доставки и соответствующая лицензия. Это дополнительная статья расходов, её лучше учесть сразу.
- Справочник меню. Блюда, модификаторы и комбо на сайте должны однозначно соответствовать позициям в учётной системе. Расхождения — самая частая причина ошибок.
- Стоп-лист. Если блюдо закончилось на кухне, оно должно автоматически исчезнуть из онлайн-меню.
- Возвраты и отмены. Нужно заранее решить, кто и как отменяет оплаченный заказ и как возвращаются деньги.
Где такие интеграции обычно ломаются
Главный риск — сбой связи между сервисом и кассой в момент, когда оплата уже прошла. Поэтому каждый заказ должен храниться в сервисе до подтверждения от кассы, а при ошибке — автоматически отправляться повторно и попадать в журнал, который видит администратор. Второй риск — дубли: повторное уведомление от платёжной системы не должно создавать второй заказ на кухне.
С чего начать
Мы начинаем с короткого аудита: смотрим версию r_keeper, доступные лицензии, структуру меню и текущий поток заказов. Затем запускаем пилот на одной точке и только после проверки на реальных заказах подключаем остальные. Если хотите убрать ручной ввод онлайн-заказов, оставьте заявку — разберём вашу ситуацию.
Көптеген мекемелерде онлайн-тапсырыс әлі күнге дейін былай көрінеді: қонақ сайтта немесе мессенджерде тапсырыс береді, әкімші хабарламаны көріп, оны кассада қолмен тереді. Тапсырыс аз болғанда бұл жұмыс істейді. Ал сағатына ондаған тапсырыс түскенде қателер басталады: позициялар жоғалады, модификаторлар шатасады, тапсырыс дайындалады, бірақ төленбей қалады.
Дұрыс схема тізбектің ортасынан адамды алып тастайды. Оның қалай құрылғанын және іске қоспас бұрын нені тексеру маңызды екенін айтамыз.
Қолмен енгізусіз схема қалай көрінеді
- Қонақ тапсырысты сайтта, қосымшада немесе корпоративтік кабинетте жинайды. Мәзір, баға және стоп-парақ бөлек жүргізілмейді, есеп жүйесінен алынады.
- Төлем Kaspi немесе Halyk арқылы өтеді. Сервис төлем бетіне өту фактісін емес, төлем жүйесінің растауын күтеді.
- Растаудан кейін тапсырыс сыртқы тапсырыстарға арналған ресми интерфейс арқылы r_keeper жүйесіне беріліп, кассада және ас үйде пайда болады.
- Дайындау мәртебелері кері қайтарылады, ал тапсырыс дайын болғанда қонақ хабарлама алады.
Әзірлеуді бастамас бұрын нені тексеру керек
- Лицензиялар. r_keeper жүйесінде сыртқы тапсырыстарды қабылдау үшін әдетте жеке жеткізу модулі және тиісті лицензия қажет. Бұл қосымша шығын бабы, оны бірден ескерген жөн.
- Мәзір анықтамалығы. Сайттағы тағамдар, модификаторлар мен комболар есеп жүйесіндегі позицияларға бірмәнді сәйкес келуі тиіс. Сәйкессіздіктер — қателердің ең жиі себебі.
- Стоп-парақ. Егер тағам ас үйде таусылса, ол онлайн-мәзірден автоматты түрде жоғалуы керек.
- Қайтарулар мен бас тартулар. Төленген тапсырыстан кім және қалай бас тартатынын, ақша қалай қайтарылатынын алдын ала шешу қажет.
Мұндай интеграциялар әдетте қай жерде бұзылады
Басты тәуекел — төлем өтіп қойған сәтте сервис пен касса арасындағы байланыстың үзілуі. Сондықтан әр тапсырыс кассадан растау келгенге дейін сервисте сақталуы, ал қате болса — автоматты түрде қайта жіберіліп, әкімші көретін журналға түсуі тиіс. Екінші тәуекел — қайталанулар: төлем жүйесінен келген қайталама хабарлама ас үйде екінші тапсырыс тудырмауы керек.
Неден бастау керек
Біз қысқа аудиттен бастаймыз: r_keeper нұсқасын, қолжетімді лицензияларды, мәзір құрылымын және ағымдағы тапсырыстар ағынын қараймыз. Содан кейін бір нүктеде пилот іске қосамыз және нақты тапсырыстарда тексергеннен кейін ғана қалғандарын қосамыз. Онлайн-тапсырыстарды қолмен енгізуден арылғыңыз келсе, өтінім қалдырыңыз — жағдайыңызды талдаймыз.