Предложение для этно-кафе: три блока и презентация гостевого PWA

Часть моих проектов заканчивается на документах. Клиент смотрит предложение, думает, ищет деньги. Разбираю такой случай честно: что в документах, чего в них нет и что из этого не проверено.

Задача

Заказчик владеет небольшим этно-кафе с двумя точками. Название и город я не называю. Кассовая программа работает, вокруг неё пусто. Продажи по годам никто не сводит, остатки сырья считают вручную, базы гостей нет.

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

Что я сделал: коммерческое предложение

Один лист A4. Вверху сказано, что система строится вокруг имеющейся кассы и ничего не переносится. Дальше три блока.

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

Второй, склад по техкартам. Продажа сама списывает сырьё, остатки видны в любой момент, на исходе приходит напоминание. Недостача считается как разница между расчётом и фактом.

Третий, гости и розыгрыши в MAX. Гость подписывается по QR на столе или чеке. Розыгрыш привязан к чеку от суммы, отзыву или приведённому другу. В базе остаются день рождения и частота визитов. Похожую связку я описывал в кейсе про другое кафе.

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

Внизу четыре вопроса к кафе: какая касса, какой ОФД и есть ли доступ в кабинет, сколько точек и позиций и есть ли техкарты, кто считает остатки и в чём.

Что я сделал: презентация приложения для гостей

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

По коду я посчитал: экранов макета семь, слайдов шесть. Экраны размером 390 на 844 собраны одним HTML-файлом, скрипт снимает каждый картинкой. Второй скрипт собирает слайды 16 на 9 и PDF.

Семь экранов. Главная: карта гостя, два действия «с собой» и «к столу», блок про свежую партию горячего блюда по расписанию. Меню на пять разделов с весами и ценами. Оформление с выбором способа получения, списанием баллов и оплатой СБП или картой. Статус заказа в четыре шага. Карта гостя с QR для кассы и тремя уровнями. Розыгрыш недели с таймером и тремя способами получить номерок. Профиль с подарком ко дню рождения и ссылкой для друга.

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

Что было сложно

Первое, показать приложение, которого нет, и не соврать. На первых четырёх слайдах стоит сноска: цены, имена и цифры на экранах условные. Цены блюд придуманы мной, имя гостя и баллы тоже. Оплата СБП нарисована кнопкой, провайдер не подключён.

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

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

Четвёртое, вёрстка. Лист должен держаться на одной странице, слайд помещаться в 1280 на 720. Скрипты сборки меряют зазор до подвала и ловят переполнение.

Что получилось

Отдано предложение и презентация, реализации нет. Что чеки доступны за все годы и что касса отдаст данные, я не проверял.

Что дальше

Если заказчик решит работать: договор, предоплата, этап аналитики. Первым делом нужны название кассовой программы и доступ в кабинет ОФД. Если чеки доступны только за последние месяцы, обещание про пять лет придётся пересматривать. Рабочее приложение для гостей собирается на меню и ценах самого кафе, с двумя кругами правок, потом QR на столы и обучение кассира. Если ответа не будет, макеты останутся образцом предложения.

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

Приложение для гостей уже работает?

Нет. Есть семь статичных экранов и презентация. Нет сервера, входа по номеру, оплаты и списания баллов. Всё на экранах нарисовано.

Почему макеты некликабельные?

В этом проекте экраны собраны как картинки для слайдов. Кликабельный прототип собрать можно, но это отдельная работа, а решения клиента пока нет.

Что нужно от кафе, чтобы начать?

Четыре вещи: касса и программа, ОФД с доступом в кабинет, число точек и позиций с техкартами, кто и в чём считает остатки. Без ответов цену и срок этапа я не подтверждаю.

Коротко о главном

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

Сейчас это отданные документы. Решения заказчика, договора и работающего приложения нет. Если у вас кафе и вы хотите увидеть систему до оплаты разработки, напишите в Telegram, MAX или VK. Формат описан на странице мобильного приложения и PWA.