Appearance
Portal: Customer & Property Management
Purpose: The operational heart of Olympus. Portal is where leasing and property-management teams run the full lettings lifecycle, holding a unit, making an offer, moving a resident in, renewing them, and moving them out.
Primary users: Way of Life leasing and property-management staff. Access is controlled by role, and most staff only see the buildings they manage.
See it live: sign in at the Olympus launchpad, olympustech.ai, then open Portal. See Accessing the systems.
Portal is the busiest and most feature-dense application in the ecosystem. Everything below hangs off one central record, the deal sheet, which holds a customer's full tenancy detail and is what every tracker works against.
Reservations
What it does: Places a hold on a unit for an applicant while their tenancy is set up. A reservation can be created, approved, declined, archived, and later restored. Approving a reservation is the step that turns interest into a deal sheet.
Who uses it: Leasing staff, at the point an applicant commits to a unit.
Key rules:
- Most reservations arrive from the public booking forms when a prospect reserves online; staff can also create them here.
- A unit can be held, and the hold removed, so it isn't double-let while an offer is in progress.
- Reservations sync to HubSpot so the sales pipeline stays in step with what's happening in Portal.
- "Store and send" creates the reservation and sends it to the applicant in one action.
Deal sheets
What it does: The deal sheet is the master record holding a customer's tenancy detail, rent, term, occupiers, deposit arrangement and more. It's the object every tracker later works against. Deal sheets can be created one at a time or imported in bulk, renewed, and terminated.
Who uses it: Leasing staff creating and managing offers.
For the full end-to-end process and edge cases, see the Deal sheet lifecycle playbook.
Key capabilities:
- Referencing: at this stage the customer is credit-checked and their right-to-rent status confirmed (through Rent Profile) before the tenancy proceeds.
- Create options: start a single deal sheet manually, or upload a spreadsheet to create many at once.
- Bulk CSV import: upload a spreadsheet of deals, map its columns to the right fields, and Olympus creates each deal sheet in the background, showing live progress and emailing a summary of successes and failures when it finishes. Useful when onboarding a whole building at once.
- Field mapper: the tool that matches spreadsheet columns to Olympus fields during a bulk import.
- Permitted occupiers: invite additional occupiers to a tenancy (giving them access to the resident app) or revoke that access.
- Contract variations: vary the terms of a tenancy on its deal sheet, adding, changing or removing a variation.
- Terminate tenancy: end a tenancy from the deal sheet, which feeds the Move-Out Tracker.
- Revisions & renewal: a deal sheet keeps a revision history, and can be renewed to create a linked new deal sheet for the next term.
- Download: produce a PDF of the deal sheet.
Integrations on the deal sheet:
- Reposit: create a deposit-replacement policy for the tenancy instead of a traditional cash deposit.
- Qube: review and push the tenancy's data (customer, unit, charges) into Way of Life's accounting system, and re-sync when something changes. This is what keeps Olympus and the finance system aligned.
- Inventory Hive: set up the check-in/check-out inventory for the unit and configure inspection reminders.
Qube charges & transactions
What it does: Beyond the initial sync, staff manage a tenancy's money in Qube from Portal: raising charges and transactions against the tenancy, adding and editing notes, and correcting tenancy information. This is the day-to-day link between Olympus and the finance system.
Who uses it: Finance and property-management staff with the relevant Qube permissions.
Detail: Qube sync playbook.
Key rules:
- Raising a transaction also raises a payment notification to the resident.
- Actions are permission-gated (submit to Qube, view or raise charges, raise transactions, manage notes), and a master switch can disable Qube writes across the platform.
Move-In Tracker
What it does: Automatically gathers every completed deal sheet with a move-in due soon, and gives the site team a readiness checklist per apartment, cleaning, keys and access, welcome pack, internet, induction, and so on. Staff tick items off as the apartment is prepared.
Who uses it: On-site building teams preparing apartments for new residents.
Key rules:
- A deal sheet appears automatically once it's complete, has synced to Qube, has an active tenant status, and the move-in date is within the next 30 days, no manual adding.
- Entries move through three stages: Current (active, editable), Past (manually set aside, still restorable), and Historic (older than 30 days, read-only archive). The move to Historic happens automatically each night.
- "All Developments" view lets a manager see move-ins across every building they manage in one table.
- Which checklist fields show up can vary by building, and buildings can add their own custom fields (see below) without a code change.
How it works, exact eligibility & stages
A deal sheet appears when all are true: status Complete, has a reservation, synced to Qube, tenant status not Previous or Withdrawn, and the move-in within 30 days. Stages run Current, then Past (set aside), then Historic, with a nightly job moving Past to Historic after 30 days. The full rules, including Renewals and Move-Out, are in the Tracker eligibility & stages playbook.
Renewals (Rent Review) Tracker
What it does: Surfaces tenancies approaching their anniversary so the team can manage the renewal, tracking negotiation status, inspections, right-to-rent re-checks, and (where applicable) serving a statutory Section 13 rent-increase notice. It's labelled Rent Review in the navigation.
Who uses it: Leasing / property-management staff handling renewals.
Key rules:
- A tenancy enters the tracker a configurable number of days before its anniversary, 100 days by default, adjustable per building.
- A negotiation status drives the workflow as staff progress the renewal (see Statuses & lifecycles for the exact values, which cover the increase-letter, Section 13 and notice steps).
- Agreeing the renewal moves the tenancy to Agreed successfully and creates a linked renewal deal sheet; a vacating outcome moves it to Vacated and automatically populates the Move-Out Tracker, prompting for a vacating reason.
- Some fields are building-specific, for example the Section 13 field currently shows only for The Kell.
Section 13 notices
What it does: Generates the official statutory rent-increase notice (Form 4A) as a filled-in PDF and sends it to the resident, straight from the Renewals Tracker. Staff can preview the letter and the PDF before sending, and download a copy afterwards.
Who uses it: Renewals staff at buildings that serve statutory notices.
Detail: Section 13 end-to-end playbook.
Key rules:
- The form is filled from the tenancy's own data, resident and occupier names, the building's landlord details and signature, current and proposed rent, and the relevant dates.
- The blank government Form 4A template is held centrally and can be swapped for an updated government version without a software release.
Move-Out Tracker
What it does: Manages the end-of-tenancy process with a per-building checklist covering everything that has to happen when a resident leaves, vacate confirmation, keys and access, check-out report, dilapidations and deductions, deposit return, and removal from building systems (parking, parcel lockers, utilities).
Who uses it: On-site building teams handling move-outs.
Detail: Move-out completion playbook.
Key rules:
- Unlike Move-In, entries are added deliberately, either automatically when a renewal is marked "Vacating"/"Do not renew", or manually by staff, not auto-gathered.
- The checklist is building-specific: each development shows only the steps relevant to it (e.g. ANPR parking removal at The Lansdowne, Evinox utility sign-off at The Sessile and The Gessner).
- A tenancy can only be cleared from the tracker once the essential steps are done, in particular keys returned and deposit arranged, enforced by the system.
Viewings
What it does: A calendar and workflow for property viewings, scheduling, reassigning the unit or applicant, and marking outcomes (attended, not attended, completed, or opportunity lost). Prospects book viewings through the public booking forms (via Calendly); staff manage them from here.
Who uses it: Leasing staff arranging and recording viewings.
Customers
What it does: A record of residents and applicants, with their associated deal sheets. Staff can send a resident a temporary password to access the app, and re-sync a customer's tenancies from the accounting system. A Single Customer View pulls a customer's full picture together on one screen, their tenancies, deal sheets and contact detail.
Who uses it: Leasing and support staff.
Customer support submissions
What it does: Handles support requests raised by residents, letting staff view a submission and reply to it.
Who uses it: Support and building staff responding to residents.
Direct debits
What it does: Collects recurring rent by direct debit. Staff see each tenancy's direct-debit subscription and status, send invites and reminders, and cancel or refresh a subscription. It's a separate area from the one-off payments a resident makes in the app.
Who uses it: Finance and property-management staff.
Key rules:
- Recurring collection runs on Stripe subscriptions; residents get invite, reminder, ending and renewal emails through the cycle.
- A resident can be opted in or out, and their direct-debit status shows against the tenancy.
Documents
What it does: A document manager tied to deal sheets and customers, organised in folders, with upload, rename and delete, and a "send customer link" action that shares a document with a resident.
Who uses it: Leasing and support staff.
Invite a resident
What it does: Invites a customer to the resident app and manages that onboarding, including resending an invite that hasn't been actioned.
Who uses it: Leasing and support staff, once a tenancy is ready for the resident to go live.
Custom fields
What it does: Lets a building add its own extra data fields to a tracker, a dropdown, checkbox, date, number or text field, without any development work. The field then appears as a column for the buildings it's assigned to.
Who uses it: Administrators configuring a building's tracker in Settings.
Key rules:
- Fields are assigned per building, so they only appear where they're relevant.
- Fields can be archived and restored; archiving hides the field without losing existing data.
Per-property support configuration
What it does: Sets how residents at a building get support: a support email, a HubSpot form, an in-app rating, or a redirect to a maintenance page. It's the building-level counterpart to the operator-wide support settings in Olympus Frontend.
Who uses it: Administrators, per building.
Guarantor providers (Renters' Reform)
What it does: Manages the list of approved guarantor providers used during referencing, and lets staff turn each one on or off. Introduced to support Renters' Reform requirements.
Who uses it: Administrators.
Smart locks & access control
What it does: For buildings fitted with smart locks, Portal manages digital keys and door access from one place: issuing a resident their key at check-in and revoking it at check-out, handling guests and visitors, managing communal doors, and encoding physical access cards at the concierge desk.
Who uses it: On-site concierge and site teams at buildings with smart locks.
Key capabilities:
- Check-in / check-out: issue a resident's key against their deal sheet when they move in, and revoke it when they leave.
- Guest & visitor keys: grant access to a resident's guests, and register, view and check out building visitors.
- Lost or frozen keys: mark a resident's key lost, or freeze it, for a given customer and unit.
- Public zones: manage access to communal areas and doors, including a bulk import of zones.
- Physical cards: read and blank access cards at the concierge desk via the smart-lock card reader.
Key rules:
- The module is scoped per building; only buildings fitted with smart locks and with concierge access see it.
- A user who manages a single building is taken straight to that building's dashboard.
Notifications to residents
What it does: Sends push notifications to residents' phones when something relevant happens on their tenancy, a payment is due, a new document is available, or a general message.
Who uses it: Triggered by the system on the resident's behalf; not a manual send.
Key rules:
- Delivered via Firebase to the resident's registered devices.
- Notifications are held in a safe "dry-run" mode by default in every environment except production, so testing never sends real messages to residents.
Search
What it does: Fast search across units and properties, powered by Meilisearch, so staff can jump straight to a unit or building.
Feature flags & UI toggles
What it does: Behind-the-scenes switches, with no admin screen of their own. The development team uses them to release features gradually or turn one off if there's a problem. Separately, some redesigned screens offer users a "switch to new/old version" toggle.
Who uses it: The development team, plus any user who sees an old/new version banner on a screen.
Integrations used by Portal
Portal is the most integration-heavy app. In summary:
| System | What it's used for |
|---|---|
| Calendly | Viewing bookings (webhook-driven) |
| Fixflo | Repairs and maintenance reporting (via webhooks) |
| Firebase | Delivering push notifications to residents |
| HubSpot | Keeping the sales pipeline aligned with reservations and deals |
| Inventory Hive | Check-in/check-out inventories and inspection reminders |
| Meilisearch | Powering unit and property search |
| Qube | Syncing tenancies, customers, charges and payments to the operator's accounting system |
| Rent Profile | Referencing: credit and right-to-rent checks, tenancy status |
| Reposit | Deposit-replacement policies |
| Smart locks | Digital keys and door access for buildings fitted with smart locks |
| Stripe | Recurring rent collection by direct debit |
See the Integrations Index for what each system is and how data flows.
Related documentation
(existing detail, link out rather than duplicate)
- Tracker System Architecture, the deep technical reference for how trackers share a common structure
- WOLRMO-109-117, Rent Review / Move-Out UAT test plan
- Move-In Tracker Improvements, UAT test plan
- Permitted Occupiers & Occupier App Access, UAT test plan
- Deal Sheet Uploads, UAT test plan
- Professional Rent Guarantor, UAT test plan
- Dynamic Section 13 Agent Details, UAT test plan