Специфікація рішення Reven та обсяг доступу
Reven — модульна платформа для сервісних компаній і ресторанів. Вона об’єднує продаж та обслуговування ваучерів, депозитів, списків очікування, бронювань, програм лояльності й купонів, а для ресторанів — спільне меню, Ordering, KDS, Kiosk і POS.
Перевірено 2026-07-15
Reven — модульна платформа для сервісних компаній і ресторанів. Вона об’єднує продаж та обслуговування ваучерів, депозитів, списків очікування, бронювань, програм лояльності й купонів, а для ресторанів — спільне меню, Ordering, KDS, Kiosk і POS.
Цей документ описує можливості платформи. Обсяг, наданий конкретній компанії, визначається виключно таблицею «Обсяг клієнта», договором, активними модулями та погодженими інтеграціями. Наявність функції в Reven не означає, що її автоматично включено до кожного пакета.
Дані документа
| Поле | Значення для заповнення |
|---|---|
| Клієнт / назва компанії | |
| Ідентифікатор або slug компанії | |
| Версія специфікації | |
| Дата набрання чинності | |
| Регіон і валюта | |
| Публічна мова за замовчуванням | |
| Відповідальний за впровадження |
Обсяг клієнта
Перед підписанням або запуском потрібно позначити активні модулі та залежності.
| Модуль | Включено | Основні залежності / примітки |
|---|---|---|
| Публічний профіль і панель компанії | ☐ | акаунт власника, профіль, мова, валюта |
| Ваучери | ☐ | пропозиція, онлайн-оплата або ручний випуск, лист/PDF |
| Депозити | ☐ | правило суми, послуги, політика скасування, платіж |
| Список очікування | ☐ | публічна форма, обов’язкові дані, розклад |
| Бронювання | ☐ | послуги, спеціалісти, доступність, правила скасування |
| Лояльність | ☐ | бали або відмітки, винагороди, картка клієнта |
| Купони | ☐ | кампанії, ліміти й погашення працівником |
| Reven Ordering | ☐ | опубліковане меню, платежі, самовивіз/доставка |
| Reven KDS | ☐ | станції приготування й операційна обробка замовлень |
| Reven Kiosk | ☐ | пристрій, локальний агент, термінал і фіскальна інтеграція відповідно до обсягу |
| Reven POS | ☐ | спільне меню, робоче місце й погоджений спосіб оплати |
| Платіжні інтеграції | ☐ | провайдер, торговий акаунт, валюта, онбординг і webhooks |
| Wallet / цифрові картки | ☐ | окреме налаштування Apple/Google залежно від продукту |
| Міграція даних / зовнішні інтеграції | ☐ | лише після визначення джерела, обсягу й критеріїв приймання |
Загальні функції платформи
Панель показує лише активні для компанії модулі та функції, дозволені роллю користувача. У межах придбаного плану власник може керувати профілем компанії, командою, налаштуваннями продуктів, платежами, приватністю й білінгом. Підтримувані мови публічного контенту: польська, англійська, російська, українська та іспанська; повнота перекладу залежить від модуля й контенту, введеного клієнтом.
Система зберігає суми в найменших одиницях валюти й не зберігає повних даних платіжних карток. Карткові транзакції та локальні способи оплати обробляє налаштований провайдер.
Опис модулів
Ваучери
Клієнти можуть продавати ваучери на довільну суму, фіксовану вартість і конкретну пропозицію, послугу, товар або враження. Компанія налаштовує номінали, довільну суму, ціну продажу, строк дії, часткове або одноразове погашення, оформлення PDF, тексти й зображення. Працівники можуть вручну випускати ваучер, перевіряти баланс, погашати й анулювати його в межах своїх прав і повторно надсилати матеріали. Дозволені ваучери можна використовувати як перевагу під час замовлення; пропозиція, пов’язана з позицією меню, може надавати право саме на цю позицію. Докладніше: Ваучери.
Депозити
Модуль приймає передоплату, пов’язану з бронюванням. Сума може бути фіксованою, відсотковою або визначеною працівником індивідуально. Компанія налаштовує список послуг, публічну політику скасування й необов’язкове правило повернення. У панелі відображаються депозити, статуси й операції, а уповноважені працівники створюють швидкі посилання. Докладніше: Депозити.
Список очікування
Публічна форма дає клієнтові змогу приєднатися до списку очікування. Компанія визначає обов’язковість телефону й email та налаштовує послуги, бажані дати й час, кількість можливих дат і години приймання заявок. Працівники керують статусами, нотатками та зв’язком із клієнтом, який очікує. Докладніше: Список очікування.
Бронювання
Кінцевий клієнт вибирає послугу, спеціаліста й доступний час. Компанія задає горизонт бронювання, інтервал слотів, вікно скасування, послуги, тривалість, ціни, необов’язковий депозит, спеціалістів і їхні розклади. У панелі обробка записів об’єднана з депозитами та заявками списку очікування. Докладніше: Бронювання.
Лояльність і купони
Програма Loyalty використовує бали або відмітки. Компанія задає назву програми, правило нарахування, цільову кількість відміток і винагороди за бали. Працівники можуть реєструвати клієнтів, сканувати картку й додавати або списувати баланс у межах своєї ролі. Купони — окремі кампанії з типом переваги, вмістом, датою завершення, загальним лімітом і лімітом на клієнта. Докладніше: Лояльність і купони.
Restaurant Commerce
Ordering, KDS, Kiosk і POS використовують спільне меню та єдиний процес замовлення. Меню містить категорії, позиції, ціни, зображення, позначки, групи модифікаторів, доступність, станції приготування, зони доставки, збори, мінімальні суми замовлення, місткість і базовий час виконання. Замовлення може бути для обслуговування в закладі, самовивозу або налаштованої доставки. Компанія вибирає автоматичне прийняття оплачених замовлень або ручне підтвердження з обіцяним часом виконання.
Kiosk проводить гостя через меню й оплату та може пропонувати окрему купівлю ваучера. Фізичний термінал, фіскальний принтер, сканер і драйвери є частиною рішення лише тоді, коли їх зазначено в обсязі клієнта й прийнято за результатами тестування. Без відповідної інтеграції з пристроєм Reven не можна вважати сертифікованою фіскальною касою. Докладніше: Restaurant Commerce.
Налаштування й відповідальність
Reven надає активні модулі та погоджені інтеграції. Клієнт відповідає за правильність своєї пропозиції, цін, податків, контенту, умов, даних працівників, розкладів, доступності, правил скасування та даних акаунта провайдера. Перед публікацією клієнт повинен провести тест купівлі або бронювання й тест операції працівника.
Зміни налаштувань можуть одразу вплинути на нові транзакції та публічні сторінки. Їхній вплив на раніше продані ваучери, оплачені замовлення або збережені бронювання потрібно оцінювати окремо; не можна припускати, що історичні snapshots і статуси перерахувалися автоматично.
Залежності й винятки
- Доступність способів оплати залежить від валюти, регіону, статусу торгового акаунта й провайдера.
- Доставка повідомлень залежить від правильної адреси клієнта й поштового провайдера.
- Apple Wallet, Google Wallet, термінали, фіскальна інтеграція, принтери й сканери потребують відповідного налаштування або драйвера.
- Міграції, інтеграції з marketplace, зовнішні POS, бухгалтерія й нестандартні звіти не включені за замовчуванням.
- Функції зі статусом pilot, demo або simulator не стають виробничим зобов’язанням без окремого підтвердження.
Приймання рішення
Перед запуском обидві сторони мають підтвердити:
- активні модулі й ролі користувачів;
- профіль, мову, валюту та публічні посилання;
- тестову транзакцію, скасування й, де застосовно, повернення;
- доставку email/PDF/Wallet для використовуваних продуктів;
- реальний сценарій працівника: сканування, погашення, прийняття замовлення або обробку запису;
- пристрої та зовнішні інтеграції, зазначені в обсязі;
- процедуру звернення до підтримки й осіб, уповноважених запитувати зміни.
Після заповнення даних документа, обсягу й підписів ця специфікація може бути основою функціонального додатка до договору за умови комерційного та юридичного затвердження.