Key Journeys

Purpose: How the apps work together across a whole piece of business. The per-app pages describe features in isolation; these are the end-to-end threads that touch several apps at once.

Primary users: New starters building the big picture; anyone tracing where a tenancy "is" across the system.

Each step names the app in italics and notes where data syncs out.

Browsing & discovery

1. Land (Marketing websites): a prospect arrives on the operator's brand site (for Way of Life, wayoflife.com or a white-label site) from search, ads or referral, and their campaign attribution (UTM / gclid) is captured.
2. Browse (Marketing websites): they explore locations, buildings and apartments, or use search and filters. The availability and pricing shown are synced from Everest into the site's CMS, not live.
3. Hand off: choosing "Book a viewing" or "Reserve" carries the apartment's Everest reference into the booking forms, where the journeys below take over.

Booking a viewing

1. Advertise (Everest): a home is listed and published to the portals and the brand website.
2. Book (Public forms → Calendly): a prospect follows a "book a viewing" link into the booking app and picks a slot, which is booked in Calendly.
3. Confirm: Calendly sends the confirmation email (for video calls the agent sends the Zoom link). The prospect is captured as a lead in HubSpot with marketing attribution.

Letting a unit

1. Advertise (Everest): a unit is prepared and published to Rightmove, Zoopla, On The Market and the brand website.
2. View (Public forms → Calendly): a prospect books a viewing from the brand site. Not every let has one. The lead flows into HubSpot.
3. Reserve & pay the holding fee (Public forms → Portal): the prospect reserves the home; the booking app creates the reservation in Portal and hands off to a Portal payment link for the holding fee. The paid reservation then appears in Portal for staff.
4. Set up the tenancy (Portal): a deal sheet captures the tenancy detail. The customer is credit-checked and right-to-rent confirmed (referencing, via Rent Profile), and the deposit or a Reposit policy is arranged.
5. Approve (Portal → Qube): approving the deal syncs the customer, unit, deposit, monthly payments and tenancy documents into Qube. The unit is marked Let.
6. Move in (Portal): the deal appears on the Move-In tracker; the site team works the readiness checklist and issues smart-lock keys at check-in.
7. Live in (Tenancy API): the resident is onboarded to the app, where they see documents, pay rent and raise support.

Renewing a tenancy

1. Enter Rent Review (Portal): around 100 days before the anniversary the tenancy appears on the Renewals (Rent Review) tracker, and staff and resident are notified.
2. Negotiate (Portal): staff work the negotiation status, complete right-to-rent re-checks, and where applicable serve a Section 13 rent-increase notice (letter or Form 4A PDF) to the resident.
3. Respond (Tenancy API): the resident can view and respond to the Section 13 notice in the app; staff are notified of the response.
4. Outcome (Portal → Qube): agreeing creates a renewal deal sheet and syncs the new terms; declining or serving notice routes the tenancy into the Move-Out tracker.

Moving a resident out

1. Trigger (Portal): the tenancy enters the Move-Out tracker, either automatically from a "vacating"/"do not renew" renewal or when a resident gives notice in the app.
2. Work the checklist (Portal): the site team completes the building's move-out steps (keys, check-out report, dilapidations, deposit return, removal from building systems). Steps vary by building.
3. Complete (Portal → Qube): the move-out can only be cleared once the essentials (keys returned, deposit arranged) are done. Final charges and balances reconcile with Qube.

Paying rent

1. Charges (Qube → Portal → Tenancy API): charges originate in Qube and surface to the resident, grouped into due, overdue and paid.
2. One-off payment (Tenancy API): the resident pays in the app through the payment provider (SagePay); on success the matching transaction is raised in Qube and any related notification is cleared.
3. Recurring collection (Portal, direct debits): for direct-debit residents, collection runs on a Stripe subscription with its own invite, reminder and renewal emails.

Onboarding a new operator

1. Create the operator (Olympus Backend): a new company (operator/tenant) is created. This seeds its isolated database, including its Section 13 mail templates and reference data.
2. Configure (Olympus Frontend): admins set the operator's integrations, AI settings, mail templates and support configuration.
3. Use (all apps): staff sign in and are handed off from the launchpad into Portal, Everest and reporting for that operator.