Oprivia FAQ: platform, onboarding, and proposals
Answers about positioning, modules, roles, the Pilot Program, tailored proposals, privacy, and how Oprivia differs from booking channels and property management systems (PMS).

Topic overview
Choose a topic to jump directly to the relevant answers.
About Oprivia
Name, purpose, target groups and current development stage.
Oprivia is a coined name derived from “operational” and “via”, the Latin word for way or route. It refers to a structured operating path after the booking.
Oprivia is a web-based governance and SLA platform for accommodation operators and their service partners. It connects guest registration, required data, service cases, housekeeping, partner services, records, approvals, and escalations in one operating workspace.
After the reservation, guest details, clarifications, cleaning, handoffs and partner services often spread across separate channels. Oprivia brings that work into a traceable operating context.
Oprivia is designed for professional hosts, hotels, business and serviced apartments, property managers, portfolio operators, tourism organizations, and operational partners with recurring coordination needs.
Oprivia is not designed for occasional private rentals without ongoing operational complexity. It is also not a booking portal and does not take over all operator responsibilities.
Oprivia is ready for operational use and is onboarding new customers. Once the scope is agreed, we begin setup and onboarding. A pilot is an optional, separately agreed way to start. Operators can invite and register guests, verify supported identity and travel documents from more than 220 countries and territories, perform liveness detection, biometric face matching, age checks, and sanctions-list screening, and manage the resulting verification status. Service partners can be onboarded and managed, tickets and tasks assigned, and workflow status and evidence recorded. Damage cases can be collected centrally and documented in a structured format. The modules, roles, and integrations activated for a specific business are defined in the agreed scope. Destination- or system-specific interfaces, such as transmitting registration data or issuing a guest card, and any broader consolidated routing of damage cases are not universally included standard services. They require technical assessment and an express agreement.
Oprivia is developed further in Switzerland and follows a quality standard based on precision, reliability, and controlled development. Its Swiss origin describes an operating standard, not a legal or performance guarantee.
Platform and scope
Core areas, shared platform functions and planned development.
The central areas are registration, required information, requests, cleaning, partner coordination, roles, records and evaluation. Which areas are introduced first depends on the specific operating model.
No. Oprivia can be introduced step by step. During onboarding, we prioritize the areas with the highest practical value for your operation. You can start regular operations with that agreed scope or evaluate individual workflows in a separate pilot.
Cross-functional elements include roles, access rights, workflow status, time windows, checklists, records, escalations and overviews.
Potential extensions include inventory functions, additional reporting, integrations and further review or risk functions. Features that are not yet available are marked as planned, optional or under review.
A single standard estimate of time savings cannot be given. The result depends on the number of stays, partners, service cases, and the quality of the existing process. During the pilot, coordination effort, processing times, rework, escalations, and evidence gaps are compared before and during the use of Oprivia.
Within the agreed deployment scope, Oprivia can support rule-based reminders, status changes, assignments and escalation. Triggers, deadlines and recipients are defined before deployment. Physical work, professional review and consequential approvals remain with the responsible people. The specific implementation is checked during setup for the agreed deployment. The governance approach explains this division of responsibility.
No, not by default. Oprivia can operate as a separate platform with its own login. A connection to existing systems is only required if data should be imported, exchanged or synchronized automatically. Such interfaces are subject to technical review and explicit agreement.
Roles and permissions
Questions on roles, permissions and governance functions.
Oprivia uses four core roles: Guest, Host, Operator, and Admin/Governance. Tasks, information, and permissions depend on the assigned role, organization, property, stay, and case.
A role only sees the information required for its intended task area. Access can also be limited by organization, property, stay or operational case.
A case can be assigned to an accountable role, a workflow status, and, where required, a time window. Handoffs and changes remain traceable.
Within the agreed deployment scope, overdue tasks, missing evidence or blocked cases can trigger escalation to a designated role. The reason, ownership and next decision remain linked to the case. Routing an escalation does not itself transfer a work order to a replacement partner. Acceptance, additional costs and professional approvals require the relevant decisions. A practical escalation example illustrates the sequence.
No. Oprivia can structure information, apply rules and highlight review needs. Critical approvals, exceptions and decisions remain with the responsible people.
Critical actions are added as new events in a continuous history. Earlier entries are not silently overwritten; corrections remain possible but are documented as additional entries.
Quality and evidence
Operational quality control without public ratings or rankings.
Oprivia is not a public review portal. The focus is on internal records, feedback, deviations and work results, not stars or rankings.
Quality is assessed through defined review points such as checklists, photo evidence, feedback, rework, approvals and documented outcomes.
Depending on the area and agreed setup, checklists, images, documents, notes, confirmations, timestamps or decisions can be assigned to the relevant case.
Critical audit events should not be silently overwritten. Corrections and new findings are added as additional entries. The exact scope depends on platform version and agreement.
Pilot program and process
Purpose, scope, participation and possible outcomes of a controlled pilot.
The pilot assesses whether Oprivia can be applied meaningfully to a specific operational case. The focus is on onboarding, operational assessment, roles, checklists, partner tasks, photo records and evaluation.
Suitable pilot clients are professional operators or partners with a concrete challenge, recurring workflows, named contact persons and willingness to participate in a structured evaluation.
The pilot can cover registration, required information, requests, cleaning, partner coordination, records, escalations and evaluation. The actual scope is defined separately.
At the beginning, the property, operating model, involved roles, partners, relevant workflows, evaluation metrics and excluded services are defined. This creates a clearly limited pilot scope.
The pilot client provides contact persons, property information, existing process documents, partner contacts and feedback. Access, data migration or integrations are agreed separately where required.
A pilot can be continued, adjusted, paused or closed. It creates a decision basis, but no automatic rollout, acceptance or contractual obligation.
Pricing and contract
How proposals are prepared, what pilot terms cover, and which additional costs may apply.
No. Oprivia does not publish fixed standard prices. Each proposal is prepared according to the operating structure, agreed scope, selected operating model, required functions, integrations, and support effort. A tailored proposal does not automatically mean a large enterprise project: a single professional operator can also start with a deliberately limited scope. You receive the terms and cost framework in writing before work begins. Oprivia does not take a share of booking revenue; any legally applicable VAT is identified in the proposal.
The operating scope used for the proposal is defined in writing. Depending on the deployment, it may include accommodation units, rooms, locations, organizations, or participating businesses. For portfolios and projects involving multiple businesses, the units, roles, services, coordination scope, and contractual structure are expressly agreed. Apartment or room count is not extrapolated automatically on a linear basis.
For the three-to-six-month pilot, the included units, workflows, roles, modules, support scope, success criteria, and technical requirements are agreed. The agreed pilot scope, commercial terms, and any additional or third-party services are documented in a written proposal before the pilot begins.
After the pilot or before a direct start, the operating model, included units or locations, roles, functions, support, and coordination scope are agreed. The proposal sets out the operating and service scope, commercial terms, and any separately agreed additional or third-party services.
No. Self-Managed Operations provides the platform, workflows, and evidence while operational coordination remains with the operator. Supported Operations adds expressly agreed assistance for clearly defined operational cases within the agreed scope. Portfolio Management extends coordination, governance, and reporting across multiple properties, locations, or teams. Cross-property coordination is included only when expressly agreed as a portfolio or project service.
The proposal identifies the agreed operating and service scope, commercial terms, and any expressly agreed additional or third-party services. Services that have not been agreed are not charged automatically.
For customers contracting directly with Oprivia outside the reseller program, pricing does not include a share of booking or accommodation revenue or any other revenue-based fee. Management and service fees are also not used as a pricing basis for these customers. The agreed proposal is based on the operating structure and service scope. Fees payable by authorized resellers to Oprivia are set out in a separate reseller agreement.
Oprivia prepares an individual proposal for every deployment. Relevant factors include the operating structure, included accommodation units, rooms, locations or organizations, the operating model, role and service scope, integrations, and the required level of support and coordination. Apartment or room count alone does not determine the price.
Value is not assessed through time savings alone. It also includes avoided errors and rework, faster escalations, stronger evidence, replaced point solutions and additional operational control. No specific ROI is guaranteed.
Agreed terms may change if the operating scope, included units or locations, roles, modules, integrations, support or coordination scope is adjusted, or if an additional or third-party service is expressly commissioned. Changes are documented in writing before they are activated or performed. For customers contracting directly with Oprivia outside the reseller program, there is no revenue-based component.
Pilot terms are set out in a separate written proposal. It specifies the pilot duration, included operating scope, modules, services, participation, success criteria, and cost framework. Any later continuation requires a separate agreement.
No. Guest access is free of charge. Commercial terms are agreed exclusively with the operator or contractual partner.
Additional or third-party services may include setup, training, integrations, data migration, special configuration, additional support, or external services such as cleaning, laundry, consumables, and repairs. The proposal identifies the services and usage allowances that are included. Additional identity, AML, PEP, business, or country-specific checks are activated and listed separately only when expressly commissioned.
Referral benefits may be offered. Eligibility, amount, duration, and application are governed by the current written referral terms. A referral credit is separate from Oprivia’s pricing calculation and does not constitute revenue sharing.
Data and privacy
Data types, visibility, third-party providers and retention.
Depending on the areas used, Oprivia may process stay, contact, identity, task, role, record, communication and evaluation data. Details are defined in the applicable privacy notices and agreements.
Visibility depends on role, organization, property, responsibility and specific case. Sensitive information should only be available to expressly authorized roles.
Personal data is processed for defined operational and contractual purposes. Purposes, categories, recipients, and access rights depend on the configuration, agreement, and privacy notices.
Retention and deletion depend on data type, purpose, agreement and legal requirements. Different data categories may be subject to different retention periods.
External providers may be used for hosting, identity verification, communication, analytics or integrations. Their use and any relevant data transfers are disclosed in the applicable documents.
Service boundaries
What Oprivia supports and where its scope ends.
No. Booking channels generate demand and transmit reservations. Oprivia is not a public booking marketplace. Where external channels remain in use, their fees continue to apply separately.
No. Oprivia is not an Airbnb manager, booking portal or channel manager. The platform supports workflows around preparation, stay, cleaning, partner coordination and closure.
A property management system typically manages reservations, availability, rates, units, and related administrative processes. By contrast, Oprivia structures the operational work that begins after a booking is confirmed, including guest data, service cases, housekeeping, service partner assignments, evidence, approvals, and escalations. Oprivia can complement an existing PMS or operate as a separate operational platform. Depending on the operating model, it can consolidate several point solutions and reduce the need for additional operational tools or extensive operational functionality within a PMS. However, Oprivia does not provide channel management, rate management, reservation management, or a booking engine.
No. Oprivia is not a payment service provider and does not receive customer funds in its own name. Whether payment requests, payment status, or billing information can be integrated through a third-party provider is subject to technical, contractual, and legal review. Until such functionality is expressly activated and agreed, payment processing remains outside Oprivia’s service scope.
No. Oprivia supports governance, access control, documentation, and auditability, but it does not replace case-specific legal, tax, data-protection, or regulatory advice. It does not guarantee legal compliance or any particular commercial outcome.
Next steps
Clarifying specific questions and operational requirements.
First, we clarify your operating model, property, current challenge, and desired level of support. We then agree on the scope and plan setup and onboarding for regular operations or an optional pilot.
No. An initial discussion is used first for orientation. You decide whether to deploy Oprivia Foundation directly, agree a pilot, or choose another starting point only after the scope has been clarified and you have received the written proposal.
Some questions require context
Briefly describe your current setup. We will clarify which information matters for your operation and which next step makes sense.