Сложность POS-системы не в том, чтобы записать заказ. Сложность — оставаться читаемой в час пик, помнить удалённую продажу, не падать при обрыве связи и гарантировать, что цена приходит из одного места.
Пять решений определяют исход POS ресторана: (1) отмены не запрещаются, но оставляют след; (2) касса — сенсорная и с минимумом касаний, работающая рефлекторно; (3) кухонный экран — не список заказов, а экран состояния с цветовой индикацией ожидания; (4) цена меню приходит из одного источника, включая QR-меню; (5) данные лояльности — естественная часть записи о продаже, а не приделанный модуль. Эти решения важнее выбора языка или фреймворка.
Большинство разработчиков начинают POS с модели данных: стол, заказ, товар, оплата. Модель работает за неделю, и система выглядит готовой.
Настоящие проблемы начинаются потом, и ни одна из них не про модель данных:
Ни один пункт не решается лучшей схемой базы данных. Все они — продуктовые решения.
Самая чувствительная функция POS — не добавить продажу, а удалить её.
Обе крайности неверны. Запретите отмены — система станет непригодной: ошибки бывают в каждую смену. Разрешите свободно — откроете самый лёгкий путь к недостаче: ввели позицию, получили деньги, удалили запись.
Правильная схема посередине: отмены разрешены, но оставляют след.
Единственный критерий интерфейса кассы — скорость, и она берётся из числа касаний, а не из визуального минимализма.
Преимущество веб-POS: одно приложение работает как разные виды на кассе, планшете и кухонном экране. Нет установки на каждое устройство и расхождения версий.
Самая частая ошибка — отдать кухне административный список заказов. Он создан для операций интернет-магазина: фильтры, поиск, постраничная навигация.
Человек на кухне не читает списки. Он смотрит на экран с полутора метров, с занятыми руками, одну секунду. Экран должен сказать ему одно: что делать сейчас?
В ресторане цена появляется минимум в трёх местах: на кассе, в печатном или QR-меню и на сайте заказов, если он есть. В разных системах они неизбежно расходятся.
Результат — спор с гостем, и этот спор заведение проигрывает каждый раз.
Правильная схема: у цены один источник, остальные поверхности читают из него. QR-меню должно питаться данными о товарах из POS — не отдельный сайт меню, а другой вид тех же данных.
В ресторане связь пропадёт. Это вопрос времени, а не вероятности. Если система не готова, обслуживание останавливается, заведение переходит на бумагу — и данные этой смены теряются навсегда.
Какой уровень нужен — зависит от заведения, и это бюджетное решение, а не техническая необходимость. Но решение должно быть осознанным. Худший вариант — когда вопрос не задали и ответ узнали при первом обрыве.
В большинстве систем программа лояльности — приделанный позже модуль, и поэтому работает плохо: запись о продаже и запись о клиенте живут в разных местах, сопоставление зависит от инициативы кассира, данные собираются наполовину.
А ведь лояльности нужно лишь фиксировать, кому сделана продажа. Это решение принимается в самом начале.
Критично, чтобы правило не было зашито в код. «Двойные штампы на фильтр-кофе по вторникам» не должно требовать обновления ПО. Иначе бизнес перестаёт экспериментировать, и система несёт мёртвую функцию.
POS отличает не выбор технологии, а пять решений: отмены оставляют след, касса работает за минимум касаний, кухонный экран показывает состояние, цена приходит из одного источника, а продажа знает, кому она сделана.
Пример этой архитектуры на практике: POS и лояльность Sisa Atelier.
Для одной точки со стандартной работой готовый продукт обычно дешевле и достаточен. Своя разработка оправдана, когда схема лояльности, логика кампаний или требования к отчётности не помещаются в рамки продукта. Решающий вопрос: насколько ценно, чтобы система помнила клиента и правила задавали вы?
Достаточно, если экран читается с расстояния. Повар смотрит примерно с полутора метров; список мелким шрифтом бесполезен. Возможность увидеть время ожидания и цвет опоздания с этого расстояния важнее размера экрана.
Зависит от того, на какой уровень устойчивости построена установка. На простом уровне система предупреждает и не теряет данные, но принимать заказы нельзя. На среднем открытые заказы хранятся на устройстве и синхронизируются при восстановлении. Это бюджетное решение — важно принять его осознанно при разработке.
Они работают скорее на возврат существующих гостей, чем на привлечение новых, — а именно там прибыльность кофейни. Условие: правило должно подходить бизнесу и настраиваться опытным путём. В системе с фиксированным правилом функция лояльности быстро выходит из употребления.