Start where friction arises
Modules are the concrete operating blocks built on the platform logic: guest registration, mandatory details, service cases and partner services.
They do not replace the entire operating model at once. They isolate recurring bottlenecks, make them configurable and allow a controlled path from first use to later expansion.
Start small. Learn fast.
Not every module belongs in the first rollout. The decisive question is which area creates the strongest operational drag today and which entry point can produce usable insight quickly.
This creates a disciplined sequence: first the bottleneck, then the relevant module, then controlled expansion.
Prepare the stay
Guides required details and clarifications toward a clear registration status.
Secure mandatory details
Shows which details are missing, reviewable or marked for decision.
Turn requests into cases
Turns questions, incidents and additional needs into assigned cases with priority and status.
Coordinate handovers
Connects assignment, execution, feedback and acceptance in one continuous flow.
Registration without loose ends
This module guides guests through the defined registration steps and shows whether required details are open, complete or awaiting clarification.
Questions surface earlier, before they delay arrival, handover or internal preparation. Identity checks and specific regulatory requirements remain in the separate module intended for that purpose.
- Value: Capture required details before arrival or at the start of the stay.
- Typical cases: Invitation, data entry, clarification, correction and approval.
- Completion signal: A visible status for open, clarified and completed steps.
.avif)
.avif)
Mandatory details under control
Identity, contact and reporting details are assigned to the relevant stay and managed with a visible review status.
External identity or verification services are used only where technically available and agreed for the specific use case. Critical deviations remain assigned to a responsible person.
- Value: Collect purpose-bound details and make them reviewable.
- Typical cases: Required-field review, document request, clarification, approval or rejection.
- Review status: Relevant details are complete, open or marked for decision.
Requests become accountable cases
Questions, incidents and additional needs are captured, prioritised and assigned to a responsible role.
This keeps visible what has been received, what is being processed and where escalation, reassignment or decision is required.
- Value: Assign, track and resolve requests through a traceable path.
- Typical cases: Technical issue, additional need, clarification, handover and escalation.
- Documentation: Intake, status changes, reassignment and outcome remain
.avif)
.avif)
Partner services from assignment to acceptance
Cleaning, facility, maintenance and other service partners are guided from assignment to acceptance within one shared operating flow.
It remains clear what has been completed, where clarification or rework is required and when an assignment can be closed.
- Value: Plan recurring and case-based services reliably and keep acceptance reviewable.
- Typical cases: Cleaning, facility assignment, technical issue, repair, photo evidence, rework and acceptance.
- Assignment status: Assignment, execution, feedback, deviation and acceptance remain linked to the case.
Four steps.
One operating line.
Each module addresses a different bottleneck, but the operating pattern remains consistent: capture information, assign it to the relevant stay or task, process it with clear responsibility and preserve the outcome for review.
This allows Oprivia to start small without rebuilding the system logic later.
Capture
Information is recorded where it arises.
Assign
Each item is linked to a stay, property or assignment.
Process
Open points move through defined handling steps.
Review
Operational experience shows what should be adjusted, expanded or deliberately left out.
Which modules should come first?
The right starting point depends on the operating model, property structure, involved roles and current points of friction. A pilot can begin with one limited workflow and expand once the logic has been tested.