One case. Distinct roles.
Oprivia does more than list individual features. It creates the operating context beneath them: stay, property, role, work item, permission and history remain connected in one controlled structure.
Guests, hosts, operators and responsible teams no longer work through loose individual channels. Each participant works from the same case record and sees only the data, functions and next steps assigned to that role.
One workspace, not another channel
Booking platforms confirm availability, price and reservation. The work that follows is different: required details must be completed, exceptions clarified, cleaning coordinated and outcomes documented.
Without a shared operating logic, information scatters, responsibilities blur and time-critical issues become harder to control.
- Information without a common reference
- Open items without clear ownership
- Time-critical issues without a reliable record
Relevant views for every role
Every open item is tied to a clear reference, an accountable role and a documented outcome.
Context
Stay
A shared reference
Reservation, property and stay period define the reference for all subsequent work.
.avif)
Case
Case
Open work becomes assignable
Guests, accommodation teams, service partners and responsible roles see only what they need for their task.
Access
Access
Access follows responsibility
Clarifications, handovers and decisions remain connected, while visibility stays limited by role.
.avif)
Record
Record
Changes remain traceable
Updates, approvals and corrections are added to the record without overwriting what came before.
.avif)
One context. Relevant views.
All participants work from the same underlying case record. Which data, tasks and functions appear depends on the responsibility assigned to each role.
.avif)
Guest
Completes required details, reports issues and receives final feedback for the relevant stay.
.avif)
Host
Manages properties and open items, prioritises action points and coordinates internal or external execution.
.avif)
Operator
Handles assigned work, updates processing status and adds the required records.
.avif)
Governance
Reviews exceptions, supports escalations and records approvals as well as material decisions.
Access only where required
Role alone does not create unrestricted access. Organisation, property and the specific case record also determine which data and functions are available.
Guests see their own stay. Operators see assigned work. Hosts see the areas relevant to their properties or portfolio. Control and approval functions remain reserved for designated responsibilities.
Undefined permissions are denied by default. Execution, review and approval can therefore be separated organisationally and technically.
Access by role, organisation, property and case
Minimum information per task
Separation of execution, review and approval
Recorded actions and status changes
One architecture across modules
The platform keeps the operating logic intact: which data belongs to which stay, who may see which information, which action was triggered and how the processing status has changed.
Modules use this foundation without creating parallel structures of their own.
.avif)
Connected data model
Stay, property, person and case record remain distinct. They are linked through clear relationships instead of being merged into an opaque master record.
Information keeps its origin and purpose. It does not need to be recreated in each module.
.avif)
Access control by role and context
Each request is checked against role, organisation, property and case. A guest, host, operator and administrator receive different permissions.
Unassigned access is denied by default. Approval exists only within defined task and data boundaries.
.avif)
Continuous event log
Relevant actions are added as new entries to a continuous event record. Earlier entries remain preserved; corrections and later findings appear as additional events.
This keeps the original sequence distinguishable from later updates.
.avif)
Rules tailored to the use case
Status changes, time windows, reminders and escalations can be defined according to the agreed operating or pilot model.
The underlying architecture remains stable while rules are adjusted to the specific use case.
Website for context.
Platform for work.
The website explains product logic, modules, operating models and governance. Personal data and live operational cases are handled only inside the protected application on a separate platform domain.
Authorised users sign in with personal credentials. Available data and functions depend on role, organisation, property and assignment.
Access is activated step by step during development and pilot use for approved users only.
Turn scattered work into structure
Describe where information, responsibilities or time-critical issues currently drift apart. We will identify which platform components are suitable for a limited pilot.