Reven solution specification and access scope
Reven is a modular platform for service businesses and restaurants. It combines the sale and operation of vouchers, deposits, waitlists, bookings, loyalty programmes and coupons and, for restaurants, a shared menu, Ordering, KDS, Kiosk and POS.
Verified 2026-07-15
Reven is a modular platform for service businesses and restaurants. It combines the sale and operation of vouchers, deposits, waitlists, bookings, loyalty programmes and coupons and, for restaurants, a shared menu, Ordering, KDS, Kiosk and POS.
This document describes the platform's capabilities. The scope provided to a specific business is determined solely by the “Customer scope” table, the agreement, active modules and agreed integrations. A feature available in Reven is not automatically included in every package.
Document details
| Field | Value to complete |
|---|---|
| Customer / business name | |
| Business identifier or slug | |
| Specification version | |
| Effective date | |
| Region and currency | |
| Default public language | |
| Implementation owner |
Customer scope
Active modules and dependencies must be marked before signing or launch.
| Module | Included | Key dependencies / notes |
|---|---|---|
| Public profile and business dashboard | ☐ | owner account, profile, language, currency |
| Vouchers | ☐ | offer, online payment or manual issue, email/PDF |
| Deposits | ☐ | amount rule, services, cancellation policy, payment |
| Waitlist | ☐ | public form, required details, schedule |
| Booking | ☐ | services, specialists, availability, cancellation rules |
| Loyalty | ☐ | points or stamps, rewards, customer card |
| Coupons | ☐ | campaigns, limits and staff redemption |
| Reven Ordering | ☐ | published menu, payments, pickup/delivery |
| Reven KDS | ☐ | preparation stations and operational order handling |
| Reven Kiosk | ☐ | device, local agent, terminal and fiscal integration depending on scope |
| Reven POS | ☐ | shared menu, workstation and agreed payment method |
| Payment integrations | ☐ | provider, merchant account, currency, onboarding and webhooks |
| Wallet / digital cards | ☐ | separate Apple/Google configuration depending on the product |
| Data migration / external integrations | ☐ | only after source, scope and acceptance criteria are defined |
Shared platform features
The dashboard shows only modules active for the business and features allowed by the user's role. Within the purchased plan, the owner can manage the business profile, team members, product settings, payments, privacy and billing. The currently supported languages for public content are Polish, English, Russian, Ukrainian and Spanish; translation completeness depends on the module and content entered by the customer.
The system stores amounts in the currency's smallest units and does not store full payment-card data. Card transactions and local payment methods are processed by the configured provider.
Module descriptions
Vouchers
Customers can sell open-amount vouchers, fixed-value vouchers and vouchers for a specific offer, service, product or experience. The business can configure denominations, a custom amount, sale price, validity, partial or single-use redemption, PDF appearance, content and images. Staff can issue a voucher manually, check its balance, redeem it, void it within their permissions and resend its materials. Selected vouchers can be used as a benefit in an order; an offer linked to a menu item can grant entitlement to that exact item. Details: Vouchers.
Deposits
The module collects prepayments associated with a reservation. The amount can be fixed, percentage-based or set individually by staff. The business configures a list of services, a public cancellation policy and an optional refund rule. The dashboard shows deposits, statuses and operations, and authorised staff can create quick links. Details: Deposits.
Waitlist
A public form lets a customer join a waitlist. The business decides whether phone and email are required and configures services, preferred dates and times, the number of possible dates and the hours when submissions are accepted. Staff manage statuses, notes and contact with the waiting customer. Details: Waitlist.
Booking
The end customer chooses a service, specialist and available time. The business sets the booking horizon, slot interval, cancellation window, services, durations, prices, optional deposit, specialists and their schedules. The dashboard combines appointment handling with deposits and waitlist requests. Details: Booking.
Loyalty and coupons
The Loyalty programme uses either points or stamps. The business sets the programme name, earning rate, stamp target and point rewards. Staff can enrol customers, scan a card and add or subtract a balance according to their role. Coupons are separate campaigns with a benefit type, content, end date, total limit and per-customer limit. Details: Loyalty and coupons.
Restaurant Commerce
Ordering, KDS, Kiosk and POS use a shared menu and order flow. The menu includes categories, items, prices, images, labels, modifier groups, availability, preparation stations, delivery zones, fees, order minimums, capacity and base lead time. Orders can be for dine-in, pickup or configured delivery. The business chooses automatic acceptance of paid orders or manual confirmation with a promised fulfilment time.
Kiosk guides a guest through the menu and payment and can offer a separate voucher purchase. A physical terminal, fiscal printer, scanner and drivers are part of the solution only when listed in the customer scope and accepted in testing. Reven must not be treated as a certified fiscal cash register without the appropriate device integration. Details: Restaurant Commerce.
Configuration and responsibilities
Reven provides the active modules and agreed integrations. The customer is responsible for the accuracy of its offer, prices, taxes, content, terms, staff data, schedules, availability, cancellation rules and provider-account details. Before publication, the customer should run a purchase or booking test and a staff-operation test.
Configuration changes can affect new transactions and public pages immediately. Their effect on previously sold vouchers, paid orders or saved bookings must be assessed separately; historical snapshots and statuses must not be assumed to have been recalculated automatically.
Dependencies and exclusions
- Payment-method availability depends on currency, region, merchant-account status and provider.
- Message delivery depends on a correct customer address and the email provider.
- Apple Wallet, Google Wallet, terminals, fiscal integration, printers and scanners require the appropriate configuration or driver.
- Migrations, marketplace integrations, external POS, accounting and custom reports are not included by default.
- Features marked as pilot, demo or simulator do not become a production commitment without separate confirmation.
Solution acceptance
Before launch, both parties should confirm:
- active modules and user roles;
- profile, language, currency and public links;
- a test transaction, cancellation and — where applicable — refund;
- delivery of email/PDF/Wallet for the products in use;
- the real staff scenario: scan, redemption, order acceptance or appointment handling;
- devices and external integrations listed in scope;
- the support contact procedure and people authorised to request changes.
Once the document details, scope and signatures are completed, this specification can serve as the basis for a functional annex, subject to commercial and legal approval.