# Documentation (/docs) Welcome to the OmniPM documentation. This site is being built. The navigation is being filled in section by section; pages marked as drafts are summaries, not finished guides. ## Where to start ## For AI assistants Every page is available as plain Markdown — append `.md` to any URL, or send `Accept: text/markdown`. There is an index at [`/llms.txt`](/llms.txt) and the full corpus at [`/llms-full.txt`](/llms-full.txt). # Authentication (/docs/api/authentication) Every request carries a bearer token: ```http GET /api/agent/site/units Authorization: Bearer ``` A missing or malformed `Authorization` header is a `401`, as is a key that does not resolve. ## Keys belong to a workspace A key is issued **for one workspace** and resolves to it. Every query the request makes is scoped to that workspace before it runs — not filtered afterwards. There is no combination of key and parameter that returns another workspace's data. Keys are stored hashed, never in plaintext, and compared in constant time. That means: - **You cannot recover a key after issue.** If it is lost, revoke it and issue a new one. - **A key can be revoked immediately**, without affecting any other key. ## Scopes A key carries an explicit list of scopes, and a request is rejected with `403` if the route's required scope is not among them. | Scope | Grants | | ------------------------- | --------------------------------------------------------------- | | `properties:read` | Buildings, units, availability. | | `content:read` | Blog posts, campaigns, positions, services, site configuration. | | `residents:read` | Resident records. | | `showings:read` | Scheduled viewings. | | `inquiries:write` | Submit an enquiry. | | `leads:write` | Submit a lead, including a résumé upload. | | `analytics:write` | Send page-view and event telemetry. | | `chat:invoke` | Invoke the site assistant. **Cost-bearing.** | | `check-in-links:write` | Create a guest check-in link. | | `reservation-links:write` | Create a reservation link. | | `purchases:write` | Accept a supplier order. | | `ota:ingest` | Relay in OTA guest messages. | **Scope your keys narrowly, and issue several rather than one.** A public website is normally provisioned as three separate keys — read, actions and telemetry — so that a burst of one traffic class cannot exhaust the budget of another, and so a key embedded in a page cannot read residents. A key that can read listings cannot read residents. That is the point of the split, and it is worth preserving when you provision. ## Rate limits Requests are counted **per key**, not per IP, with a default budget of 300 per hour. A key can be given its own budget where a first-party sync tool legitimately bursts. Exceeding the budget returns `429`. Back off and retry; the window is rolling. Because limits are per key, one integration cannot exhaust another's allowance — another reason to issue separate keys rather than sharing one. ## What the API is for This is a deliberately small, mostly read-oriented surface: enough to drive a public website, feed an external assistant, and accept orders from a supplier. **It is not a general-purpose interface onto the whole product**, and it is not how you would build a second dashboard. There is no OpenAPI document yet, so these pages are written by hand and can drift from the implementation. Treat a live response as authoritative over a sample here, and report anything that disagrees. See also [Errors](/docs/api/errors). # Errors (/docs/api/errors) Errors return a JSON body with a single `error` field carrying a human-readable message: ```json { "error": "A building with this slug already exists" } ``` The **status code** is the part to branch on. The message is for a human reading a log, and its wording can change. ## Status codes | Code | Meaning | Retry? | | ----- | -------------------------------------------------------------------------------- | ------------------------------------------------------- | | `400` | The request was understood and rejected — a validation or business-rule failure. | **No.** Fix the request. | | `401` | Missing, malformed or unrecognised bearer token. | **No.** See [Authentication](/docs/api/authentication). | | `403` | The key is valid but lacks the scope this route requires. | **No.** Issue a key with the right scope. | | `404` | No such record, or not visible to this key's workspace. | **No.** | | `409` | Conflicts with something that already exists — a unique field collision. | **No**, not unchanged. | | `429` | Rate limit exceeded for this key. | **Yes**, after backing off. | | `500` | Something failed on our side. | **Yes**, with backoff. | ## The two that are commonly misread **`404` does not always mean "does not exist".** A record belonging to another workspace is a `404`, not a `403` — the API does not confirm the existence of data your key cannot see. So a `404` for an id you are certain about usually means the key belongs to a different workspace than you assumed. **`403` is about the key, not the record.** It means this key's scopes do not include what the route requires. The record may be perfectly readable with a different key. ## Retrying Only `429` and `5xx` are worth retrying. Everything else will fail again identically, and retrying it just consumes your rate budget. For `429`, back off before retrying — the window is rolling, so an immediate retry is likely to fail again and push the reset further out. Budgets are per key, so a well-behaved integration is not affected by a noisy neighbour. Retry **writes** carefully. `inquiries:write`, `leads:write`, `check-in-links:write`, `reservation-links:write` and `purchases:write` are not idempotent: a retried request that actually succeeded the first time creates a second record. On an ambiguous failure — a timeout, a dropped connection — reconcile before retrying rather than retrying blind. ## Validation failures A `400` names what was wrong in its message. Common causes: - A required field missing or the wrong type. - A value outside an allowed set. - A business rule refusing the operation — for example a date that conflicts with an existing booking. These are `400`, not `409`, because nothing *collided*; the request was simply not allowed. A `409` is narrower: something with that unique value already exists. Changing the conflicting field and resending is the fix. See also [Authentication](/docs/api/authentication). # API reference (/docs/api) OmniPM exposes a deliberately small HTTP API — enough to drive a public website, feed an external assistant, and accept orders from a supplier. It is not a general-purpose interface onto the whole product. Every request carries a bearer token. Tokens are per-workspace and **scoped**, so a key that can read listings cannot read residents. There is no OpenAPI document yet, so these pages are written by hand and can drift from the implementation. Treat a live response as authoritative over a sample here, and report anything that disagrees. # Properties (/docs/api/properties) ```http GET /api/agent/properties Authorization: Bearer ``` Requires the `properties:read` scope. Returns units from **your workspace's** catalogue only. ## Filters All optional, all query-string parameters. | Parameter | Type | Notes | | ---------------------- | -------------------------------------------------------- | -------------------------------------------------------------------- | | `area` / `areas` | string | One area, or a comma-separated list. | | `priceMin`, `priceMax` | integer | Whole yen, non-negative. A negative or non-numeric value is a `400`. | | `type` | `apartment` \| `sharehouse` | Anything else is rejected. | | `layout` / `layouts` | string | One layout, or a comma-separated list. | | `bedrooms` | integer | | | `moveInBy` | ISO date | Must parse as a date, or `400`. | | `availableNow` | `true` | Present and `true` to filter; anything else is ignored. | | `hasCampaign` | `true` | Same. | | `search` | string | Free text. | | `sort` | `price-asc` \| `price-desc` \| `size-asc` \| `size-desc` | | | `page`, `limit` | integer | See below. | The singular and plural forms are alternatives, not additions — `areas` takes precedence over `area` when both are sent. Send one. ## Pagination `limit` is **capped at 500**, deliberately higher than a human-facing page size: a first-party sync tool should be able to pull an entire catalogue in one request rather than making fifty and spending its rate budget on pagination. Ask for more than 500 and you get 500 — not an error. The response carries the total, so a client can decide whether to page at all. ## Availability in the response Alongside the matching units, the response distinguishes **confirmed** from **possible** availability. A "possibly available" unit is one where a resident has *mentioned* they intend to leave, without filing notice. It is a lead, not a fact — the date can move or never happen. Do not present it to a prospective resident as a date they can move in on. See [Availability](/docs/concepts/availability). ## The site endpoints For driving a public website there is a parallel set under `/api/agent/site/*` — units, buildings, blog posts, campaigns, positions, services, sitemap data and site configuration. They return presentation-shaped payloads with public URLs already built, rather than raw catalogue records. Those endpoints use `content:read` for editorial content and `properties:read` for listings, which is why a website is normally provisioned with a read key covering both. See [Authentication](/docs/api/authentication). ## Related - [Residents](/docs/api/residents) - [Errors](/docs/api/errors) - [Availability](/docs/concepts/availability) — what the states mean # Residents (/docs/api/residents) ```http GET /api/agent/residents GET /api/agent/residents/{id} Authorization: Bearer ``` Requires the `residents:read` scope. This endpoint returns **personal data about real people**. Give the scope only to integrations that genuinely need it, and never to a key embedded in a public website. A listings key and a residents key should be two different keys — see [Authentication](/docs/api/authentication). ## Filters | Parameter | Type | Notes | | --------------- | -------------------------------------------------------------------------------- | ---------------------------------------------- | | `building` | string | | | `unit` | string | | | `email` | string | Exact match on the address held on the record. | | `search` | string | Free text. | | `paymentStatus` | `pending` \| `paid` \| `refunded` \| `cancelled` \| `failed` | | | `signNowStatus` | `pending` \| `sent` \| `partially_signed` \| `signed` \| `declined` \| `expired` | Contract signature progress. | | `page`, `limit` | integer | `limit` is **capped at 50**. | An unrecognised value for either status parameter is rejected rather than ignored, so a typo fails loudly instead of silently widening your query. ## Response ```json { "ok": true, "data": { "residents": [ ... ], "pagination": { "page": 1, "limit": 50, "total": 128, "totalPages": 3 } } } ``` The `limit` cap of 50 is much lower than the catalogue's 500. That is deliberate: bulk-exporting personal data should be a conscious, paginated act, not a single convenient request. ## A resident *is* a reservation There is no separate "resident" entity. A resident record is the tenancy — the contract, the pricing, the ledger and the departure all hang off it. Someone who has lived in two units has **two** records, correctly, because they had two tenancies. This matters when you match on `email`: one address can legitimately return several records, including ended ones. See [The tenancy lifecycle](/docs/concepts/the-tenancy-lifecycle). ## Not in this API Money movement, invoices and ledger entries are **not** exposed here. The API is read-oriented and narrow by design; billing is not a surface an external integration should be driving. See [The ledger](/docs/concepts/the-ledger) for what those records look like inside the product. ## Related - [Properties](/docs/api/properties) - [Errors](/docs/api/errors) — in particular, why a `404` may mean "not yours" # Webhooks (/docs/api/webhooks) **There are no outbound webhooks.** OmniPM does not currently POST events to a URL you register. If you need to know when something changes, poll — see [Watching for changes](#watching-for-changes) below. Everything on this page is **inbound**: an external service, or your own integration, pushing data *into* the platform. ## How inbound endpoints authenticate Two different mechanisms, and which one applies depends on who is calling. ### Provider webhooks: signature verification Endpoints that receive events from a third-party provider — payments, e-signature, messaging channels — verify the provider's own **signature** over the raw request body, against the secret held for **that workspace**. Messaging endpoints are addressed per workspace, so the URL identifies whose credentials to verify against: ``` POST /api/webhooks/line/{workspace} POST /api/webhooks/whatsapp/{workspace} ``` You configure these URLs in the provider's own console when connecting the channel. A request whose signature does not verify against that workspace's secret is rejected — a valid signature for a *different* workspace is not accepted. Signature verification is over the **raw bytes** of the body. If something sits between the provider and the platform and re-serialises JSON — a proxy, a middleware, a logging layer — verification fails even though the payload looks identical. This is the usual cause of a webhook that works in testing and fails in production. ### Your own integration: a scoped bearer token Where *you* are the one pushing data in, the endpoint uses the same bearer-token auth as the rest of this API rather than a signature. The relayed-OTA-message endpoint works this way: ```http POST /api/webhooks/ota-messages Authorization: Bearer ``` **The key names the workspace.** That is the whole point of using a token here: ingest runs scoped to the workspace that owns the key, rather than inferring an owner from the payload — which would be a guess, and a guess that puts one workspace's guest messages in another's inbox. `ota:ingest` is one of the scopes the legacy shared key is explicitly denied. See [Authentication](/docs/api/authentication). ## Watching for changes Until an outbound event feed exists, poll the read endpoints: - **Poll on a sensible interval**, not continuously. Budgets are per key and default to 300 requests an hour — see [Errors](/docs/api/errors) for the `429` behaviour. - **Pull wide, not often.** [Properties](/docs/api/properties) allows up to 500 records per request precisely so a sync can take the whole catalogue in one call rather than spending its budget on pagination. - **Use a dedicated key** for the sync, so its polling cannot exhaust the budget of an interactive integration. ## Delivery expectations For provider webhooks, assume **at-least-once** delivery: a provider may retry, and the same event can arrive twice. Handlers on this side are written to tolerate that, but if you are building something that consumes the effects, do not assume exactly-once. Related: [Authentication](/docs/api/authentication), [Errors](/docs/api/errors). # Getting started (/docs/getting-started) OmniPM runs a property-management business end to end: the catalogue of buildings and units, the reservations that fill them, the money those reservations generate, and the cleaning and maintenance that keep them habitable. It is used by five different kinds of people, each through their own portal, and each seeing only what their role needs. # Signing in (/docs/getting-started/signing-in) There is no single login. Each portal uses the method that suits how and where its people work. | Portal | How you sign in | | --------------- | ----------------------------------------------------------------------------------------------------------- | | Dashboard | Email and password, or a 6-digit PIN sent to your email. A forgotten password is reset from the login page. | | Resident portal | Email, then a 6-digit code — no password to remember or leak. | | Owner portal | Email, then a 6-digit code. Only registered owners can get in. | | Contractor | No sign-in. The job link itself is the credential — which is exactly why it can be revoked. | The resident, owner and dashboard sign-in pages open with the same **Resident · Owner · Staff** switch, so anyone who lands on the wrong one is one tap from the right one. A company's own website can link to these pages with its name; they then show that company's logo and a link back to its website. ## Emailed codes expire quickly The code a resident or an owner receives is deliberately short-lived: it expires after 10 minutes. It works only on the screen where it was requested, and once a new one is sent, only the newest works there. This is the source of most "the code doesn't work" reports, and the answer is almost always the same: it was requested a while ago, an older code was typed after a newer one was sent, or it was typed on a different screen from the one that asked for it. Send a new one. Too many requests in a short time are slowed down: the screen asks them to wait and try again. Once in, a session lasts about a week before it has to be renewed. A code is not a way to share a portal. A resident whose partner also needs access should not pass codes along: register the second person as a co-occupant instead. ## The dashboard Email and password, or a 6-digit PIN sent to your email: choose **Sign in with email PIN** on the login page. Every dashboard account can use either, office staff and field staff alike. **Forgot your password?** Choose **Forgot password?** on the login page, type your email, and enter the PIN we send you together with a new password. You are signed in straight away. A workspace administrator can still set a staff member's password under [Settings](/docs/platform/settings). Because a PIN arrives by email, whoever can read an account's inbox can get into that account. Keep that email account secure. Housekeepers and maintenance staff sign in at the same dashboard, narrowed to their role. Their accounts have no shared starting password: the first time in is with a one-time code emailed to them, after which they set their own password under the lock icon at the top of the screen — and can change it the same way later. When someone leaves, their coordinator switches the account off and it stops working immediately. Which screens an account can then reach depends on its **role**, not on where it signed in. See [Roles and portals](/docs/concepts/roles-and-portals). ## Contractors Contractors get no account at all. A share link for one maintenance project is the whole credential. Because the link *is* the credential, anyone holding it has the access it grants — and that includes the building handbook, entrance codes and WiFi. Set an expiry, and revoke it when the job is done. See [The maintenance model](/docs/concepts/the-maintenance-model). ## Guests Short-stay guests never sign in. They arrive through a tokenised check-in link, complete registration and read the handbook for their stay. The token is the access, and it is scoped to that one booking. ## When someone cannot get in 1. **Are they using the right portal?** A resident trying the dashboard login will never succeed — the account does not exist there. The switch at the top of every sign-in page takes them to the right one. See [Who uses it](/docs/getting-started/who-uses-it). 2. **Is the code stale, or an older one?** Send a new one, and use the newest. 3. **Is the email the one on the record?** Sign-in matches the address held on the reservation or owner record, not any address the person also owns. 4. **For owners:** they must be registered. An unregistered owner gets no code, because there is nowhere to send it. # Who uses it (/docs/getting-started/who-uses-it) There are four separate surfaces, and they are genuinely separate — a resident cannot see the dashboard, and a housekeeper signed into the dashboard sees only their own work. | Portal | Who | What they do there | | ------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Dashboard** | Operators and office staff, including housekeeping and maintenance staff | Everything, narrowed by role: catalogue, reservations, rent, move-outs, cleaning, maintenance, messaging, analytics — a field-staff account sees only its own cleaning events, errands and maintenance jobs | | **Resident portal** | People living in a unit, and applicants | Review and sign a contract, pay rent, register guests, report problems, give notice | | **Owner portal** | Building owners | Monthly statements, who is in their units, occupancy | | **Contractor link** | External contractors | One job, through an unguessable link, with no account at all | A fifth surface is not a portal: **guests** on short stays check in through a tokenised link and read a handbook, without ever signing in. ## The dashboard Where the business is run. Everything else in this documentation's [platform guide](/docs/platform/getting-started) describes a dashboard screen. Staff **roles narrow the dashboard rather than opening a different one.** A housekeeper-role account signing into the dashboard is redirected to their own cleaning events and timesheets and cannot reach any money page. See [Roles and portals](/docs/concepts/roles-and-portals). ## The resident portal A resident's whole relationship with the tenancy: the contract to review and sign, rent to pay, receipts, registering an overnight guest, reporting a problem, and filing a move-out notice. Applicants use it before they are residents — the contract review step happens here, before anyone has moved in. **A resident sees their own tenancy and nothing else.** Not the building's other residents, not their charges, not their contact details. That boundary is the main reason the portal exists as its own surface rather than as a filtered view of the dashboard. ## The owner portal Owners see their own buildings: monthly statements, occupancy, and who is in their units. **They do not see resident contact details.** An owner asking why they cannot message a resident directly is hitting a deliberate boundary, not a gap — the operator sits between the two on purpose. An owner who also *lives* in one of their units is a different thing again: they occupy it, but it is not an ordinary tenancy. See [Availability](/docs/concepts/availability). ## Housekeeping and maintenance staff Cleaning and maintenance staff sign in at the same dashboard as everyone else, narrowed to their role: today's cleaning events, the room checks to complete, errands, and (for maintenance staff) their maintenance jobs and the hours worked. They cannot reach other staff's data or any money page. ## Contractor links An external contractor gets no account. They receive a link to one maintenance project, which is writable: they can log hours, add a purchase, and move tasks along. That link also exposes the **building handbook**, including entrance codes and WiFi. Treat it as a building credential, not a task credential. See [The maintenance model](/docs/concepts/the-maintenance-model). ## Which one do you want? - **"I need to check a resident's rent"** → dashboard. - **"I need to pay my rent"** → resident portal. - **"How full was my building last month?"** → owner portal. - **"Which rooms am I cleaning today?"** → dashboard → Cleaning events. - **"I have been asked to fix a boiler"** → the link you were sent; there is nothing to sign into. See [Signing in](/docs/getting-started/signing-in) for how each one lets you in. # Changelog (/docs/changelog) Notable product changes, newest first. This page starts from the point these docs went live. It is not a backfilled history, and pretending otherwise would make it less trustworthy rather than more complete. ## September 2026 ### Help buttons on every admin screen — 14 Sep A **Help** icon now sits in the dashboard's top bar on every screen, opening this manual at the page for whatever you are looking at. It follows the current tab too, so Help on Rent Roll's Profit & Loss tab opens the money chapter rather than the general one. See [Getting started](/docs/platform/getting-started). Internally this is backed by a coverage check: a new admin screen cannot ship without a documentation page, or an explicit, reasoned exemption. ### Your workspace, your messaging accounts — 13 Sep Messaging channels are now **per workspace**. Each workspace connects its own accounts — LINE, WhatsApp and the OTA channels — rather than sharing a single set, and inbound messages are verified against that workspace's own secret. AI reply drafting in the [Inbox](/docs/platform/inbox) became per-workspace at the same time, so a draft is written with your own configuration and tone rather than a shared one. ### Your workspace, your accounting connection — 12 Sep Each workspace now connects its **own** accounting account, instead of the integration being configured once for everyone. See [IoT Monitoring & Freee Accounting](/docs/platform/iot-and-accounting). ### Photos and documents open in place — 12 Sep Attachments across the dashboard, the resident portal and the staff surfaces now open in an **in-app viewer** rather than a new browser tab. Thumbnails that previously did nothing when clicked are now clickable everywhere. ### Reference numbers restart per workspace — 12 Sep Numbered records are numbered **within your workspace**, so two workspaces no longer interleave in one shared sequence. Existing numbers are unchanged. ### Payment fixes worth knowing about — 12 Sep Two defects were corrected in how externally-collected payments are reconciled: - A rent payment collected by the payment processor could be missed when the matching record was archived. It no longer is. - A booking deposit the processor may already have collected is no longer archived without checking with the processor first. If you have historically worked around either of these by hand, you can stop. ### Deposit forfeiture removed from the move-out form — 12 Sep The resident move-out form no longer warns about deposit forfeiture. The mechanism was retired: **every move-out penalty is a payable charge**, netted against the deposit only if it is still unpaid at settlement. See [Move-out penalties](/docs/concepts/move-out-penalties). ### The staff assistant reads this site — 12 Sep The knowledge base behind the dashboard's AI assistant is now sourced from this documentation. An edit to the platform guide changes what the assistant tells staff, usually within a day. See [AI Chat & Staff Knowledge Base](/docs/platform/assistant). ### Contractor share links reachable again — 12 Sep A routing fault made contractor share links and the inventory board return "not found". Both work again. See [The maintenance model](/docs/concepts/the-maintenance-model). # Help centre (/docs/help) Guides for the people who use OmniPM without running it. Looking for how to *run* the business rather than use it? That is the [platform guide](/docs/platform/getting-started). # Availability (/docs/concepts/availability) A unit's availability is **derived** from the reservations against it. There is no "available" switch to flip. Change a move-out date and availability moves with it; cancel a booking and the room frees itself. That is deliberate: a manually-set flag is a second source of truth, and the moment it disagrees with the bookings, one of them is lying and nobody can tell which. ## The states | State | Meaning | | ---------------------------------- | ---------------------------------------------------- | | **Available now** | Bookable today. | | **Available from *date*** | Confirmed free from a known date — a filed move-out. | | **Reserved** | Someone has it, or has it from a date. | | **Possibly available from *date*** | Soft, and the important one — see below. | | **Occupied** | In use, with no known end. | A confirmed date that has already passed reads as **available now**, not as a stale future date. ## Confirmed versus possible **Confirmed** means a move-out notice has been filed. It is a commitment: billing, settlement and the successor booking all key off it. **Possible** means a resident has told someone they intend to leave, without filing. It is recorded as an expected departure, and it does exactly one thing — advertises the unit as *possibly* available from that date, for waitlist purposes. An expected departure is **never read by billing or occupancy**. It cannot free a room, cannot end a tenancy, and cannot be relied on for a start date you promise a new resident. It is a lead, not a fact. It clears itself automatically once a real notice is filed. ## External occupancy Some units are blocked by things that are not reservations in this system — an imported rent roll, a channel calendar, an owner using their own unit. Those blocks are real, and the availability view shows them. **External blocks must never be fed to the double-booking detector.** They are not reservations and they do not carry the same identity, so treating them as such produces phantom conflicts on rooms that are perfectly fine — and the noise trains people to ignore the detector, which is worse than not having one. ## Owner residents An owner living in their own unit occupies it, but is not a normal tenancy: no refundable deposit, no ordinary rent roll treatment. Availability views can be filtered to exclude them. Two things about that filter behave in a way worth knowing: - **Absent means excluded.** With no filter specified, owner residents are left out. That is the default because it is the common case. - **Explicitly clearing the filter** is a distinct state from not setting it — it means "exclude nobody", and it is how you deliberately see everything. ## Degrading safely Availability labels render on every public property card. A single corrupt date — the kind an external rent-roll sync can introduce — falls back to the plain no-date label rather than breaking the page. If a unit shows "Occupied" with no date where you expected one, a bad source date is worth ruling out. See also [Contract dates](/docs/concepts/contract-dates), [The tenancy lifecycle](/docs/concepts/the-tenancy-lifecycle) and the [Rent Roll](/docs/platform/rent-roll) chapter for the availability grid itself. # Contract dates (/docs/concepts/contract-dates) A tenancy carries several dates that are easy to conflate and that drive different things. Getting the wrong one is the most common cause of an invoice that looks inexplicable. | Date | What it is | What it drives | | ------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Move-in date** | Contract start. | Billing, occupancy, the contract itself. | | **Override move-in date** | A corrected contract start. | **Everything the move-in date drives.** It replaces it. | | **Arrival date** | When the resident physically turns up, if that differs. | The condition-report window and its reminders, the calendar event, admin display. **Never billing.** | | **Contract end date** | When the agreed term finishes. | Notice period, penalties, when month-to-month begins. | | **Move-out date** | When they actually leave. | The final month's proration, settlement. | ## Override move-in date is financial The override move-in date is not a display convenience. Wherever the system asks "when did this tenancy start?", the answer is **the override if one is set, otherwise the move-in date**. Changing it changes what is billed. Treat it like editing an amount, because that is what it does. ## Arrival date is not financial The opposite is true of the arrival date. A resident whose contract starts on the 1st but who physically lands on the 20th still owes rent from the 1st — the room was theirs. What the arrival date does change is the **move-in condition report**: someone who walks in three weeks late must document the room they actually walked into, not the room as it was on the contract start. So the report window and its two reminder emails anchor on arrival. Billing, occupancy and the e-signature flow never read it. ## The move-in invoice is not one month This surprises people regularly, and it is deliberate. **A resident moving in after the 15th gets a move-in invoice that bundles two periods**: the partial move-in month *and* the whole month after it. Regular monthly rent then starts a month later than you might expect. So for such a resident: - There is **no separate rent entry** for the move-in month, or the one after it. - The first ordinary rent entry appears in the *third* month. - A recurring discount applies across **both** bundled periods. Reading only the move-in month understates a mid-month campaign discount by its entire second slice. Before concluding that a resident's early months are under-billed, check what the move-in invoice actually covered. A missing rent row in month two is usually the invoice having already collected it. ## Contract end, and what comes after The contract end date decides the notice period and whether leaving counts as an early exit. It does **not** end the tenancy on its own — a resident who stays rolls into [month to month](/docs/concepts/month-to-month). There is an override for contract end too, and it behaves like the move-in override: it replaces the value everywhere. ## The rule of thumb **Never classify a month by doing arithmetic on its amount.** "This is less than a full month, so it must be a proration" is wrong often enough to cause real billing errors — a short month can be a prorated final month, a prorated first month, a post-contract-end stub, or a month with a discount. Read the dates and the invoice coverage, not the number. See also [Proration](/docs/concepts/proration), [Pricing snapshots](/docs/concepts/pricing-snapshots) and [The tenancy lifecycle](/docs/concepts/the-tenancy-lifecycle). # Dates and currency (/docs/concepts/dates-and-currency) Two conventions run through everything, and both explain behaviour that looks odd until you know them. ## Dates are calendar days, in JST A move-in day, a contract end, a billing month boundary — these are **calendar day** concepts, not moments in time. They are anchored to **Japan Standard Time**, and JST has no daylight saving, so a day is always a day. What follows from that: - **A date has no time of day.** A move-out "on the 31st" means the whole of the 31st. There is no hour at which it takes effect. - **A date does not shift for the viewer.** Someone reading the dashboard from another country sees the same dates as someone in Tokyo. They are properties of the tenancy, not of the reader. - **Month boundaries are JST calendar boundaries.** This is why proration uses the real number of days in the month — see [Proration](/docs/concepts/proration). ### Timestamps are different Some values genuinely *are* moments: when an invoice was sent, when a payment landed, when someone was forced to month-to-month. Those are instants, recorded to the second, and they are audit trail rather than policy. The distinction matters when you compare two things. A filed-on timestamp and a move-out calendar day are different kinds of value, and "is the notice before the move-out?" needs the calendar day on both sides. Notice periods are counted in whole days for exactly this reason. ## Money is whole yen Every amount is a **whole number of yen**. There are no sub-yen fractions in the money path, and nothing is stored as a floating-point value. Consequences worth knowing: - **Rounding happens per line, not per total.** Each component of a prorated period is rounded on its own and the total is their sum. That is why an itemised prorated invoice can differ by a yen from the same month multiplied out on a calculator — and the itemised figure is the correct one, because it is what the resident is actually billed, line by line. See [The ledger](/docs/concepts/the-ledger). - **A one-yen discrepancy is usually arithmetic, not an error.** Before chasing it, check whether you are comparing a sum of rounded parts against a rounded whole. ### Where percentages live A few things are configured as percentages rather than amounts — a fee derived from a share of rent, for instance. The **percentage** is stored precisely; the **yen amount it produces** is rounded to a whole yen at the point it becomes a charge. So the rate is exact and the money is an integer, which is the right way round. ## Reading an amount anywhere Amounts display with a yen symbol and thousands separators. A figure shown without them in an export is the same number — formatting is presentation, and the stored value is the integer. Never enter an amount with decimals, and never paste a figure carrying a currency symbol into an amount field. Both are signs you are working from a formatted display rather than the underlying number, and the mismatch tends to surface later as a reconciliation problem rather than immediately as a validation error. See also [Proration](/docs/concepts/proration) and [Contract dates](/docs/concepts/contract-dates). # Deposits (/docs/concepts/deposits) A deposit is collected at booking and held for the length of the tenancy. It is **refundable** — it belongs to the resident until settlement decides otherwise. It is not revenue while it is held, and it is not a pot to bill against during the stay. A penalty is a **charge**, not a deposit deduction. It is billed to the resident and payable like anything else. If it is still unpaid at settlement it is netted off then — but until that moment it is a debt, not a deduction, and treating the two as interchangeable is how a resident ends up billed twice for one thing. ## The held balance At any moment the deposit balance is: **what was collected, minus what has already been settled or transferred away, adjusted for anything the resident still owes or has overpaid.** Three things feed that last part, and each is counted exactly once: - **Unpaid rent and charges** reduce the effective balance. - **Overpayments** increase it. - **An arrears charge that collects an earlier month's shortfall** neutralises that earlier month's own shortfall, so the same debt does not appear twice — once as the missed month and again as the charge chasing it. See [The ledger](/docs/concepts/the-ledger). The balance is always **computed from the ledger**, never stored as a field. A stored balance is a number that can quietly stop agreeing with the entries it was supposed to summarise. ## Who has one Not every occupant does. Rows imported from an external rent roll, owner residents, and short-stay guests booked through a check-in link are not residential deposit holders, and are deliberately excluded from deposit reporting. A large negative balance appearing against one of these is a classification problem, not a money problem. An onboarding resident whose move-in invoice is not yet paid is also excluded, so that a not-yet-arrived resident does not show as deeply in debt. ## Room changes and occupant changes When a resident moves to another room, or the occupancy of a reservation changes, the deposit **moves with them**. It is transferred onto the new reservation as a paper transfer: the old reservation's held deposit closes, the new one opens, and no cash moves. This matters when reading a balance. The old reservation showing no held deposit is correct — it was carried across, not refunded. The transfer is visible as its own ledger line on both sides. ## Settlement At move-out the deposit is settled: legitimate deductions are applied, anything the resident still owes is netted off, and the remainder is refunded. The move-out report is where that calculation is shown and agreed. See [Move-out penalties](/docs/concepts/move-out-penalties) for what may and may not be deducted. Settlement and refund are separate steps on purpose. A settled figure is the agreed number; the refund is the act of sending it. Only a reservation whose refund has actually been sent counts as refunded — a settlement concluding that nothing is owed back is a **zero refund**, not a sent one. ## Deposit forfeit **Forfeit is retired.** New move-out notices never forfeit a deposit; the value is always zero. The field and its historical display remain so that old records still read correctly, but it is not a lever to reach for. If a resident owes money at move-out, that is a **charge**, netted at settlement — which is the same answer as everywhere else on this page. See also [The ledger](/docs/concepts/the-ledger) and [The tenancy lifecycle](/docs/concepts/the-tenancy-lifecycle). # Glossary (/docs/concepts/glossary) Where a term has a page of its own, it is linked. Where two terms are commonly confused, the difference is spelled out rather than implied. ## Who and where | Term | Meaning | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Workspace** | One operator's world — branding, fees, contracts, integrations and data. Two workspaces can hold the same physical building as two separate records, correctly. | | **Building** | A property. Holds units. | | **Unit** | What someone rents. Either a room in a shared house or a whole home. | | **Resident** | Someone living in a unit for months. | | **Guest** | Someone staying nights, arriving through a check-in link, with no move-out notice. | | **Co-occupant** | Someone living with the resident, named on the contract but not the contract holder. | | **House leader** | A resident who helps run a building's shared areas. | | **Owner** | Whoever owns a building. May or may not be the operator. | | **Owner resident** | An owner living in their own unit. Occupies it, but is not an ordinary tenancy — no refundable deposit, and excluded from deposit reporting. | ## The tenancy | Term | Meaning | | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Reservation** | The tenancy record. Carries the contract, prices, ledger, documents and departure. A resident *is* a reservation. | | **[Move-in invoice](/docs/concepts/contract-dates)** | The single invoice collecting everything due before arrival. **Not always one month** — a move-in after the 15th bundles the next whole month too. | | **Contract start** | Drives billing and occupancy. | | **Arrival date** | When the resident physically turns up, if that differs from contract start. Drives the condition-report window, and **nothing financial**. | | **[Month to month](/docs/concepts/month-to-month)** | A tenancy continuing past its contract end with no notice filed. Still occupied. | | **Notice** | The resident's statement that they are leaving, with a date. Ends the tenancy. | | **Expected departure** | A resident *mentioning* they will leave, without filing. Advertises the unit as *possibly* available. Never read by billing or occupancy. | | **Room change** | Moving a resident between units. Carries the deposit across; not a move-out. | | **Amendment** | The new reservation a room or occupant change creates. | ## Money | Term | Meaning | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **[Ledger entry](/docs/concepts/the-ledger)** | One billable or payable event — a month's rent, an invoice, a charge, a purchase. | | **Line** | One item inside an entry, with its own amount, category and period. The entry's total is the sum of its lines. | | **Charge** | A one-off billed to a resident. **Payable** — not a deduction from anything. | | **[Deposit](/docs/concepts/deposits)** | Refundable, held for the tenancy, settled at the end. Never revenue while held. | | **[Settlement](/docs/concepts/deposits)** | Working out what is returned from the deposit after a departure. | | **No refund due** | A settled deposit where the amount sent was **zero**. A complete outcome, but **not** a refund. | | **[Penalty](/docs/concepts/move-out-penalties)** | An early-exit or short-notice cost. Always a charge, never a forfeit, and the two kinds never stack. | | **[Proration](/docs/concepts/proration)** | Billing a partial month by day ratio. Automatic at both ends of a tenancy. | | **[Pricing snapshot](/docs/concepts/pricing-snapshots)** | The price frozen onto a reservation at booking, so a later catalogue change cannot rewrite history. | | **[Fee catalogue](/docs/concepts/the-fee-catalogue)** | Your workspace's own definitions of what it charges. The authority for any amount. | | **Fee code** | A fee's stable identity. Survives relabelling. | | **Arrears charge** | A charge collecting an earlier month's shortfall. Excluded from revenue — that income was recognised in the original month. | ## Maintenance | Term | Meaning | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **[Request](/docs/concepts/the-maintenance-model)** | One report of one maintenance problem. The inbox you group *from*. | | **Project** | The maintenance job that one or more requests fold into. Numbered `PRJ-####`; gaps in the numbering are normal. | | **Visit** | One trip by one person to one building on one day, bundling tasks. | | **Share link** | A project handed to an outside contractor. Writable, and **exposes the building handbook** — treat it as a building credential. | | **Ticket** | The conversation with a resident about a problem. Distinct from the work. | ## Conventions | Term | Meaning | | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **[JST calendar day](/docs/concepts/dates-and-currency)** | How every date is anchored. A date has no time of day and does not shift for the viewer. | | **Whole yen** | How every amount is stored. Rounding happens per line, not per total. | | **[Role](/docs/concepts/roles-and-portals)** | Narrows what an account reaches inside the dashboard. Distinct from a portal, which is a different door entirely. | # Concepts (/docs/concepts) The handful of ideas that make the rest of OmniPM make sense. Read these once and most of the product stops being surprising. Three of them cause more confusion than everything else combined: # Month to month (/docs/concepts/month-to-month) A contract has an end date, but a tenancy does not have to stop there. When a resident stays on past their contract end without signing a new one, they are **month to month** — billed a full month at a time, open-ended, until a move-out notice is filed. There are two ways a reservation becomes month to month, and the difference matters. ## Derived: it happens on its own As a contract approaches its end with no move-out notice and no successor booking, the reservation is treated as month to month automatically. The window in which that happens mirrors the notice period: **30 days out for contracts longer than 30 days, 15 days for shorter ones.** Nothing needs to be clicked. This is the normal path, and it is why a resident who simply stays keeps being billed correctly. ## Manual: staff force it Staff can also force a reservation month to month explicitly. That overrides the derived logic entirely, on **every** surface: - Billing rolls open-ended full months. - The unit stays blocked indefinitely. - Successor bookings are rejected. It ignores both the contract-end window and the successor cutoff. Clearing it reverts to the derived behaviour. Manual month-to-month is honoured only for **live** tenancies. A filed move-out date, a minpaku booking, or a cancellation always wins over it. So forcing it does not resurrect a tenancy that has already ended. ## What gets billed A month-to-month month is a **full month**, not a prorated one. The tenancy is no longer running toward a known end date, so there is nothing to prorate against. Proration returns as soon as an actual end date exists — when a move-out notice is filed, the final month is prorated to that date. See [Proration](/docs/concepts/proration). ## The trap: a stub month and a later notice This is the one thing on this page worth reading twice. When a contract ends mid-month and the resident stays a few days before a notice is filed, those days may already have been billed as a short **stub** — a part-month rent row, correctly prorated at the time and quite possibly already paid. If a move-out date is later edited, the reconciliation that reprices rent rows has to decide what each existing row should now be. **A stub billed for a post-contract-end holdover looks very similar to an ordinary prorated final month**, and restoring it to a full month is wrong: it inflates a row the resident already settled correctly. If a move-out date change offers to "restore" a short month to a full one, stop and check whether that month was a post-contract-end stub. Restoring a paid stub bills the resident for days they never owed, and because the row was already paid it surfaces as an unexplained balance rather than as an obvious error. ## Reading a month-to-month reservation - **No contract end in the future** is expected, not missing data. - **A full-month rent row after the contract end date** is correct. - **A short row spanning the contract end** is the stub described above — leave it alone unless you are certain. See also [Contract dates](/docs/concepts/contract-dates), [Move-out penalties](/docs/concepts/move-out-penalties) and [The tenancy lifecycle](/docs/concepts/the-tenancy-lifecycle). # Move-out penalties (/docs/concepts/move-out-penalties) Leaving can attract a penalty in two situations, and they are different things: - **Early exit** — the resident leaves strictly *before* their contract end date. - **Short notice** — the resident gave less warning than the notice period requires. **Every move-out penalty is a payable charge, never a deposit forfeit.** It is billed to the resident like any other charge. If it is still unpaid at settlement, it is netted against the deposit then — but until that moment it is a debt, not a deduction. The deposit's job is to secure damage, not to absorb penalties. See [Deposits](/docs/concepts/deposits). ## They never stack Both are evaluated, and **only the larger one is billed.** A resident who both leaves early *and* gave short notice pays one penalty, not two. ## The notice period The required notice depends on how long the contract runs, counted inclusively of both the move-in day and the contract-end day: | Contract length | Notice required | | -------------------------- | --------------- | | 31 inclusive days or fewer | 15 days | | Longer | 30 days | A contract that spans a full calendar month lands in the 30-day bucket, not the 15-day one — only a genuinely sub-month stay is short enough to qualify for the shorter notice. **A resident who was already month-to-month when they FILED owes the longer period**, whatever their original contract length. **Month-to-month does not begin when the contract ends. It begins when the notice window opens — *before* the contract end.** The window opens one notice period before the contract end date: 30 days out on a normal contract, 15 on a very short one. A resident who has not given notice by then has **auto-renewed**. That is the same window [month-to-month](/docs/concepts/month-to-month) uses everywhere else, and the same one the "MTM at Submission" column on the move-out notices screen reports. So the test is: **on the day the notice was filed, had the window already opened?** If yes, 30 days. If no, the contract's own period. Two consequences worth knowing: - Filing **early**, before the window opens, holds you to the contract's base period — even if the departure date you choose falls a little past the contract end. Staying a few extra days does not retroactively raise the requirement. - Filing **inside the window**, even before the contract end date has arrived, means the longer period applies — because by then the contract has already rolled over. Staff can also set month-to-month manually; a manual flip dated on or before the filing counts the same way. Your workspace configures the actual values; the shape of the rule is what is described here. ## How each is priced Both are priced the same way: the days involved, charged at **each day's own calendar-month daily rate**, starting the day *after* the move-out date. The move-out day itself is already covered by the final month's rent, so starting the window the next day is what stops it being billed twice. **Early exit** covers the remaining days from the day after move-out through the contract end — **capped at one month's rent**. The cap is a policy value based on rent, deliberately not on the deposit actually held: a discounted or zero deposit must not change what leaving early costs. **Short notice** covers only the days that were short, and is **clamped to the notice period** — a resident can never owe more than one full notice period for short notice, however late the notice was filed. A notice given the same day as the move-out owes one day less than the full period; only a notice filed strictly *after* the move-out day reaches the full amount. The short-notice window is exactly the rent a compliant leaver would have paid for those days. A notice filed on the 8th for a move-out on the 31st, where 30 days' notice was required, gives 24 days and is 6 short — so the charge covers the 1st to the 6th of the following month. ## Reading it afterwards A filed notice stores the penalty in a single pair of fields, so an early-exit penalty and a short-notice penalty look the same once persisted. Which one it was is determined from the dates: if the move-out date is before the contract end, it was an early exit. This matters for wording. A capped early-exit penalty covers **less** than full rent through the end of the window, so it should be described as "your contract runs until…" rather than "rent is owed through…". Getting that backwards overstates what the resident owes. ## Deposit forfeit **Retired.** New notices never forfeit a deposit — the value is always zero. The field survives so historical notices still display correctly, and a chargeable early exit is recorded in the short-notice fields. Do not reach for it. See also [Contract dates](/docs/concepts/contract-dates), [Month to month](/docs/concepts/month-to-month) and the [Move Outs](/docs/platform/move-outs) chapter for the screen itself. # Pricing snapshots (/docs/concepts/pricing-snapshots) When a reservation is created, the price it was quoted is **frozen onto the reservation itself**. Changing a building's rent tomorrow does not change what an existing resident is billed, and does not change what their old invoices say they were billed. This is not a caching optimisation. It is the reason a two-year-old invoice still reconciles. ## Two snapshots, doing different jobs **The original price** is written once, at booking, and never changes. It is the answer to "what did this resident agree to?" — the figure their contract was generated from. **The current price** is a *timeline*: a list of periods, each with its own amounts and its own date range, the last of which runs open-ended. It is the answer to "what are they paying now?" Rent that steps up at year two, a utility change, a guest surcharge appearing when a co-occupant moves in — each is a new period on that timeline, not an edit to the old one. Because the current price is a timeline rather than a value, you can always ask what someone was paying on a given date, and get the right answer for that date. Billing a past month re-reads the period that was in force then. ## What a snapshot holds Only the **recurring monthly** amounts live on the snapshot: base rent, utilities, building maintenance, the short-term surcharge, the guest surcharge, and any monthly fees your workspace has defined in [the fee catalogue](/docs/concepts/the-fee-catalogue). Workspace-defined monthly fees are stored **self-describing** — the label and the P\&L category travel with the amount. That means a rent row can be written from the snapshot alone, without going back to the catalogue to ask what a code meant at the time. Rename or retire a fee and the historical rows still read correctly. One-time amounts are not on the snapshot. The reservation fee and the security deposit are fields on the reservation itself, because they are collected once. ## Discounts are snapshotted too A discount is frozen alongside the price, including the minimum-stay condition that made the resident eligible. A resident who qualified keeps what they qualified for, even if the campaign later changes or ends. ## The frozen quote Workspaces running the fee catalogue in **active** mode also freeze the whole **quote** at booking: which rules produced each number, the season and length-of-stay rent plan that applied, and every workspace-defined fee line. That is the audit trail. When someone asks in eight months why this resident pays what they pay, the quote answers it without anyone having to reconstruct what the catalogue looked like on the booking date. ## What this means in practice - **Changing a fee rule never touches existing residents.** If you intend to change what a current resident pays, that is a change to their reservation, not to the catalogue. - **Add a rule, do not edit one.** Editing a rule that has already been quoted against rewrites what the past says it charged. See [the fee catalogue](/docs/concepts/the-fee-catalogue). - **A resident's price looking "wrong" against the current catalogue is usually correct.** Check when they booked before treating it as a defect. Never repair a pricing problem by editing a snapshot to the number you want. The snapshot is what invoices, contracts and the ledger were all derived from; moving it silently desynchronises them from documents already sent. Correct the reservation's pricing through the proper amendment, which writes a new period and leaves the history intact. See also [Contract dates](/docs/concepts/contract-dates) and [The ledger](/docs/concepts/the-ledger). # Proration (/docs/concepts/proration) A resident who occupies a room for part of a month is billed for that part, by day ratio. It happens automatically at both ends of a tenancy, and it recalculates when a date changes — moving a move-out date later restores the fuller month, moving it earlier trims it. ## How the amount is worked out The ratio is **days occupied ÷ days in that period**. February and August therefore give different answers for the same number of days, which is intended: a day in a 28-day month is worth more than a day in a 31-day one. Two details decide whether the numbers reconcile: 1. **Each component is prorated separately, then summed.** Rent, the utility fee, building maintenance, surcharges and any catalogue fees are each scaled and rounded on their own. The invoice total is the sum of those rounded parts — not the monthly total scaled once. 2. **A full month is never prorated at all.** When the occupied days equal the period's days the exact rates are used, with no ratio and no rounding, so a normal month can never drift by a yen. Point 1 is why a prorated invoice can differ by one yen from "monthly total × ratio" done on a calculator. A one-day slice of a ¥102,000 month sums to ¥3,291 across its components but rounds to ¥3,290 as a single figure. The itemised figure is the correct one, because it is the one that matches the lines the resident is actually billed for. ## Discounts inside a prorated period A discount is clipped to the part of the window that overlaps the period, and that clipped slice is used as-is. It is **not** re-scaled by the period's day ratio a second time — doing both would shrink the discount twice. ## The first month and the last month These two look different from every other month, and both differences are normal: - **The first month may not appear as rent at all.** It is commonly folded into the [move-in invoice](/docs/concepts/the-tenancy-lifecycle) instead, together with the deposit and the one-off fees. Looking for a rent entry that month and not finding one is not a missing charge. - **The last month is prorated to the move-out date**, and recalculates if that date moves. A date change is the supported way to change the amount. ## The rule that matters **Never hand-edit an amount to simulate proration.** The calculated figure is what reconciles against payments and against the ledger's own lines. A typed-over number looks right until the month it does not, and by then the reservation, the invoice and the payment disagree with each other and nobody can tell which was intended. If the amount is wrong, the **date** is wrong, or a **fee rule** is wrong. Fix whichever it is and let the figure recalculate. ## Where it shows up Prorated periods appear as their own lines on the move-in invoice, each stamped with the month it belongs to, so a stay that straddles a month boundary reports into both months rather than landing entirely in one. See [The ledger](/docs/concepts/the-ledger) for how those per-line periods work, and [Contract dates](/docs/concepts/contract-dates) for which date drives which end. # Roles and portals (/docs/concepts/roles-and-portals) There are separate places to sign in, and within the staff dashboard there are separate **roles**. The two do different jobs and are worth telling apart. ## Portals: different doors Each audience has its own portal, showing only what that audience needs — see [who uses it](/docs/getting-started/who-uses-it) for the map. Portals are separated for privacy, not convenience. Three boundaries generate most of the questions people ask: - **Owners** see occupancy and money for their own buildings — never resident contact details. - **Residents** see their own tenancy only — never the building's other residents, and never anyone else's charges. - **Contractors** get one job through one link, and no account at all. See [The maintenance model](/docs/concepts/the-maintenance-model) for what that link exposes, because it is more than the job. ## Roles: narrowing one door A role does not send an account somewhere else. It **narrows what that account can reach** inside the dashboard, and sends it home when it tries to go further. | Role | Reaches | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | The dashboard. | | **Housekeeper** | Their own cleaning events, timesheets and paid holiday, and the resident list. Every other page sends them home, and every other action — money, settings, other people's records — is refused, not just hidden. | | **Platform** | Everything, across workspaces. | Each role has its own home, so being redirected is not an error page — a housekeeper who follows a link to a money screen lands back on housekeeping. The platform role **bypasses every role gate**, by design. It is not "admin plus a bit"; it is an account no ordinary restriction applies to. Any restriction that must hold even for platform staff has to be written as its own explicit check — relying on the normal role gate will not stop it. ## Workspace scope Every account belongs to a workspace, and that is the boundary that matters most: what an account can see is scoped to its workspace before any role is considered. An account with no workspace is platform-level. This is not a filter applied to queries after the fact. It is applied underneath them, which is why there is no combination of role and URL that shows one workspace another workspace's data. ## Signing in as someone else Staff with the right permission can act as another account to reproduce what a user is seeing. Sessions started this way are **marked as impersonation throughout** — the dashboard says so while it is happening, and actions taken are attributable. Use it to diagnose, and be aware that anything you do lands as that user's action on their records. ## The practical version If someone reports "I cannot see X": 1. **Which portal are they in?** A resident asking about another resident is working as designed. 2. **Which role?** A housekeeper cannot reach or use money pages; a link to one sends them back to housekeeping rather than showing an error. 3. **Which workspace?** Scope is checked before role. See also [Getting started](/docs/platform/getting-started) and the [Settings](/docs/platform/settings) chapter, where accounts and roles are managed. # The fee catalogue (/docs/concepts/the-fee-catalogue) Every fee — rent, deposits, surcharges, one-offs — is a **definition** in your workspace's own catalogue. Nothing about what you charge, or how much, is fixed by OmniPM. Two workspaces running the same software can bill entirely differently, and neither is a special case. This is why documentation never quotes an amount as fact. Any figure you see in a worked example is illustrative. **The authoritative answer to "what is the late fee?" is your own catalogue**, and nowhere else. ## What a definition holds | Field | What it decides | | ----------------- | ------------------------------------------------------------------------------------------ | | **Code** | The stable identity. Survives relabelling — rename the fee and its history still lines up. | | **Label** | What residents see, in English and Japanese. | | **Timing** | When it bills: at move-in, monthly, at move-out, or per night. | | **Method** | How the amount is derived — see below. | | **P\&L category** | Which revenue line it reports into. | | **Auto-settles** | Whether it clears itself against the deposit at settlement. | | **Active** | Whether it can be charged at all. Deactivating never rewrites history. | ## The five methods - **Fixed** — a flat amount. - **Percent of rent** — a share of base rent, so it tracks a rent change automatically. - **Tiered by stay** — the amount depends on how long the resident stayed, in days or months. - **Per extra guest** — applies from a guest count threshold, optionally multiplying per additional guest. - **Per bed** — priced by bed size, which is how bedding is billed. The room-restoration fee is the one built-in exception: it is set on the **unit** (Properties ▸ a unit's Pricing tab — see [Properties](/docs/platform/properties)), not as a catalogue rule, and it is frozen onto the reservation the moment it is made. Editing a unit's fee only ever affects bookings made afterwards. ## Rules: the same fee, different answers A definition says *what* the fee is. **Rules** say what it costs in a given situation, and the more specific rule wins. A rule can be narrowed by: - **Property type** — sharehouse or apartment. - **Building** — one building overrides the type-wide default. - **Bed size**, for per-bed fees. - **Date range** — every rule has an effective-from, and optionally an effective-to. That last one matters more than it looks. **Changing a price means adding a rule that starts today, not editing yesterday's.** An edited rule rewrites what the past says it charged; a new rule leaves the old one intact and correct for the reservations that were quoted against it. See [Pricing snapshots](/docs/concepts/pricing-snapshots) for why that history has to survive. ## Built-in and workspace-defined fees Some codes are **built-in**: rent, utilities, building maintenance, the security deposit, the reservation fee, short-term and guest surcharges, bedding, restoration, the room-change fee. They are built in only because they occupy named places in invoices, contracts and the ledger — not because their amounts are fixed. Every one is still a row you set. Anything else your workspace bills gets its own code and rides the generic path. It appears on invoices, in the ledger and in the P\&L exactly like a built-in one. ## Catalogue mode A workspace runs the catalogue in one of three modes: - **Legacy** — pricing comes from the older per-building fields. - **Shadow** — the catalogue is evaluated alongside legacy pricing and the two are compared, but legacy still decides what is billed. This is the safe way to move an existing workspace across. - **Active** — the catalogue decides. Never infer which mode a workspace is in from documentation, including this page. Check the workspace. A change made in the wrong mode either does nothing visible or changes real invoices, and the two look identical while you are making it. ## Ordering Fees appear on invoices and quotes in the catalogue's own sort order, not alphabetically and not in the order they were added. If a fee is showing up in an odd place on a resident's invoice, that is where to fix it. See also [Pricing snapshots](/docs/concepts/pricing-snapshots), [The ledger](/docs/concepts/the-ledger) and [Move-out penalties](/docs/concepts/move-out-penalties). # The ledger (/docs/concepts/the-ledger) All money — income and expense — is recorded as **ledger entries**, each with its own itemised **lines**. There is no separate rent table and no separate charges table. To answer "what does this resident owe?", read the ledger, not the reservation. The reservation holds the agreement; the ledger holds the money. ## An entry, and its lines An **entry** is one billable or payable event: a month's rent, a move-in invoice, a one-off charge, a supplier purchase. It carries a direction (income or expense) and a kind (`monthly_rent`, `move_in_invoice`, `charge`, `short_stay`, and the expense kinds like `repair` or `utility_expense`). A **line** is one item inside it, with its own amount and its own category — rent, a utility, a guest surcharge, a bedding fee, a deposit, a discount, an adjustment. The entry's total is the sum of its lines. The itemisation is the record. Never hand-edit an entry's total to make it match something — change the line that is wrong, or add the line that is missing. A total that no longer equals its lines is the shape of every reconciliation problem that takes a day to unpick. Two consequences follow from the split, and both come up constantly: - **A single month can carry lines that belong to different months.** Each line can be stamped with its own billing period, so a move-in invoice covering a part-month plus the following full month reports into two months rather than landing entirely in one. - **A single entry can carry lines that belong to different units.** A temporary room during a transfer attributes its own lines to that room's building in the profit-and-loss view, while the rest of the invoice stays with the real one. ## The four income shapes **Monthly rent** is generated per reservation per month, prorated at each end of the tenancy. **The move-in invoice** is the entry that collects everything due before arrival — first period's rent, the deposit, one-off fees — and it is why a first month often does not appear as a rent entry at all. **Charges** are one-offs raised against a resident after move-in, classified by charge type. **Short-stay revenue** mirrors each check-in-link booking into the ledger so minpaku and OTA income reaches the same profit-and-loss view as everything else; the booking record stays the operational source of truth for the stay itself. ## Expenses Expenses are entries in the other direction, with lines for the item, tax, shipping and anything else. Some kinds keep their operational context alongside the money — a maintenance purchase keeps its supplier and photos, an inventory item keeps its stock level — because profit-and-loss is not the only thing that needs them. ## Entries that point at other entries Three links between entries exist, and confusing them causes double-counting: | Link | What it means | Effect on revenue | | ------------------ | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | **Settles** | This entry collects an earlier entry's shortfall — arrears for a month already billed. | **Excluded** from revenue: that income was recognised in the original month. | | **Transfers from** | This entry was paid using an overpayment sitting on a previous reservation. | **Counted** as real revenue; the source's overpayment is neutralised. | | **Adjustment** | A correction line against an existing entry. | Changes the entry it belongs to, rather than adding a new one. | The rule of thumb: **money arriving late is not new money.** If an entry exists to recover something already billed, it must not be counted twice, and the settles link is what says so. ## Reading it - **Payments and P\&L** live on the [Rent Roll](/docs/platform/rent-roll-financials) money tabs, which read these entries. - **A resident's own view** shows the same entries as invoices and receipts. - **What is still owed** is always entry total minus what has been paid against it — never a stored "balance" field, because a stored balance is a number that can silently stop agreeing with its lines. See also [Proration](/docs/concepts/proration), [The fee catalogue](/docs/concepts/the-fee-catalogue) and [Deposits](/docs/concepts/deposits). # The maintenance model (/docs/concepts/the-maintenance-model) Maintenance has three layers, and they answer three different questions. | Layer | Answers | | ----------- | ------------------------------------ | | **Request** | What did someone report? | | **Project** | What are we actually doing about it? | | **Visit** | Who is going, where, and when? | Keeping them separate is what lets one trip fix five reported problems, and one reported problem take four trips, without either becoming a mess. ## Requests are the inbox A request is a report — usually from a resident, sometimes raised by staff. It carries the description, the photos and the unit it concerns. **A request is not a plan.** It is the raw signal you group *from*. Requests stay readable as their own list precisely so nothing gets lost between being reported and being scheduled. ## Projects are the work A project is the unit of actual work, numbered `PRJ-####`. It gathers the requests it addresses, the tasks it breaks down into, the purchases it needs, the work logged against it and its files. Project numbers have **gaps**, and that is expected. Older gaps came from rolled-back transactions burning a number. It is not evidence of a deleted project. A project has a status — open, in progress, on hold, completed, closed — a priority, and a **manager**: the office staff member overseeing it. The manager is not the person who physically goes; that is the visit's assigned staff. ### Grouping requests into a project When you group requests, two warnings can appear, and both are about money and attribution rather than tidiness: - **Requests spanning different buildings** produce a project with *no* building. - **A project with no building** means grouped purchases book to the overall P\&L rather than to a building. The consensus rules that infer a project's building, unit and priority from the requests you are grouping apply **only when creating a NEW project**. Grouping into an **existing** project leaves that project's own building, unit and priority alone, and issues no warning. If you expected a project to inherit a building and it did not, check which of the two you did. ## Visits are the trips A visit is one person going to one place on one date, bundling the tasks to be done there. It has a scheduled time window, a status — scheduled, in progress, completed, cancelled — and may require approval. Because a visit bundles tasks, **the link between work and a trip lives on the project's tasks**, not on the request. Claiming, reassigning or detaching work from a visit is done against a project task. Filters for "needs a visit" exclude work already **in progress** — it is being dealt with. Reading such a filter as "everything outstanding" undercounts, and the gap is exactly the work someone is currently doing. ## Contractor share links A project can be shared with an outside contractor through a link. This is the part to be careful with. The share page is **project-scoped and writable**. A contractor holding the link can see the project's requests, tasks, purchases, work logs, files and history, and can act: log hours, create a purchase, move a task between pending, in progress and completed, and tick steps. **A share link is a building credential, not a job credential.** It exposes the building handbook — entrance codes and WiFi included — alongside the work. Send it only to a contractor you would give those details to on the phone, and revoke it when the job is done. Links expire, but expiry is a backstop, not the control. Purchases a contractor creates on the share page book to the project's building, and therefore to that building's P\&L — which is the other reason a building-less project deserves a second look before you share it. See also the [Maintenance](/docs/platform/maintenance) chapter for the screens themselves. # The tenancy lifecycle (/docs/concepts/the-tenancy-lifecycle) Everything in OmniPM hangs off a **reservation**. It is created when someone books, and it stays the spine of the tenancy until the deposit is settled long after they have gone. The reservation holds the **agreement**. The ledger holds the **money**. Almost every confusing situation resolves once you know which of the two you should be reading — see [The ledger](/docs/concepts/the-ledger). ## 1. Booking A reservation is created with a unit, dates and a resident. At this moment the price is **frozen onto it** — see [Pricing snapshots](/docs/concepts/pricing-snapshots). A later change to your fee catalogue will not alter what this resident was quoted, which is what makes an old invoice still reconcile. A booking fee may be collected here, and it is credited back on the move-in invoice rather than kept separately. ## 2. The move-in invoice Before arrival, one invoice collects everything due up front: the first period's rent, the [deposit](/docs/concepts/deposits), and the one-off fees your catalogue defines. **It is not always one month.** A resident moving in after the 15th gets the partial move-in month *and* the whole month after it on the same invoice, with ordinary monthly rent starting a month later than you might expect. See [Contract dates](/docs/concepts/contract-dates) — this is the single most common reason a resident's early months look under-billed when they are not. ## 3. The contract The contract is generated from the frozen pricing and sent for signature. Two dates start diverging here and should not be confused: - **The contract start** drives billing and occupancy. - **The arrival date**, when the resident physically turns up, drives the condition-report window and nothing financial. ## 4. Living there Month by month, rent is generated per reservation. Alongside it: - **Charges** are raised for one-offs — see [The ledger](/docs/concepts/the-ledger). - **The current price is a timeline**, so a rent step-up or a co-occupant arriving adds a new period rather than editing the old one. - **Room and occupant changes** create an amendment, and the deposit transfers across on paper without cash moving. ## 5. Notice A move-out notice fixes the departure date. From that moment: - The final month is **prorated** to it — see [Proration](/docs/concepts/proration). - Availability updates on its own; nothing is flipped by hand. - Any [penalty](/docs/concepts/move-out-penalties) is calculated — as a **charge**, never as a deduction from the deposit. A resident who merely *mentions* they are leaving has not filed a notice. That is recorded as an expected departure and does nothing financial. See [Availability](/docs/concepts/availability). **A contract reaching its end with no notice does not end the tenancy** — it rolls into [month to month](/docs/concepts/month-to-month). ## 6. Move-out and the room check The room is inspected and the condition recorded against the report from move-in. Legitimate deductions are established here. ## 7. Settlement The deposit is settled: deductions applied, anything still owed netted off, the remainder established as the refund. The move-out report is where that calculation is shown and agreed. ## 8. Refund — its own step Settlement and refund are **separate stages**, and conflating them misstates whether a resident has been paid. | Status | Meaning | | ----------------- | ------------------------------------------------- | | **Pending** | Not settled yet. | | **Partial** | Some of the deposit resolved, some still held. | | **No refund due** | Fully resolved, and the amount sent was **zero**. | | **Refunded** | Money was actually sent. | Only **refunded** means a payment went out. **No refund due** is a legitimate, complete outcome — the deposit was consumed by deductions or arrears — but it is not a refund, and describing it as one to a resident invites a dispute about money that was never owed to them. ## What outlives the tenancy The reservation, its ledger entries, its invoices and its pricing snapshots are all kept. That is what allows a question about a tenancy that ended two years ago to be answered with the numbers that were actually true at the time, rather than reconstructed from today's configuration. # Analytics (/docs/platform/analytics) ## Analytics (/admin/analytics) Analytics opens on an **Overview**: one block per area, each with its headline number and a link into the detail. If one block cannot load, it says so and the others still show. Below the Overview are five areas, listed under Analytics in the sidebar. Each area's page is titled with the area's name (Occupancy, Income, …) and has a back link labelled Analytics that returns to the Overview. Each area has a row of views across the top: | Area | Views | What it answers | | ------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Occupancy** | Now · Forecast · History | How full are we today, this month, and in the coming months? **Now** has this month's occupancy and its change against last month, today's counts, occupancy by type, management or owner, units by area, and a table of every building. **Forecast** shows the coming months, with a range for contracts that may not renew, and the residents moving out soon. **History** shows saved months and the seasonal pattern. | | **Income** | Estimate · What-if | What does the portfolio bring in? **Estimate** gives monthly rent, net income and vacancy loss, by building. **What-if** recalculates them at an occupancy you choose. **Net income** is what you keep: the management fee on managed buildings, and the full rent on your own and master-leased ones. Occupancy on both views is the same as on Occupancy ▸ Now: buildings on offer only. | | **Pricing** | Our rents · vs Market · Unit suggestions | Are our rents right? **Our rents** shows our rent levels (average and median by type), how rents are spread, price per m² by area, price against size, and the portfolio mix by layout, size, type or management. **vs Market** compares our rent with collected market listings, ward by ward, and shows market rent and availability over the last 30 days of scrapes. **Unit suggestions** lists every unit against its ward's market median (above, in line or below) with a suggested price. | | **Marketing** | Funnel · Sources · Website · Campaigns & blog | Where do bookings come from? **Funnel** goes from views to inquiries to reservations, compares each measure with the previous period, and shows the reservation pipeline and each unit's conversions. **Sources** covers contact sources, how residents found you, inquiry volume by type and contact clicks. **Website** and **Campaigns & blog** are described below. | | **Audience** | Residents · Visitors · Devices | Who books, and who visits? **Residents** shows the nationality, visa status and payment method of reservations made in the period, or over all time. Visa statuses that are not one of the booking form's choices are counted together as *Other (not a listed status)*, and nationality values made only of digits are left out. **Visitors** shows the languages and countries visitors come from, and what they search for. **Devices** shows sessions, conversions, first clicks and scroll depth by device. | **Every panel says which time window its numbers cover**, in a short line under its title: for example *Today*, *Current month · today*, *Last 30 days* or *Last 12 months*. Two panels on one screen can cover different windows, so read that line before you compare them. **Filters.** - **Occupancy ▸ Now** and **Forecast** filter by **Owner**, **Properties** and **Type**; **Income** by **Owner** and **Properties**. Picking an owner narrows the property list to that owner's buildings. **History** has its own All / Share House / Apartment switch. - **Pricing ▸ Our rents** filters by **Type**, **Ward** and **Properties**; **vs Market** and **Unit suggestions** by **Ward**. - **Marketing** and **Audience** have a **Period**; on **Residents** it also offers **All time**. Filters are part of the address, so a link you copy opens on the same view with the same filters. They also carry over when you move between areas from the sidebar. **Charts.** Hover a chart for its values. On a chart with a legend, click an entry to hide or show that series. **Export.** Marketing and Audience have an **Export spreadsheet** button that downloads the *Marketing & audience* workbook: one sheet per figure, each stating the window it covers. Most follow the period; *Monthly trends* always covers the last 12 months. Numbers here are summaries of the operational data. If something looks wrong, check the source pages (Rent Roll payments and expenses, reservations) before you doubt the chart. Old links still work: the previous tab names (Scenario, Forecast, History, Conversions, Portfolio, Market Intel, Website) open the view that replaced them. ## How occupancy is counted - **Occupancy %** is room-days: every day a unit is lived in across the whole current month (days already booked ahead included), divided by units × days in the month. Residents on the rent roll, partner-calendar bookings and short stays all count. Occupancy counts only buildings on offer: hidden and archived buildings are left out. The dashboard home's Occupancy Rate is the same number. - **Occupied / Month-to-month / Reserved / Available** are today's counts and always add up to the total units. A resident becomes **month-to-month** when their renewal window opens (the notice period before their contract end) without notice — the same rule as the Residents list. A resident with no move-out date and no notice stays counted, however long ago their contract ended. - **The change against last month** on Occupancy ▸ Now compares this month's Occupancy % with the month History saved for the same buildings. It appears once that month has been saved. - **Forecast** shows two lines per month: **Expected** (bookings and filed notices as they stand; residents without notice stay) and a shaded range down to **If contracts ending soon don't renew** (residents who can still give notice leave at their contract end). This month on Forecast is the same number as Occupancy %. **Upcoming move-outs** lists who leaves in the next two months; **Not contacted** shows only those nobody has emailed yet. - **History** is saved month by month: shortly after midnight on the 1st, the month just ended is saved and never recalculated. ## Marketing ▸ Website (/admin/analytics?tab=marketing\&view=website) Traffic and search for one of your public websites, over the period you pick: **Google Analytics** (users, sessions, channels, landing pages) and **Google Search Console** (clicks, impressions, click-through rate, position, top queries and pages). **It needs two things under Settings ▸ Google Workspace** (see [Settings](/docs/platform/settings)): a connection that granted Analytics and Search Console — press **Reconnect** once if yours predates them — and at least one website with its Analytics property, Search Console site, or both. Until then the view says which is missing. With several websites, a **Website** filter appears beside **Period**; the *primary* one opens first. - **Refreshed hourly**; the top bar says when the numbers were fetched. - **Sessions and Users are compared with the previous period** of the same length: the change shows under each figure, and the sessions chart adds that period as a grey line. Search Console figures have no comparison. - **Search Console runs two to three days behind**, so the newest days read low. - **It will not match the Funnel.** The Funnel counts events our own pages record; Analytics counts sessions by Google's rules, and ad blockers hide some visitors. - **If Google refuses**, its reason is shown — usually that the connected account has no access to that property. Add the account as a user in Google. **In the Funnel (Marketing ▸ Funnel).** With Analytics connected, a **Website sessions** step heads the funnel, and **Website sessions** joins the measures you can pick above the daily chart, compared with the previous period like the others. The line under the funnel is the share of sessions that *started* a reservation — started, not paid, because paid reservations include ones staff enter by hand. Only the primary website counts. The spreadsheet export does not include sessions. **Blog in Google Search (Marketing ▸ Campaigns & blog).** With Search Console connected, **Top posts** gains Search clicks, Impressions and Avg. position for the last 90 days, with each post's languages added together. **Views** is the site's own lifetime count, so the two will not agree. # Announcements & Newsletter (/docs/platform/announcements-and-newsletter) ## Announcements (/admin/announcements) Official notices to residents (maintenance windows, rule changes, events). Tabs: **Compose · Drafts · History**. - **Compose** — write the announcement, choose the target buildings (or everyone), optionally set a target date the notice refers to, and either send now or **schedule** a send date & time (Japan time — it sends at the time you pick). - Announcements reach residents by email and appear in their resident portal, in the resident's language where translations are provided. - **Drafts** — saved but unsent announcements; finish and send them later. - **History** — everything sent, with delivery info. Check here before re-sending anything. ## Newsletter (/admin/newsletter) The marketing newsletter for subscribers (prospects who signed up on the websites): manage the subscriber list and send campaigns. Unsubscribes are handled automatically — never manually re-add someone who unsubscribed. **Which to use?** Residents/operational → Announcements. Marketing to prospects → Newsletter. # AI Chat & Staff Knowledge Base (/docs/platform/assistant) ## AI Chat (/admin/ai-chat) The internal staff assistant. Ask it operational questions in any language — "How do I process a move-out?", "What's the late-fee policy?" — and it answers from the Staff Knowledge Base (including this guide). Chat sessions are saved per staff member, so you can revisit past conversations from the session list. **It only knows what's in the knowledge base**, unless you have been given database access (below). If it can't answer, it says so and tells you to ask your manager — it will never guess a policy or a price. Every one of those unanswered questions is recorded automatically in the **Unanswered** tab, so nobody has to remember to report the gap. ## Asking about live data If an admin has given you **AI data access**, the assistant can also look things up in the live database — in the dashboard chat and on LINE alike. It reads; it never changes anything. Ask it in plain language, in English or Japanese: - **What's available** — "What can I offer for July?", "中野で15万円以下、今空いてる？", "anything free at Tokiwadai?" It searches by building, area, neighbourhood, station or room number, in English or Japanese, and handles typos. It lists only rooms a customer could move into — for an occupied room's rent, just ask for it directly. - **What something costs** — rent, the utility fee, the building maintenance fee, the monthly total and any campaign discount. Just name the building and the room: "what's the rent of ML Meguro 102?". You don't need a slug, and it works for a room that is **currently occupied** — a full room still has a rent, and staff are entitled to it. (Only don't offer that room to a customer.) - **What a room is like** — size, layout, floor, bed size, amenities, nearest stations, and how many people it takes. Named the same way: building plus room number, or a slug. - **What it costs to move in** — "how much to move into Kanda 103 on December 20th?" It runs the same pricing engine a real booking runs, so the deposit and prorated first month match what the customer will actually be invoiced. It needs a real move-in date; the first month is prorated by day. - **Who lives somewhere** — the anonymous resident mix of a share house (nationalities, ages, occupations), and which rooms are taken, by whom, and until when. Things worth knowing: - **Every figure it gives you comes from the database, not from memory.** If it can't look something up, it says so rather than estimating. If a number looks wrong, check the dashboard and tell a manager — don't repeat it to a customer. - **"Month-to-month" is not a vacancy.** A resident past their contract end with no move-out notice stays indefinitely. The assistant says so explicitly; never promise that room. - **"Possibly available" is a guess**, not a date. It means a contract is ending with no notice filed. Don't promise it either. - **Rent never includes utilities.** The assistant always states them separately, and so should you. - **Resident details are internal.** Names, emails and phone numbers are for you, not for the customer sitting with you. For "what's the house like?", use the anonymous mix. - **It cannot see** visa status, income, employer, addresses, identity documents, contracts or payment history. Those stay in the dashboard. - **Every lookup is recorded** against the staff member who asked. If you don't have access, nothing changes: the assistant answers from the knowledge base as before. Ask an admin — it's granted per person under Settings → Staff members, and the whole feature has a master switch under Settings → Automation. ## Asking from LINE You can also ask the assistant from **LINE**, using the same Official Account residents message. Your LINE account has to be linked to your staff profile first: message the Official Account once, then ask an admin to open that conversation in the Inbox and choose **⋯ → This is a staff member**. From then on: - Your messages are answered from the Staff Knowledge Base and **stop appearing in the team inbox** — colleagues won't see your questions among resident conversations. - Your LINE questions show up in the AI Chat session list alongside anything you typed in the dashboard, marked `LINE`. - A thread stays together while you're using it and starts fresh after about six hours of silence. - Text only — photos and stickers get a short "please type your question" reply. - If you have **AI data access**, the availability, pricing and resident lookups above work here too — which is the point of having it on your phone while you're sitting with a customer. If your LINE isn't linked, nothing changes: your message lands in the inbox like any other. An admin can unlink you any time from Settings → Staff members, which sends your messages back to the inbox. The whole LINE side is governed by one switch: **Settings → Automation → LINE staff assistant**. When it's off, every LINE message goes to the inbox as normal, including from linked staff. ## Unanswered tab (?tab=gaps) The assistant's backlog: every question it couldn't answer, newest first. This is where the knowledge base grows from real demand rather than guesswork. It opens on the **Status is Pending** pill; remove it to see resolved and dismissed questions too. - **Times** counts how often the same question has been asked. Work the high numbers first — that's what the team actually needs written down. - **Source** shows whether it was asked on LINE or in the dashboard; **Asked by** shows who. - **Create KB entry** opens a new entry with the topic pre-filled and marks the question resolved once you save. Don't create the entry by hand from the KB tab — you'd leave the question sitting in the backlog. - **Dismiss** is for questions that genuinely don't deserve an entry (one-offs, personal requests, nonsense). They stay counted if asked again but stop being suggested. - If a question is asked again *after* you resolved it, it **reopens automatically** — a signal that the entry you wrote didn't actually cover the case. Read the question again and expand the entry rather than re-resolving it. ## Knowledge Base tab (?tab=kb) The Staff Knowledge Base is the assistant's brain: entries for procedures, policies, and this dashboard guide. - **Browse & search** — the list shows topic, category, a content preview, order, and status. Click a row to read the full entry; use **Edit** to change it. - **Add an entry** — **+ New Entry** → topic (phrase it as the question staff would ask), category, and content in plain text/markdown. You can also **import a file** (PDF, Word, Excel, CSV, text) — its text is extracted into the content field for review before saving. - **Active toggle** — only Active entries are given to the assistant. Deactivate outdated entries instead of deleting them if unsure. - **Sort order** — lower numbers appear first in the list. The dashboard guide uses 100–330; keep other entries below 100 or above 400 so the guide stays grouped. - **Keep entries focused** — several small entries on precise topics beat one giant document, both for browsing and for answer quality. Short entries are given to the assistant in full with every question. Long ones are listed by title and section headings, and the assistant opens one when a question needs it — so a clear topic and clear `##` headings are how it finds the answer. **This is the internal KB.** The customer-facing knowledge base (which powers the public "Moly" assistant) lives under Content → Knowledge Base — never put internal procedures there. Staff entries can also come from conversations: **Add to KB** in the Inbox, OTA Inbox, Reports and move-out channel suggests entries you review and save to the Staff KB. # Content (/docs/platform/content) ## Content (/admin/content) Marketing and website content. Subtabs: **Blog · Campaigns · Knowledge Base**. ## Blog Articles for the public websites. Create them by hand, or with **AI generation** where it has been set up for your company — where it hasn't, the generate buttons say so and nothing is created. A new post's author defaults to your company name. Review drafts for accuracy and brand voice before publishing — the Dashboard home shows a Drafts card when posts are waiting. Posts are multilingual; check the main languages before publishing. **Topics follow real search demand when Search Console is connected.** If your primary website has a Search Console site chosen under **Settings ▸ Google Workspace**, topic suggestions favour subjects people already search for — queries where your site shows up in Google but below the top three results, so it rarely gets the click. Without Search Console, topics are chosen exactly as before. To see how each post is doing in search, open **Analytics ▸ Marketing**. ## Campaigns Discount campaigns for marketing pushes: percentage or fixed-amount discounts, permanent or first-N-months, with optional site banner (headline, emoji, CTA). Campaign discounts apply automatically to qualifying new bookings and show in the resident's price breakdown for the campaign duration. End a campaign by its end date — existing residents keep the discount terms they booked with. ## Knowledge Base (public) The **customer-facing** knowledge base that powers the AI assistant on your public website. Entries are bilingual (English + Japanese) Q\&A about living with us — booking, fees, house rules, area info. Keep it accurate: the assistant answers customers directly from these entries. **Important:** this is different from the **Staff Knowledge Base** (AI Chat → Knowledge Base tab), which powers the internal staff assistant and contains this guide. Customer-facing info → here; internal procedures → Staff KB. Entries can also start from a real conversation: **Add to KB** in the Inbox, OTA Inbox, Reports and move-out channel proposes entries (English and Japanese) for you to approve. Everything here also reaches the AI reply drafts in the Inbox, so keep it accurate. # Contract templates (/docs/platform/contract-templates) ## Contract templates (/admin/contract-templates) The tenancy agreement a resident signs is written here, as a **template**: a document with **fields** that fill in from the reservation (names, rent, dates), optional **conditional sections**, and the **signature blocks** where each party signs. Open it from the Settings hub, under **Guest communication → Contract templates**. **Nothing is sent from these templates yet.** You can write templates, preview them against real reservations and keep drafts. Publishing is limited to platform staff until signing in the app is switched on for your workspace. Until then, contracts go out exactly as they do today. ### The list Each row shows a template's language, its scope, its latest published version, and whether the draft has changed since. **+ Filter** narrows the list by **Language** or **Status** (Published, Unpublished changes, Never published, Archived). **+ New template** opens an empty contract straight away: paste or type it first, and name it when you save. Deleting a template that was never published removes it. A published template is **archived** instead: new contracts stop using it, and its versions are kept, because issued contracts refer to them. SignNow's own page has not moved: its connection test, its webhook and its template browser are under **Settings → Integrations → SignNow**, and stay there until signing in the app replaces SignNow. Once your workspace has a SignNow template ID set (under **Settings → Client settings → Contracts**), this list also shows **SignNow settings**, which opens that page, and **Import from SignNow**, which turns one of its templates into a new draft. The text comes across with a field wherever SignNow had one. Positions are approximate, so read the result line by line. ### The three steps A template is written in three steps, shown under its title: 1. **Contract.** The text and its fields, together. Fields are part of the text, so editing a sentence never moves a field out of place. 2. **Save.** For a new contract, this is where you name it and choose its language. After that, every change saves on its own. 3. **Properties.** Which buildings use it, plus the page and signing settings. **Version history** sits to the right of the steps once the template has been published. **Rename** and **Publish…** are at the top right. ### Which template a contract uses | Setting | Where | Meaning | | --------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Contract language** | Save, or **Rename** | English or Japanese. A contract prints in its template's language, whatever language the resident uses in the app. Once the template is published its language is fixed: for the other language, create a new template. | | **Buildings** | Properties | **All buildings**, including ones added later, or **only the buildings you tick**. | | **Property type** | Properties | Apartment, sharehouse, or any. With all buildings it sits next to that choice; with ticked buildings it is under **Advanced**. | | **Priority** | Properties → Advanced | Breaks a tie between two templates that fit equally well. | | **Active** | Properties → Advanced | Only active, published templates are used. | When several published templates fit a reservation, the most specific wins. A template limited to named buildings beats one limited by property type. To word part of a contract differently for some buildings, keep one template and use a **Building is** condition (see [Conditions](#conditions)). Priority only decides between templates limited in the same way. Publishing warns you when two templates would still tie. ### Writing the contract The **Contract** step shows the field panel on the left and the contract on the right. On a narrow screen the panel opens from the toolbar's **Fields & blocks** button. **Edit | Preview** above the contract switches to the preview. Start with the text: click in the page and paste it, type it, or use **Import from Word**. Then place the fields. #### The field panel The panel sorts everything by **who fills it in**, and each kind keeps its colour in the panel and in the contract: | Section | What it holds | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **In this contract** | What the contract uses so far: its fields, its signers and upload requests, and its conditions. A key the catalogue no longer knows shows in red, because it blocks publishing. | | **Filled from the reservation** | Fields printed from the booking when the contract is issued: names, the property, rent and fees, dates, your company's details. **Most used** is open; the other groups fold. | | **Filled in when signing** | Signature blocks and upload requests. The signer completes them while signing. | | **Conditions** | **Show only if…**, which makes a part of the contract print only in some cases. | | **Layout** | The page break. | Sections and groups open and close with a click, and the panel remembers them in your browser. **Find a field, block or condition** searches labels and descriptions ("surname" finds the family name) and opens every group with a hit. **Hover over anything** in the panel, or over a field in the contract, to see what it is, where its value comes from and what it prints for the preview's sample resident. #### Placing fields - **Blanks.** Gaps the pasted text leaves for a value are highlighted: underscores (`＿＿＿`, `___`), circles (`○○○`), short placeholders in brackets (`[Tenant name]`) and spaces before 年, 月, 日 or 円 (`令和　　年　　月　　日`). Drop a field on a highlighted blank and it replaces the blank. The bar above the contract counts the blanks left. **Next blank** selects the next one; then click a field to replace it. - **Fields.** Drag one into the text, or click it to insert it at the cursor. With some text selected in one paragraph, clicking a field replaces that text. A field shows as a chip. Double-click the chip, or select it and press **Edit selected**, to set what it prints when the value is empty or to make it **required**. A required field that is empty stops the contract from being issued rather than printing a blank. - **The annex.** The **Annex** group holds `special_terms`, the annex itself: the discount, the season rent schedule, additional fees and the temporary-room note, each only when it applies. Put it near the end, before the signatures. **Annex reference** prints one sentence pointing to it ("See Annex for additional terms.") and belongs in the rent clause. Both print nothing when there is nothing to disclose. - **Fees.** Every active fee in your fee catalogue has fields for its amount and its label, under **Rent & fees**. If you later deactivate a fee, its fields show as unknown and block publishing until you remove them. - **Co-occupants.** Under **Occupants**, choose Co-occupant 1, 2 and so on, then insert their fields. A field for a co-occupant the contract does not have prints nothing. - **Signature blocks.** One per signer: the resident, the co-occupants (one block repeats for every co-occupant) and the legal representative. Choose the boxes it holds: signature, initials, name, date signed. - **Upload requests.** A document the signer uploads while signing, such as an ID. It is not printed on the contract. - **Formatting.** Headings, lists (including 第1条 numbering), tables, quotes, page breaks, bold, italic, underline and alignment are in the toolbar. - **Undo and Redo** are the two arrows at the start of the toolbar (Ctrl+Z and Ctrl+Shift+Z; ⌘Z and ⇧⌘Z on a Mac). They take back anything done in the contract: typing, pasting, placing a field or block, adding or editing a condition, and changes saved from an **Edit** drawer. #### Conditions Click in a paragraph, or select several, then click **Show only if…** under **Conditions**. Choose what decides in the rows that open and press **Wrap selection**: that part prints only when the condition holds. The section shows its condition on its header. Press **Edit** there to change it or add more. A condition is a set of rows, like a filter in a spreadsheet: **Show this section if** *what to test*, *how*, *against what*. For example: | What to test | How | Against | The section prints when | | ------------------------------------------------- | --------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Property type | is not | Sharehouse | the property is not a sharehouse | | Building | is | Maple Court | the unit is in that building | | Has co-occupants | is | No | the contract has no co-occupants | | Restoration fee charged upfront | is | Yes | the booking pays the unit's restoration fee on its first invoice | | Restoration fee already paid at the first booking | is | Yes | an occupant-change amendment in a room whose restoration fee is charged on the first invoice, when that fee was paid at the first booking | | Monthly base rent | > | 100000 | the rent the contract prints is over 100,000 | | Contract start date | is before | 2026-10-01 | the contract starts before that day | | Applicant nationality | is not | Japan | the nationality is anything else, or empty | | Unit/room number | is empty | | the field prints nothing | - **What to test** is the property type, a building, one of the yes-or-no situations (people, situation, fees), or any field. Type to search. - **Building** tests the building itself, not its name, so renaming a building (in English or Japanese) never changes which contracts print the section. For several buildings, add one row per building joined with **or** — or, for "none of these", rows of *is not* joined with **and**. - **How** depends on the field. Amounts and counts compare with =, ≠, >, ≥, \< and ≤, against what the contract prints. Dates compare with *is before*, *is after*, *is on or before* and *is on or after*. Text compares with *is*, *is not*, *contains* and *does not contain*, ignoring capitals and full-width letters. Every field can also be *is empty* or *is not empty*. - **Restoration fee already paid at the first booking** holds only on an occupant-change amendment in a room whose restoration fee is charged on the first invoice, when that fee was paid at the first booking. The amendment does not charge it again: **Has a restoration fee** and **Restoration fee charged upfront** are then No and the restoration fee field prints nothing, so put a sentence such as "The restoration fee for this room was already paid at the first booking." under this condition. When the fee is still billed on the first booking's unpaid invoice, the amendment prints as it always did; when it was never billed, the amendment states it as deducted at move-out, over the whole stay. - **A field with no value fails every comparison**, so *is not* and *does not contain* hold for it. Add an *is not empty* row to leave empty values out. - **+ Add condition** adds a row. The second row chooses **and** (every row must hold) or **or** (one is enough), and the rows after it follow. - **+ Add condition group** adds a box of rows that join the other way, for a test such as *apartment and (rent over 100,000 or has co-occupants)*. A group cannot hold another group; for that, put one conditional section inside another. - A section tests at most 10 conditions in at most 5 groups. **Save** names the first row that is not finished. Select whole items of a numbered list to make articles conditional: a hidden article is left out and the ones after it renumber. Conditions nest at most three deep. To take a condition off, press **Remove condition** on the section's header. The editor will not delete, cut, type or paste over a selection that runs across a section's edge, because that would move text into or out of the condition. Select inside the section, outside it, or the whole section instead. #### Pasting and importing Pasting from Word or Google Docs keeps headings, lists, tables (with each cell's alignment) and basic formatting, and drops everything else. Text written as `{{monthly_rent}}` becomes the matching field when it is pasted or imported, even where Word has split it with spelling marks or formatting, and as you type its closing `}}`. **Import from Word** replaces the whole draft with a `.docx` file's content in the same way. ### Saving A new contract is not stored until you press **Save…**. That asks for a name and the contract language, which is pre-selected from the text, then opens **Properties**. Leaving before that asks you first. After the first save, every change is saved as the draft a moment after you stop typing. The **Save** step reads *Unsaved changes*, *Saving…* or *All changes saved*; clicking it saves at once. **Save and continue to properties** under the contract does the same, then opens **Properties**. If the template is saved from another tab, or by someone else, after you opened it, saving stops and a red banner offers **Reload the latest draft**. Your unsaved edits are not merged into theirs, so nothing of theirs is overwritten. A draft is never used for a contract. Only a published version is. ### Preview Choose **Preview** above the contract. It is available once the contract has been saved. The preview shows the **saved draft** on an A4 page with the template's margins and the contract fonts, so lines wrap where they will in the PDF. In a narrow window the page is scaled down to fit. Preview it with the **sample resident**, choosing co-occupants, a legal representative and the property type, or with **a real reservation** in your workspace, found by name, reservation ID or room. Fields with no value for that resident are listed above the page. **Open as PDF** prints the same preview as a PDF, without the contract number and page footer an issued contract carries. ### Properties The **Properties** step decides which buildings use the template: - **All buildings, including ones added later.** New buildings are covered without anyone remembering to add them. - **Only the buildings I choose.** Tick them in the list. Search it, narrow it to apartments or sharehouses with **+ Filter** → **Type**, or use **Select all shown**. Until you tick one, the template still applies to all buildings. Each row shows what a **new contract in the template's language** at that building would be issued from: - **This template**; - another template, named; - **Tie**: two templates fit equally well, so the contract fails until one has a higher priority or a narrower scope; - **No template**: nothing fits, so the contract fails to issue. The line above the list counts each. On a template that has never been published, the list shows what happens once it is. **Page and signing**, below, holds: - the page margins (the bottom margin holds the contract number, the page number and any initials, so it is at least 20 mm); - the base font size; - how many days a signing link stays valid; - the signing order: one signer after another, or the resident first and then all co-occupants at once; - which signers initial every page. Once a template is published, changing its scope or archiving it changes at once which contracts it is used for, without a new version. That is also limited to platform staff until signing in the app is switched on. Such a change is refused if it would make two published templates fit the same contracts equally well, and every change is recorded with who made it. ### Publishing and versions **Publish…** runs every check first. It refuses a template that has any of these: - an unknown field or condition; - a field for an inactive fee; - no signature box for the resident; - no signature box for the co-occupants, or for a legal representative. To print one only when the contract has that person, put it in a "Has co-occupants" or "Has a legal representative" conditional section; - a character the contract fonts cannot print. It warns about weaker problems, such as another template that would tie with this one, or a landlord detail the contract prints that your workspace has not filled in yet. It also says which contracts the template will be used for (an archived template is used for none until it is made active again under **Properties → Advanced**), lists your workspace's other published templates, and asks for an optional note. Publishing freezes the draft as a new **version**, which never changes, and contracts issued from it keep pointing at it. **Version history** lists every version with its note, who published it and when. **Preview** shows a version. **Restore to draft** copies it back into the draft, to edit and publish again. ### Your company on the contract Contracts name your company as the landlord, from **Settings → Client settings → Branding → Legal identity**: the legal entity name and the representative, in English and Japanese, and the real-estate licence number. Fill these in before you publish a template that prints them. Platform staff viewing all workspaces must first choose yours to edit them. See [Settings](/docs/platform/settings). # Dashboard Home (/docs/platform/dashboard-home) ## Dashboard home (/admin) The home page is your morning overview. It greets the logged-in staff member and shows the key numbers at a glance. ## Stat cards | Card | Meaning | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Buildings** | Buildings you still offer: not demo, hidden or archived. The occupancy cards below count the same buildings. | | **Total Units** | Units in those buildings. | | **Available** | Units empty today with nothing booked ahead. Rent-roll and partner-calendar residents count as occupied. | | **Occupancy Rate** | Occupancy for the current month in room-days, rent-roll residents included. It is the same number as Analytics ▸ Occupancy ▸ Now, refreshed every 5 minutes. | | **Pending Reservations** | Unpaid bookings that still need action. Cancelled, refused, and waitlist-converted reservations are excluded, so this number is genuinely actionable — if it's above zero, someone should follow up. | | **Total Reservations** | All reservations ever recorded. | | **Blog Posts / Blog Drafts** | Published post count; a Drafts card appears only when there are drafts waiting for review. | **How "Available" works on this page:** a unit counts as available when nobody is in it today and no booking starts later. A resident who hasn't given notice by the time their renewal window opens (the notice period before their contract end) is month-to-month and still counts as occupied, until they file a move-out notice. The public site's "From \[date]" labels are worked out separately, for advertising. ## Recent activity Two tables below the cards: - **Recent Reservations** — the 5 newest bookings with guest name, building, amount, and payment status (green = paid, orange = pending). Click **View all** to open the full Reservations list. - **Recent Contacts** — the 5 newest contact-form submissions with type badges (inquiry, viewing, owner inquiry). Click a name to open it: a viewing opens on the Viewings page, anything else in Contacts. **View all** opens the Contacts page. ## Suggested daily routine 1. Check **Pending Reservations** — follow up on unpaid bookings (Reservations page, **+ Filter** → **Payment Status** → Pending). 2. Check the **Inbox** and **Contacts** badges in the sidebar — reply to new messages and inquiries. 3. Check **Move Outs** for new notices and upcoming departures. 4. Check **Maintenance** and **Reports** badges for new resident-reported issues. 5. Skim **Rent Roll → Payments** for overdue rent (**+ Filter** → **Status** → Overdue). # Expenses (/docs/platform/expenses) ## Expenses (/admin/expenses) Every cost in your workspace, in one list: what was bought for the buildings, costs typed in by hand, recurring monthly costs, and the costs other screens book (housekeeping, maintenance, inventory, approved receipts, freee payments, move-out refunds). Every row is also on the P\&L, under the property it is assigned to. Purchases used to have their own page and expenses were a Rent Roll tab. Both old addresses open this page. ### The list - **One row per expense, and one row per purchase invoice.** An invoice (a vendor order or a receipt) shows once however many lines it has. Expand it with the chevron to see its lines. - **Type** is what the P\&L files the cost under: **Bedding**, **Repair**, **Utility Expense**, **Other Expense** and so on. An invoice shows the type of each of its lines. - **P\&L Month** is the month of the P\&L the expense counts in: the month of its date, or the month after it if your company books expenses in the next month (Settings → Client Settings → **Accounting**). An unpaid expense shows **—**, because the P\&L counts paid expenses only. The Date filter still works on the expense date. - **Source** says where the expense came from: - **Online order**: imported from a vendor's order confirmation email, where that is set up. - **Manual**: added on this page, as a purchase or as a one-off expense. - **Recurring**: booked each month from a recurring expense. - **freee**: a bank or card transaction assigned on the freee page. - **Housekeeping**: a cleaner's labor and transit for a visit, or a supplies receipt from a cleaning report. - **Maintenance**, **Inventory**: parts and items recorded on those screens. - **Receipt**: a receipt a house leader or resident submitted and staff approved. - **Move-out**: a deposit refund recorded at move-out. - **Utility bill**: an electricity, gas or water bill entered as a utility bill (below). - **Filters**: Source, Type, Property, Date and **Needs attention**. Search looks at the item, vendor, order number, buyer, property and notes. The bar above the list shows how many expenses match and their total. - **Filtering by Property or Type counts only the matching lines of an invoice.** An order with bedding for one building and detergent for another shows, under that building, only its own lines and its share of the shipping and tax, with the whole invoice's amount underneath. So the total matches that building's (or that type's) row on the P\&L. - Purchases for a demo building are left out, as they are on the P\&L. - Click an expense row to open its details: the receipt photo where there is one, the visit it came from for housekeeping, its files and its change history. Files and notes can be added to any expense there. ### Adding an expense Click **+ Add expense** and choose what you are adding: - **Purchase or receipt**: something bought, line by line. See below. - **One-off expense**: a single cost with no lines, such as a repair bill, a tax payment or an insurance premium. Pick its **Type**, its **Category**, the property and the amount. Vendor, payment method, a receipt link and files are optional. - **Utility bill**: an electricity, gas or water bill. See below. - **Recurring expense**: a fixed monthly cost, booked automatically each month. This opens the recurring list, where you can add, pause or end one. **Recurring** at the top of the page opens the same list. The **Category** (managed in Settings → Reference Data → Expense Categories) decides who bears the cost in a managed building's owner split. Filing under "Miscellaneous expenses paid PBKK" always books it as the management company's cost, whatever Type you pick. ### Utility bills A utility bill is one bill as printed: the **Property** and **Unit** it is for (or **Whole building** for a bill that is not for one unit), the **Utilities** it covers (tick several for a bill that covers electricity and gas together), its **Period** (the first and last day as printed on the bill; both count) and its **Amount**. Provider and a note are optional. When the unit's bills are set up (Units ▸ Edit ▸ Pricing, see [Properties](/docs/platform/properties)), its bills appear as buttons that fill in the utilities and provider, and the unit's recent bills are listed under the form so a missing or repeated period is easy to spot. Saving books the bill as a **Utility Expense** dated the last day of its period. For an apartment or house whose utility providers your company pays, it also works out what each resident of that period used. A resident's share of a bill is the bill's amount per day times their days inside its period. Once every bill the unit lists covers a month they lived there, and that month is over, the share is compared with the allowance the unit's overuse rule gives them for those days. Anything above it becomes a **Utility overuse** charge for that month, which the resident is emailed about like any new charge. The message after saving says which charges were created, corrected or withdrawn. - Correcting a bill corrects an unpaid charge it produced, and deleting one withdraws it. A charge with a payment, a payment proof or an invoice on it is never changed: the message says it needs a look. - To waive a resident's overuse charge, delete it from their charges (the reservation's **Payments** tab). It is kept as cancelled rather than removed, so it is never raised again for that month. - Two bills that cover the same days for one utility stop that month from being worked out until one is fixed. - A sharehouse's bills, a whole-building bill, and a unit whose residents pay the providers directly are recorded as expenses only. Click a utility bill's row to open the bill, where you can correct it or delete it. ### Purchases What gets bought for the buildings (supplies, furniture, bedding, parts), who bought it, and what it cost. 1. Choose **Purchase or receipt**. 2. **Attach the receipt** (optional): a photo or a PDF. Drop it on the box or click it. It is read in a few seconds and fills in the lines: the item (in English, with the printed name underneath), quantity, price, and the tax & fees amount. The supplier and date are filled in too if you have not typed them. 3. **Check the lines against the receipt.** Items that look personal (snacks, drinks and similar) start unticked, and an unticked line is not saved. A discount printed on the receipt is already taken off the line it applies to. 4. **Set each line's Type.** Mark bedding (futons, pillows, blankets, linens) as **Bedding**, everything else as **Other Expense**. One order can mix both. **Type for All Lines** sets every line at once. 5. **Set the property.** **Property for All Lines** sets every line at once; change individual lines where they differ. 6. **Check Purchased by.** It starts as you, the profile picked in "Who are you?". 7. **Compare the totals.** The footer shows your total against the receipt's. A difference usually means points or a voucher were used, a line was misread, or a line is missing. Lines you left off are counted as accounted for. Any warnings under the total say what to check. 8. Click **Add expense**. Nothing is saved before this; **Cancel** also discards the uploaded receipt. Without a receipt it is the same form with one empty line: type the item and its cost, and use **+ Add line** for more. If an iPhone photo is refused, set the camera to "Most Compatible" (Settings › Camera › Formats) or send the receipt as a JPG or PDF. In an expanded invoice: - **Each line has its own Property / Unit and Type**, set right there. One receipt can cover several buildings: assign each line to the one it was bought for. - **Shipping, tax & fees** is the part of an invoice's total that is not a product. When its lines go to more than one property, it is split between them in proportion to what each one bought; a note under the lines says so. It has no Type of its own and stays **Other Expense**, even on an order of bedding. - The **paperclip** opens the receipt the invoice was added from. - **Buyer** is who made the purchase. Pick someone from the staff list, or choose **Someone else…** to type a name. It applies to every line of the invoice. Imported orders show the ordering account's name marked "(not on staff list)" until you pick the person. - **Edit** (pencil) changes one line: item, type, quantity, cost, supplier, date, order ID, product link and notes. - **Deleting** a line removes its expense from the P\&L and re-splits the invoice's shipping, tax & fees across the lines that are left. Deleting the last line of an invoice also deletes its receipt. #### Needs attention A purchase line needs attention (orange **!**) when it has **no property, no cost or no buyer**. The **Needs attention** count above the list (also a filter) and the sidebar badge both count the invoices with such a line. A line with no cost is not on the P\&L until a cost is entered. ### Bedding Bedding bought for residents is a cost like any other, filed under the **Bedding** type, either on a purchase line or as a one-off expense. It does not have to match one resident: bedding often goes into stock first, and pillows, blankets and linens are often bought separately. - On the **P/L** (Rent Roll → P/L), Bedding is its own expense row, and the **Bedding** section under the statement sets it against the bedding fees for the same P\&L months: fees, cost and the margin. - In a managed building's **owner split**, bedding cost is shared the same way as the building's bedding-fee income (the **Bedding fee** setting in the property's income allocation): whoever keeps the fee pays for the bedding. - Bedding bought for stock counts in its P\&L month (the month it was bought, or the month after if your company books expenses in the next month), not the month a resident receives it. ### Deleting an expense Only expenses added on this page as one-off expenses, and the months a recurring expense booked, can be deleted from their row. A recurring expense that is still running books its current month again the next day, so to stop it, pause or end it in the recurring list instead. Everything else is changed where it came from, so the two never disagree: - a purchase, line by line in its expanded invoice; - housekeeping, maintenance and inventory costs, on those screens; - a freee payment, with **Unassign** on the freee page; - an approved receipt, from the receipt review; - a move-out refund, from the move-out list; - a utility bill, from its own row, which opens the bill. # Getting Started (/docs/platform/getting-started) ## What the admin dashboard is The admin dashboard, at your workspace's own address under **`/admin`**, is where staff manage the whole business: properties, reservations, residents, rent, move-outs, housekeeping, maintenance, communication, and analytics. Log in at `/admin/login` with your staff email and password, or choose **Sign in with email PIN** to get a 6-digit code by email. If you forget your password, choose **Forgot password?** on the same page. A switch at the top of the page takes residents and owners to their own sign-ins. ## The sidebar The left sidebar is organized into groups. Section headers (Residents, Operations, Communication) can be clicked to collapse or expand the group — the dashboard remembers your preference. | Group | Items | | ------------- | ------------------------------------------------------------------------------------------ | | Overview | Dashboard (home) | | — | Properties, Schedule | | Residents | Reservations, Rent Roll, Waiting List, Move Outs, Reviews, Overnight Guests, House Leaders | | Operations | Reports, Maintenance, Housekeeping, Handbooks, Inventory, Purchases, IoT Monitoring, Freee | | Communication | Inbox, OTA Inbox, Contacts, Announcements, Newsletter, Social Media, Content, Positions | | — | Analytics, AI Chat, Settings | Many sidebar items expand into **subtabs** (for example Reservations → Reservation Links, Check-in Links, Import). Clicking a subtab opens that view directly. **Badges:** small number badges on sidebar items show pending work (unread inbox messages, pending reservations, open maintenance issues, etc.). They refresh automatically about once a minute. ## Global search (Ctrl+K / Cmd+K) Click **Search...** at the top of the sidebar (just the magnifier when the sidebar is collapsed; on a phone, at the top of **More**), or press **Ctrl+K** (Windows) or **Cmd+K** (Mac), to open global search. It opens over whatever is on screen, an open drawer included; **Esc** or a click outside it closes it. It searches across: - Properties (buildings and units) - Reservations (by name, reservation ID, or a minpaku stay's OTA confirmation code; a minpaku result opens its check-in link) - Contacts (a viewing request opens on the Viewings page) - Blog posts and campaigns - Knowledge base entries - Housekeeping visits Type a resident name, building name, or reservation ID (e.g. `RSV-…`) and press Enter to jump straight to the record. This is usually the fastest way to find anything. ## Top bar On a phone there is no top bar: everything below is under **More** (see [On a phone](#on-a-phone)). - **Notification bell** — recent system notifications (new reservations, contacts, errors). Click an item to open the related page. - **Language switcher** — the admin UI can display in 13 languages. This only changes the interface language for you, not any data. - **Help** — opens this manual at the page for the screen you are on, in a new tab. It follows the current tab too, so the Help button on Rent Roll's Profit & Loss tab opens the money chapter rather than the general one. If a screen has no page of its own yet, it opens the platform guide index. - **Profile menu** — shows who is logged in. Use **Switch staff** to change the acting staff member (this controls whose name is stamped on actions like calendar events), **Change password** to set a new password, **Display** to choose dark mode or bigger, easier-to-read tables (see below), and **Logout** to sign out. Field staff have no profile menu: their **Display** button (a half-filled circle) sits beside the password and logout buttons. ## Display: dark mode and easier-to-read tables Open **Display** from the profile menu (on a phone, from **More**). Every choice applies at once, so you can try each one and see the page change behind the dialog; click **Done** when you are happy. - **Theme** — **Light** (the default), **Dark**, or **Match device**, which follows your phone's or computer's own light/dark setting and switches with it. - **Text and tables**: - **Standard** — the dashboard as it has always looked. - **Comfortable** — for anyone who finds the tables hard to read: bigger text inside every table, taller rows, darker grey text, stronger lines between rows, and a light stripe on every other row so your eye stays on the right line across a wide table. - **Large** — everything Comfortable does, plus bigger text across the whole dashboard: menus, forms, buttons and headings. These choices are saved **on this device only**, in your browser: set them again on another computer, phone or browser. They do not change what anyone else sees, and clearing your browser's cookies puts them back to Light and Standard. ## On a phone On a phone (640 px wide or less) the dashboard works like a phone app: - **The bar at the bottom** holds four places and **More**. Tap a place to go there; its number is the same count the sidebar shows. A page that is not in the bar lights up **More**. - **More** holds everything else: search, who is signed in (with **Switch staff**), notifications, **Help** for the screen you are on, every section of the sidebar (a section with pages of its own unfolds them when you tap it, its main page first; the one you are on opens already), then **Bottom bar**, **Settings**, **Display**, **Language**, **Change password** and **Logout**. - **Choose your own bar** under **More** › **Bottom bar**: tick up to four places, and untick one to make room for another. **Reset to default** goes back to Home, Reservations, Inbox and Maintenance (field staff: the first four places of their own menu). The choice is saved on this device only, like Display. - **As you scroll**, the page's title and buttons, its tabs, and its search and filter button stay at the top, so you can filter without scrolling back up. The line describing the page scrolls away. A list's pager stays at the bottom, just above the bar: **‹** and **›**, the rows on screen (tap them to jump to any page) and how many rows a page shows. - **Tabs:** a page whose views are listed under its sidebar item on a computer (Rent Roll, Housekeeping, Reservations and others) shows them as tabs at the top of the page on a phone. ## Roles | Role | What they see | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **admin** | The full dashboard described in this guide. | | **super\_admin** | Same as admin, plus tenant/client switching. | | **housekeeper** | A reduced sidebar with only: Visits, Timesheets, Residents, and (for eligible staff) Paid Holiday. Housekeepers see only their own visits and cannot access money or reservation pages. | ## General conventions used everywhere - **Lists** have a search box, a **+ Filter** button and pagination. **+ Filter** lists what you can filter by; choose one and a value, and it becomes a pill that reads as a sentence, such as "Status is Pending" or "Unsettled only". Click a pill to change it, or its **×** to remove it; **Clear all** appears once there are two or more. Some lists open with a pill already on (open tickets only, the next 14 days): remove it to see everything. On a phone the bar stays one line: the search, a filter icon showing how many filters are on, and the page's own buttons. The filter icon opens a panel from the bottom of the screen with the sort order and every filter, set or not; tap one to change it, its **×** to remove it, then **Done**. Above the list, a page's main button (**+ New …**) is a round **+** beside its title on a phone; its less-used buttons are under **⋯** next to it, and the counters above a list (Open, In progress …) become a row of chips you can swipe. On a phone each row of a list is a card (its name, a line of details, its status); tap it to open the record and see every field. - **Sorting:** click a column header, or use the **⇅ Sort** pill. Filters and sorting cover every matching row, not just the page on screen. On most lists they are kept in the URL, so you can bookmark or share a filtered view. - **Tables** show one line per row. Long text is cut short (hover it for the full text), several items in one cell show the first plus "+N", and a start and end date share one column, such as **Stay**: "Oct 21, 2024 → Oct 6, 2025". - **Clicking a row** usually opens the detail page or a drawer with more information. - **Statuses** are pills with a dot, color-coded: green = good/paid/active, amber = pending/needs attention, red = problem/overdue, blue = information (upcoming, locked, handled), gray = inactive/closed. A few lists add a color of their own for one state; the word on the pill always names the state. **Categories** (payment method, source, type) are colored chips, and each building has a color of its own. A chip's color only tells values apart, and a value keeps it on every screen. - **Dialogs:** **Enter** confirms and **Esc** closes. A dialog or confirmation that moves money or cannot be undone (mark paid, refund, charge, adjustment, approve a receipt, settle a move-out, publish a final report) ignores Enter: click the button. - **Messages** (toasts) appear top right. A success or warning fades after a few seconds; an **error** stays until you press its **×**, so you can read it. At most three show at once. - **Edit pages** (a property, a unit, a campaign, a blog post, settings) are one centered column of sections; an introductory note sits in a gray ⓘ box. - **Dates** are Japan Standard Time everywhere. A resident's "move-out on 6/30" means through June 30 in Japan. - Money is always in Japanese yen (¥). ## Where to get help - Ask the **AI Chat** (sidebar → AI Chat) any operational question — it answers from this guide and the staff knowledge base, in your language. - Browse the knowledge base directly at AI Chat → Knowledge Base tab. - If something looks broken (errors, missing data), tell a manager — errors are also tracked automatically under Settings → Errors. # Handbooks (/docs/platform/handbooks) ## Handbooks (/admin/handbooks and /admin/guest-handbooks) Two separate handbook systems — don't mix them up: - **Regular Handbook** (/admin/handbooks) — the resident handbook each building's residents see online (house rules, wifi, garbage days, emergency contacts, neighborhood info), available in the resident's language. It is described below. - **Minpaku Handbook** (/admin/guest-handbooks) — the short-stay guest handbook per building/room (entrance codes, check-in instructions, wifi). These are the pages guests receive with their check-in link. Managed as per-room documents. ### The overview The Regular Handbook tab lists every building: how complete its handbook is, what residents are missing (wifi, trash days, directions, a welcome message), how many rooms have their own changes, and who edited it last. Search finds a building or a room ("nakano 203" opens that room). **Needs attention** shows the buildings with something missing; **Not started** the ones with no handbook yet, each with **Start from property info**. ### Rooms follow their building Open a building to edit its handbook. Every room shows the building's handbook, section by section. When one room is different — its own router, its own mailbox — pick the room in the picker next to the title, open the section and press **Change it for this room only**. Only that section becomes the room's own; everything else keeps following the building, so a later building edit still reaches the room. **Go back to the building's …** undoes it. On a building section, the note under the title says which rooms have their own version, so you know a change will not reach them. **Use this in all rooms…** brings them back to the building's version. ### Editing a section - **Who sees this section:** *Residents and staff* (residents in their handbook, housekeeping and maintenance staff in the [staff handbook](#the-staff-handbook)), *Residents only* (kept out of the staff handbook), *Staff only* (residents never get it), or *Hidden* (it leaves the handbook but keeps what was written). Until you choose, the door, key-box, lock-box, elevator and storage codes are *Staff only*; the welcome, house rules, neighbourhood guide and the standard guides (no smoking, washing machine, AC, kitchen, toilet) are *Residents only*; everything else (wifi, directions, mailbox, trash, cleaning supplies, emergency contacts…) is *Residents and staff*. In a room, **Hide in this room** hides a building section there only. - **Remove from handbook** (at the bottom of a built-in section, on the building): deletes what was written in the section and its photos, and takes the section out of the handbook in every room. It leaves the list entirely; **Add section** brings it back, empty. Use *Hidden* instead when you may want the text again. Your own sections have **Delete this section**. - **Order:** drag sections in the list on the left. On a phone, use ⋯ → Move up / Move down. Rooms use the building's order. - **Fill from property info** copies wifi, door codes, key box, mailbox and the map pin from the building's or room's property info. Inside one of those sections it fills only that section. - **Photos and videos** show under the section, to the same people. - **Add section** brings back a hidden or removed section (it comes back with the same audience it had, so a staff-only code section stays staff-only) or creates your own (a title, text and photos). The **Preview** button shows the handbook as residents see it, or with **Staff** as the staff handbook shows it, with the section you are editing outlined. Edits save automatically. The status next to the title says *Saving…*, *Saved*, or *Couldn't save* with **Try again** — nothing you typed is lost. If someone else saved the same handbook in the meantime, you choose whose version to keep. Residents see a saved change straight away. ### The staff handbook Housekeeping and maintenance staff have their own read-only handbook: **Handbooks** in their menu (/admin/staff-handbook), and a **Handbook** link next to the building on a cleaning event and on each maintenance job. They pick the building, and the room if they have one, and see every section marked *Residents and staff* or *Staff only* (the codes, wifi, trash rules, emergency contacts) as that room shows it. They never see *Residents only* sections, and they cannot edit anything. Every building with a handbook is listed, not only the ones they have visits in. Admins can open the same page to check what staff are shown. So when a code or a rule staff need changes, change it here: the staff handbook reads the same handbook residents get. ### More (⋯) On a building: **Fill from property info**, **Make every room follow the building…** (pick the sections; rooms keep everything else), **Clear this handbook…**. On a room: **Fill from property info**, **Copy another room's changes…** (room-specific codes are not copied), **Open the resident page**, **Make this room follow the building entirely…**. **When info changes** (new wifi password, changed garbage day, new entrance code): update the handbook immediately — residents and guests rely on these pages, and support messages drop when they're accurate. Change it on the building and every room that follows the building gets it. For entrance codes, update the minpaku handbook for the affected room(s). # House Leaders (/docs/platform/house-leaders) ## House Leaders (/admin/house-leaders) House leaders are residents who take on building duties (mainly garbage management) in exchange for a rent discount. Tabs: **Leaders · Discounts · Supply Requests · Duty Reports · Schedules · Collection Config**. Their receipts have their own page, **Receipts**, in the sidebar. - **Leaders** — who leads each building, shown by the leader's name (their email when no name is on file), with contact info, status and the leader's room. One leader per building; assign a replacement when a leader moves out. **Log in as** and **Remove** are in the row's **⋯** menu. - **Discounts** — the rent discount each leader receives for their duties, applied to their monthly rent automatically. - **Supply Requests** — leaders request building supplies (garbage bags, cleaning items); approve or decline, then arrange delivery/purchase. - **Receipts** (its own sidebar page, not a tab here) — leaders submit receipts for approved purchases; review and approve them for reimbursement. **Click a receipt to open it**: its photos (click one for full screen), its details, its items with any that look personal flagged, and the corrections made to it. From there: **Approve** (or **Mark Paid**, once approved), **Edit** (the form opens beside the photos, so you can check the paper as you correct), **Download PDF**, **Reject**, and **Retry scan** after a failed scan. **Approve** and **Mark Paid** also stay on the row for quick work. **Tick receipts** to download just those as one PDF; the header's **Download *month* PDF** takes every receipt listed for that month. Approved receipts flow into expenses. Be careful editing a receipt after approval — the amount is already booked. - **Duty Reports** — leaders report completed garbage duties (photos, dates); review for compliance. - **Schedules** — the weekly garbage-duty schedule per building (who puts out what, when). - **Collection Config** — each building's municipal garbage collection days by type (burnable, non-burnable, recyclables…), which drives the schedules. **Sodai Gomi** — house leaders can also report oversized rubbish for their building and be asked to put a booked collection out. Those requests live on their own page, [Sodai Gomi](/docs/platform/sodai-gomi), not in these tabs. ## AI Accuracy (/admin/receipts/ai-check) **Receipts → AI Accuracy** shows how well the AI reads receipts: what it read off each receipt photo beside what staff approved, so the AI's mistakes can be found and counted, even after someone has corrected them. It covers housekeeping receipts and residents' receipts. Nothing on this page changes a receipt or any money. - **What is kept.** Every scan from 11 October 2026 is kept exactly as the AI returned it: the total, the date, the store, the items and which items it thought were personal. A rescan keeps the earlier read and shows the new one. Receipts scanned before that date have nothing to compare. - **When a receipt counts.** A receipt is compared once it is approved: a resident's receipt when staff approve it or mark it paid, a housekeeping receipt when its cleaning event is locked for payroll. Editing an approved receipt updates the comparison. Un-approving it, or unlocking the cleaning event, takes it out again until it is approved again. - **The counters.** For approved receipts, how often staff changed each field: **Total**, **Date**, **Description**, **Category** (residents' receipts only), **Items** (lines edited, added or removed) and **Personal Items** (what the AI flagged as personal is not what was taken off the claim). Click one to list those receipts. **Scan Failed** lists the photos the AI could not read. **Read Right** is the share of approved receipts that needed no change. - **A receipt.** Click one to see the photo, the AI's read and the approved values side by side, the items on both sides, the text the AI transcribed, and how the read went: the size of the photo it was sent, the version of its instructions, and what the scan cost. - Taking an item off a claim is not counted as a mistake: the claimed amount is the receipt's total minus what was taken off, and that is the submitter's call, not the AI's. **Demo note:** a sandbox "demo house leader" exists for testing the leader portal — don't assign it to a real building. # Housekeeping (/docs/platform/housekeeping) ## Housekeeping (/admin/housekeeping) Cleaning operations. Tabs: **Cleaning Events · Recurring · Timesheets · Paid Holiday · Room Checks · Calendar** (the Calendar tab jumps to the reservations calendar view). ## Cleaning Events One row per cleaning event: building/unit, assigned staff, date, status, tasks, work periods, and transit. The list opens on today and the next 14 days, shown as a **Date** pill; **Today** and **Next 14 days** switch it, and removing it shows every date. On a phone, **Today** and **Next 14 days** stay on the bar, and the search sits with the filters under the **Filters** button. The Tasks column shows the first task by its **title**, then "+N" for the rest; hover it for the full list. Tasks without one (recurring cleanings, and tasks made before titles existed) show "Weekly Cleaning" or "One-off Cleaning" instead. A task tied to a room shows the room after its name, and tasks with the same name are listed together — for example "Room Check (201, 305)" or "Move-out cleaning (204)". Create a cleaning event with **New** (or let recurring schedules generate them — see below). - **Move** on a row changes the cleaning event's date, its housekeeper, or both at once. If that housekeeper already has a cleaning event at the building on the new day, the button reads **Merge into …**: the tasks and hours join that event, fixed prices add up, and this one is removed. Locked (payroll-exported) cleaning events have no Move. - **Statuses** flow scheduled → in progress → completed. A completed cleaning event's report records what was done, time worked (work periods), transit used, and photos. - Each cleaning event's tasks list what to clean. Staff on site complete the cleaning event from their own portal; admins can edit or complete cleaning events here. ### The cleaning event page Opening a cleaning event shows its tasks first. The **Tasks** tab lists each task with its latest photos; click a task to open its report. The **Time & Rides** tab holds the work periods and the train and bus rides. A dot on that tab means a ride has no fare, or no time has been recorded yet. A station or bus stop missing from the list can be added on the spot with **+ New station** / **+ New bus stop** — housekeepers can do this too. It is selected into the ride straight away; leave the Japanese name blank and it is filled in automatically, and an English name already on file reuses that entry instead of making a second one. The panel on the right holds: - **The next step** for the cleaning event's current state, for example **Mark as completed** once its day has passed. - **Details.** Click **Pricing** or **Fixed Price** to change them; the change saves at once. Click **Scheduled** or **Staff** to move or reassign the cleaning event, then confirm with **Move** or **Reassign**. If that housekeeper already has a cleaning event at the building on that day, the button reads **Merge into …** instead: the tasks and hours join that event, fixed prices add up, and this one is removed. - The hours and rides recorded so far, and the **Note to Housekeeper** shown on their phone. The **⋯** menu at the top right, next to **Lock**, holds the cleaning event's less common actions. For office staff that is **Request Sodai Gomi** (spotted oversized rubbish on the visit? It opens a new [Sodai Gomi](/docs/platform/sodai-gomi) request with the building filled in; not offered on an errand, which has no building), **Cancel cleaning event…**, **Reset cleaning event…** and **Delete cleaning event…**. Reset and Delete are hidden on a locked cleaning event. Housekeepers have no **⋯** menu; they keep **Request Sodai Gomi** inline in the panel on the right. **Handbook**, next to the building on a cleaning event, opens that building's [staff handbook](/docs/platform/handbooks#the-staff-handbook): door and key-box codes, wifi, trash rules and contacts. Field staff also have **Handbooks** in their menu. ### Creating a task (New) - **Building task / No building.** The switch at the top of the form sets whether the task is tied to a building. - A **building task** needs a building, a room (optional) and a housekeeper. - **No building** is for errands such as a supply run or a ward office visit. It appears on the timesheet under "General / No building". - **Title** (required). This is the only way to say what the task is; there is no separate type. - **No building errand:** type the title yourself. Errands never require photos. - **Building task:** pick the title from the list. Each title belongs to a **category**, set in Settings → Reference Data → Task Titles, and the list shows it beside every title: - **Photos required** (shown in the list as "After photo required"). The cleaner must add an after photo before the cleaning event can be finished. A description is also required when creating the task. - **No photos.** Nothing is required. - **Changing a task's title** to one in the other category switches the task's photo requirement to match. You can do this on the cleaning event's page or from the reservations calendar. Recurring cleanings are the exception: they always require an after photo, whatever their title, so their list shows no category. - **Changing a title's category** in Reference Data only affects tasks created or re-titled afterwards. Existing tasks are left as they are. - **Require a before photo** (building tasks only). The cleaner must photograph the space *before* starting, and the cleaning event cannot be finished without it. - You can switch this on or off later, from the task on the cleaning event's page. - Move-out inspections always require a before photo, so the switch isn't offered on them. - Recurring cleanings only require an after photo, so the switch isn't offered on them either. The same Title and before-photo choices appear when you add a task to an existing cleaning event, and when you schedule one from a room's cell on the reservations calendar (**Cleaning or task**). Adding a task to a No building errand works like the errand form: you type the title, and there is no room, minimum guarantee or before photo to set. The title of an errand's task is also typed when you edit it later. ### Moving or removing a single task A cleaning event is one cleaner's trip to one building on one day, and its tasks are that trip's line items — so the date belongs to the cleaning event, not to the individual task. Changing **Scheduled Date** on the cleaning event therefore moves *everything* on it. To move just one task, open the task on the cleaning event and use **Move…**. Pick the new day and, if it should change hands, a different housekeeper. The building stays the same. - If the destination day already has a cleaning event for that housekeeper and building, the task joins it rather than creating a second trip. That housekeeper is asked to confirm the changed trip. - **If it is the only task on the cleaning event, the whole cleaning event moves with it** — its work periods, transit and notes included. You are warned before this happens, because it is rarely what "move one task" sounds like. - Move-out inspections keep their inspection record and calendar invite in step, and still cannot be scheduled before the resident's departure date. - A completed or cancelled cleaning event refuses the move — reopen it first. So does a locked (payroll-exported) cleaning event. **Delete** removes a single task and its notes, photos and report from the cleaning event. A cleaning event always keeps at least one task, so the last one can't be deleted — delete the cleaning event instead. Move-out inspections aren't deleted here either; cancel those on the room-check screen so the inspection record and its calendar invite go with it. **Use as room check…** is for a task that *was* a move-out inspection but was created as an ordinary task (for example "Move-out cleaning"). It lists the move-outs in that room that have no room check yet and fall around the task's day. Pick one and the task becomes that move-out's room check, keeping its photos, issues and notes; the move-out list and its report pick them up. If the resident left before the move-out date on their notice, set the **Actual Departure Date** in the same dialog. Deleting that room check later gives the task back as it was. Offered to office staff on tasks that have a room, unless the cleaning event is locked. - **Issues found during cleaning** (damage, broken equipment) recorded on a cleaning event automatically create a maintenance issue, so nothing gets lost — check Maintenance for follow-up. - **Locked cleaning events** (already exported to payroll/timesheets) are read-only — the report can be viewed but not edited. Locking also counts the event's receipts as approved on [Receipts → AI Accuracy](/docs/platform/house-leaders), which compares what the AI read off each receipt with what was kept. - Every cleaning event is posted to the housekeeping Google Calendar with a `Posted by ` line so the field team sees who scheduled it. Staff sometimes hand-edit calendar titles — the dashboard record is the source of truth. - A cleaning event's price can be overridden per-event when a special rate was agreed. - **Photos** are taken by the cleaner on the cleaning event's page. Which ones are required depends on the task: see *Creating a task* above. - **Next guest's bedding.** On a room check, the **Next Resident** card shows the bedding the next guest needs (for example "2 beds: Single + Double"), and the calendar invite carries the same line. It is read from their reservation each time, so if the bedding changes or is no longer needed the line follows, without notifying the cleaner. Minpaku arrivals show no bedding line. ## Recurring tab Recurring schedules (e.g. "clean Building X common areas every Tuesday") automatically generate upcoming cleaning events several weeks ahead. Edit the rule here; generated cleaning events then appear in the Cleaning Events tab. Deleting a rule stops future generation but keeps already-generated cleaning events. - **Moving or deleting one generated cleaning changes that week only** — the schedule itself is untouched and the following weeks arrive as usual. A moved cleaning stays where you put it however far you move it, and a deleted one stays deleted; neither reappears overnight. - **Editing the rule's day or cadence rebuilds its upcoming cleaning events from scratch**, which discards any individual weeks you had moved or removed. Change the rule when the pattern itself has changed; move the single cleaning event when it is just this week. ## Timesheets tab Monthly timesheets per staff member per building, built from completed cleaning events: hours worked, wage, and transit fares. Click a row for the detailed month view. - Wages are computed from each staff member's rate **at the time of the cleaning event** — a rate change applies to cleaning events going forward; already-recorded cleaning events keep the rate that was in effect. - Some cleaning events carry a **fixed labor fee** instead of hourly pay (a flat amount agreed for the job) — those show the flat fee regardless of hours. - Transit fares per building are managed in Settings (train fares) and applied automatically. - **Download all** sits in the top bar (on a phone, under **⋯** with the month lock). The month lock is the **Payroll lock** menu beside it (**Lock month…** / **Unlock month…**); only admins see it, and it always offers both, because each reaches every cleaning event in the month whatever the filters, including ones the rows do not count. ## Paid Holiday tab Paid-holiday balances and usage for employed cleaning staff (contractors invoicing separately don't accrue paid holiday). Grant days, record usage, and see each staff member's remaining balance. Paid-holiday pay uses the staff member's wage settings. ## Room Checks tab The board for **automatic room checks** — the switch in Settings → Automation that creates room checks for the next 2 weeks, every night at 02:30 and whenever a reservation changes: one in every turnover gap (a resident leaves, the next one arrives), and one after every move-out with a notice even when nobody is booked next. A move-out from the past week that still has no room check gets one for today. If someone is later booked in after that move-out, or the next resident cancels, the cleaner keeps the same room check (moved if the date changes) rather than getting a new one. The same switch is shown under Client Settings → Feature flags; it is one setting. - **The top card** shows whether the automation is on, what its last run did (created / moved / removed / cancelled), and how many upcoming room checks are automatic versus scheduled by staff. - **Run Now** does the nightly run immediately. You normally never need it: the engine already runs by itself every night at 02:30 and whenever a reservation changes. Use it when you don't want to wait — for example right after giving cleaners their working days, or on a night the automatic run did not happen. It is only available while the switch is on. - **Upcoming Room Checks** lists every room check scheduled from today on, whoever created it: date, building and room, cleaner, **Acceptance** (Accepted — and whether the cleaner confirmed or was only emailed —, Declined, or With Weekly Cleaning when no confirmation is needed), **Origin** (Automatic, Edited by Staff, or Staff), and the departing and arriving residents. **Edit** opens the room check to change its date, cleaner, type or notes; an automatic check you edit is yours from then on. **Mark Declined** / **Mark Accepted** record the cleaner's answer on their behalf (a phone call, a message). **Open** goes to the cleaning event. - **Needs Attention** lists what a person has to deal with: - **No Cleaner** — a turnover got no room check because no active cleaning staff could be assigned. Add staff (Settings → Cleaning Staff) or schedule the check by hand from the Move-Outs screen. - **Declined** — the assigned cleaner said they can't do it. Open the cleaning event and reassign. - **No Email** — the cleaner has no email address, so they cannot be told about the room check. - **Not Yet Notified** — assigned; the cleaner is emailed at the next 10:15 run. Nothing to do. - **Cancelled (Covered)** — a stay was booked over the date of a room check, so the check was cancelled (with its cleaning-event task and calendar event). The engine creates the right check for the new gap when the switch is on; a check you scheduled yourself may need rescheduling. The cleaner is emailed that the check was removed from their schedule, and the move-out it belonged to can be scheduled again. - **Error** — the engine failed on that unit; the detail says why. - **Activity** is the log of everything the engine did in the last 14 days, filterable by action. **Edited by Staff** rows show room checks the engine created and then released because someone changed their date or cleaner. Two rules keep the automation out of your way. A room check you edit (date or cleaner) is yours from then on — the engine never moves it back. A room check you delete stays deleted: the engine remembers that turnover and does not create it again. Cancelling one from the Move-Outs screen works the same way. One exception: if a new booking later splits a turnover in two, the part your edited check no longer sits in gets its own automatic room check. To say a move-out needs no room check at all (the room is already clean, say), use **No Room Check Needed** in the resident's **Move Out** tab: the automation then makes none for it, even if someone is booked after it, and removes one it already made. ## Housekeeper accounts Staff with the **housekeeper** role see a reduced dashboard: their own cleaning events, their timesheets, resident info for their buildings, and (if eligible) paid holiday. They cannot see other staff's data or any money pages. ## Quick answers - **"Who cleans Building X this week?"** — Cleaning Events tab, **+ Filter** → **Building**; or the Google housekeeping calendar. - **"Why is a cleaning event missing from the calendar?"** — re-save the cleaning event; saving re-posts the calendar event. - **"A cleaner reported damage"** — it's already in Maintenance if recorded on the cleaning event; otherwise create a maintenance issue manually. # Inbox, OTA Inbox & Contacts (/docs/platform/inbox) ## Inbox (/admin/inbox) The unified messaging inbox for resident and prospect conversations on **LINE** and **WhatsApp**. The sidebar badge shows unread conversations. - **+ Filter** narrows the list by channel, status and staff, plus **Unread** and **Archived** (archived conversations stay hidden unless you add that pill). **Staff is Unassigned** shows conversations nobody owns yet — assign yourself before replying. - The screen has three panes: the conversation list, the conversation, and a **details panel** on the right — who this is, the resident they are linked to, the assignee and status, and the AI's read of the topic. The panel icon in the conversation header shows or hides it. Below about 1280px wide the three panes do not fit, so the details open as a drawer over the conversation instead; on a phone the conversation list and the open conversation take turns, and the back button in the conversation header (or the phone's Back) returns to the list. The OTA Inbox and the AI chat page behave the same way. On a phone the list's search and filter button stay at the top while you scroll, and the conversation header is one line: the name, **Resolve** and **⋯**. The assignee, the status and the rest of the details are under **⋯** › **Conversation details**. - Conversations can be **linked to a resident** (reservation). "Not linked" means the dashboard doesn't know who this is yet — link it from the details panel (or **⋯ → Link to a resident** in the header) so the conversation appears alongside the resident's record and history. When the dashboard recognises a resident by their phone number, the panel asks **Looks like a resident** — **Link resident** or **Not them**. - Reply directly from the inbox; the message goes out on the original channel. Each of your replies shows its delivery state underneath — **Sent**, **Delivered**, **Read**, or **Not delivered** with the provider's reason. Attach photos, videos or documents (PDF, Word, Excel, PowerPoint or a text file, up to 25 MB) with the paperclip, by dragging them onto the reply box, or by pasting them; **⌘/Ctrl + Enter** sends. On WhatsApp a document arrives as the file itself, under its name. LINE cannot receive files from a business account, so there the resident gets the file's name and a download link that works for 7 days; after that, send it again. Documents are stored privately: only that link, or someone signed in to the dashboard, can open them. - **Reply to one message in particular**: hover over it and click **Reply** (the arrow). The reply box shows what you are answering, and the customer sees the quote in WhatsApp or LINE too. **Esc** or **×** cancels. - **Reactions** (WhatsApp only): hover over a message, click the smiley and pick an emoji — the customer sees it on their message. Pick it again to remove it. The team shares one reaction per message, because the customer sees one business. A customer's own reactions appear under the message they reacted to. LINE does not let a business account react, so there is no smiley on LINE conversations. - **Resolve** in the header closes the conversation when it is dealt with (**Reopen** brings it back). The arrow beside **Send** also offers **Send and resolve** and **Send and mark pending**, to reply and set the status in one step. - **WhatsApp reply window**: WhatsApp only lets a business reply freely for 24 hours after the customer's last message. The header counts the time left; the list warns **Reply window closes in 4h** when a customer is waiting and time is running out. Once it closes, the reply box is replaced by a note until the customer writes again. - Scrolled up reading older messages? New ones no longer pull you down — a **new messages** pill appears at the bottom instead; click it to jump to the latest. - **Mark as unread** and **Archive** are in the details panel and under **⋯**. Mark as unread puts a conversation back among the unread ones to deal with later; a new message brings an archived conversation back. - **✦ Improve** polishes what you typed — grammar, spelling, clearer and friendlier wording — in the same language and with the same meaning. It never adds facts. **↶ Undo** restores your text until you type again; taking the AI's suggestion with **Use reply** can be undone the same way. - **Suggested reply**: when a customer writes in, the AI's suggested answer appears as a highlighted card above the reply box, with the topic, how sure it is and who usually handles it. **Use reply** puts it in the box for you to edit before sending; **Regenerate** asks again; **×** hides it. It is never typed in or sent unless you choose it. With no card showing, the ✦ icon in the reply box asks for one, even after you have already replied. It always answers: with the card, with **No reply needed**, or with a line under the reply box saying why there is no suggestion (for example, nothing from the customer to reply to yet). - **Add to KB** reads the conversation and suggests knowledge-base entries worth keeping — general facts, never the customer's personal details. Nothing is saved until you review each suggestion, choose **Customer KB** (answers residents; used by Moly and by AI reply drafts) or **Staff KB** (internal know-how), and click **Save**. - Auto-replies for common questions are configured under **Settings → Automation → WhatsApp auto-reply**. An auto-reply is never sent when someone has already replied after the customer's last message, or when the suggestion repeats something the conversation already said in the last 30 days (a staff reply or an earlier auto-reply). The suggestion stays in the inbox for you to decide. (Not to be confused with **Settings → Auto-Replies**, which is a different feature: canned first replies on resident maintenance tickets. See [Settings](/docs/platform/settings).) - **⋯ → This is a staff member** (LINE only) — if a LINE conversation is actually a colleague rather than a resident or prospect, link it to their staff profile with this action. Their later messages are then answered automatically from the Staff Knowledge Base and stop arriving here, and this conversation is archived. Use it only for real staff: it silences that LINE account in the inbox until someone unlinks it from Settings → Staff members. Requires **Settings → Automation → LINE staff assistant** to be ON; while it's off, linked staff keep landing in the inbox as normal. ## OTA Inbox (/admin/ota-inbox) Guest messages from OTA platforms (short-stay / minpaku bookings) in the same conversation format: read, assign, and reply to platform guests without leaving the dashboard. Keep OTA guest communication here rather than in personal accounts so the whole team can see it. The conversation view, the details panel, **Resolve**, **Send and resolve**, **✦ Improve** and **Add to KB** work here exactly as in the Inbox. **Reply** to a particular guest message works too — the quoted message is included in the email. There are no reactions on OTA messages. Replies reach the guest by email through the platform's relay address; until the guest has written in with one, the reply box is replaced by a note saying so. ## Contacts (/admin/contacts) Every inbound form submission from the websites: **Inquiry** (general/property questions), **Owner Inquiry** (property owners offering buildings), job applications and cleaning requests. Viewing requests are not here: they have their own page, [Viewings](/docs/platform/viewings), which follows each one from the request to the booking. - **+ Filter** narrows by type and source (which site/page the lead came from). Source starts as **Source is Our websites**; remove that pill to see every source. - **Schedule Showing** on an inquiry books a viewing for that person. It then appears on **Viewings**. - Click a row for the full message and reply/action options. ## Quick answers - **"A resident messaged on LINE about rent"** — Inbox → find the conversation (link it to the resident if not linked) → answer; check their Payments tab in Rent Roll first so your answer is accurate. - **"Who is handling this inquiry?"** — the assigned staff on the conversation/contact row; unassigned means nobody yet. - **"Lead asked for a viewing tomorrow"** — Viewings → **To Schedule** → the request → **Confirm** a slot that works with the Schedule page. # Inventory & Purchases (/docs/platform/inventory-and-purchases) ## Inventory (/admin/inventory) Tracks bedding stock (pillows, blankets and linens) in each building and at the office. Tabs: **Stock · Futon Requests · History**. ### Stock One row per location, item and size, with the quantity on hand. Change a quantity from the row's **⋯** menu (a bottom sheet on a phone) rather than by editing it, so every change is recorded in History. The menu holds **Adjust stock**, **Move stock**, **History**, **Edit notes** and, last, **Delete**: - **Adjust stock** adds or removes stock. Pick a reason (**Received** or **Count correction** when adding; **Used**, **Damaged / lost** or **Count correction** when removing) and add a note if it helps, such as who delivered it or what was damaged. Stock cannot go below 0. - **Move stock** takes stock from one location to another. Pick the destination and how many. If the destination has none of that item yet, a row is created for it. **Move Stock** at the top of the page (under **⋯** on a phone) does the same without starting from a row. - **History** shows every change to that row, newest first, with the quantity after each one. - **Edit notes** changes the notes only. To correct a quantity, use Adjust with **Count correction**. - **Add Item** creates a row for an item a location does not stock yet. A location holds one row per item and size; if it already has one, use Adjust. ### Futon Requests Bedding requests for incoming residents (futon sizes follow the destination unit's bed size). **Fulfill** takes one set (pillows, a blanket and linens) from the unit's building, another building or the office; buying new bedding instead takes nothing from stock. Undoing a fulfilment returns the set to where it came from. Both show in History, linked to the reservation. A request appears once its booking is accepted: a booking still waiting for staff to accept it is left out of the list and its counts. To correct a fulfilled bed (the wrong building, or the wrong purchase or delivery date), use **Edit** instead of Undo and Fulfill. It does both in one step: the set goes back where it came from and is taken again from your new choice, and the bed keeps the date it was first fulfilled. If the new choice has no stock, nothing changes. ### History Every stock change, newest first: when, who, what happened, and each item's change with the quantity left. A change that moves several items (a move, or a fulfilment) shows its first item and **+N**; hover it to see them all. Filter by location, item type, size or action. Changes made elsewhere are included: - a cleaner using an item, logged under the cleaner's name (reason **Used**) — this came from the field portal's supply-logging feature, which is retired; these entries are historical only, staff can no longer log usage this way; - a fulfilment undone because the reservation's room or bedding changed, with the reason in the note. Rows that existed before History started begin with an **Opening balance**. A lightweight read-only inventory board also exists at `/inventory` for quick lookups without logging into the admin. ## Purchases Purchases are on the **Expenses** page now (Operations → Expenses), in the same list as every other expense: one row per invoice, each line with its own property and type. Bedding bought for residents is marked there with the **Bedding** type, so the P\&L can set its cost against the bedding fees. The old Purchases address opens that page. # IoT Monitoring & Freee Accounting (/docs/platform/iot-and-accounting) ## IoT Monitoring (/admin/iot-monitoring) Smart devices installed in buildings (sensors, meters, smart locks/plugs), one card per device with monthly usage and status KPIs. On the sensors tab the **Month** pill at the top picks the period (removing it returns to the current month) and **+ Filter** offers **Building** and **With open alerts**. Click a device for its detail page and history; each alert there shows one **Period**, from trigger to resolution, or "open". Use it to spot anomalies — a device offline, or unusual usage in a unit. ## Freee (/admin/freee) The bridge to the Freee accounting system. It lists imported Freee transactions and lets staff classify each one: | Status | Meaning | | ------------------------ | --------------------------------------------------------- | | **pending** | New transaction, not yet classified. | | **assigned** | Matched to a building — counted in that building's costs. | | **ignored** | Deliberately skipped. | | **not building related** | Company-level cost, not tied to a property. | Work the pending list down: assign each transaction to its building (or mark it not-building-related). Switch status with the tabs, expenses or income with the **Type** pill (Expenses by default), and the account with the wallet cards; the search box filters as you type. **Sync Now…** is in the top bar and opens a dialog with From / To dates; they only set what that sync imports, they do not filter the list, and **Sync Now** in the dialog starts it. Accurate assignment keeps per-building P\&L honest. Freee connection settings live under Settings → Freee. **Income: matching a transfer to bills.** With the type set to **Income**, **Match** opens a transfer. Pick the resident (the ones it most likely comes from are suggested first, or search for anyone) and tick the bills it pays: one or several, including a rent month that has not been billed yet. When several of a known payer's bills add up exactly to a transfer, the row shows a **Suggested** match with **Accept**; it is never applied without that click. If the transfer is short (a bank fee, say) or over, every bill is paid in full except the one marked to take the difference, which shows what is short or over. **Unassign** undoes the match and sets every bill it paid back to unpaid. # Maintenance (/docs/platform/maintenance) ## Maintenance (/admin/maintenance) Repairs and upkeep. Sub-pages in the sidebar: **Projects** (the front door) · **Requests** · **Field visits** · **Visit planner** · **Timesheets**. The section was rebuilt around a simple idea: **a report is not a job.** Several people can report several problems that are really one piece of work, and one piece of work usually takes several tasks, only some of which involve going to the building. So there are now five words, and they mean different things. ## The five words to learn - **Request (MNT-0001)** — *a report.* "The window in 402 is broken." One per thing somebody told us. It never changes number and never disappears. - **Project (PRJ-0001)** — *the job.* What we are actually going to do about it, from start to finish. A project holds one request or many. - **Task** — *one ordered piece of the project.* "Inspection", "Order the glass", "Install". Some tasks are field visits; most are not. Tasks are numbered on screen, and that number is the order they happen in. - **Step** — *one line under a task.* "Measure the window frame." Each step remembers which request it arrived with, so you can always see who asked for it. - **Data room** — *the project's files.* Every photo, quote, invoice and receipt for that job in one place. Everything else follows from those five. ## Projects (/admin/maintenance) The main screen. Three views, switched at the top of the page: - **List** — the whole hierarchy in one table: project, then its tasks indented under it, then each task's steps. The MNT reports themselves are **not** rows here — you read them by opening the project's Requests tab. A project row opens closed — it already tells you how many tasks it has and how far along they are — so click its arrow when you want to see inside. **Click a project's name to open it.** The name is the link; the PRJ number is not shown on the row, because you only need it once you are inside. To rename a project, use **Rename** on its "⋯" menu — a single click on the name now opens the project, so it cannot also mean "edit this". **Nothing in this table is dragged.** Rows are moved from the "⋯" menu — **Move up**, **Move down**, **Move to project…**, **Merge into task…**, and on a step **Move to task…**. Those were always the movements a keyboard and a screen reader could drive, and they are now the only ones, so there is one way to move a row rather than two that can disagree. (The Board still drags — see below. That is a different thing: there, the drop *is* the edit.) **How to read the indentation.** Each level sits further right than its parent, with a faint vertical guide line running down from it — follow the line up and you are at the row something belongs to. The marks tell you *what* a row is: a numbered chip (**1**, **2**, **3**) is a task, and a tickbox is a step. A step that came in with a report says **from MNT-####** beside it — that is where it came from, not where it lives; every step belongs to the task above it. **A new report becomes a project and one task, both named after it** — nothing else. It used to also lay down a step repeating the same words, so one report painted three near-identical lines; and the task was called "Work", which nobody had chosen and which told you nothing when you were scanning a column of them. Older projects were renamed to match, and their leftover duplicate step removed where no one had touched it. - **Board** — projects as cards in status columns (Open / In Progress / On Hold / Completed / Closed). Dragging a card to another column *is* changing its status. - **Gantt** — one month at a time, one bar per task. The bar runs from the day the task is planned for (its own date, or the day of the visit it rides on) to the day it is due. Diamonds mark the project's due date and any dated steps. Use the arrows to move a month at a time. **Reading a row.** Every project and task row shows when it was created, in a **Created** column you can sort by — click the header (or use the **⇅ Sort** pill) once for oldest first, again for newest. It sorts **projects only**: a project's tasks stay in the order you put them in. The sort is kept in the URL, so a reload keeps it. The building is in the **Location** column and nowhere else — it used to repeat as a chip beside the project's number on every row, which cost the title its space and said nothing twice. A project with **no building** still says so in grey beside the number, because that is not a label but a warning: it marks the project whose visits land in the worker's building-less bucket and whose purchases book with no building attached, and Location can only render that state as a dash. **Flat or by building.** A **Flat** / **By building** toggle above the table bands the list under building headings — alphabetical, with **No building** last. It is the project-list twin of the inbox's **Newest first** / **By building** switch. Every band starts folded away — you get the list of buildings, and open the one you came for — and its tickbox selects every project in it at once. The choice rides in the address bar, so a reload, a shared link, and coming Back out of a project all keep it. **What you can change without opening anything.** Double-click a task's title or a step to rename it where it sits; for a **project**, whose name is a link to the project itself, use **Rename** on its "⋯" menu. A title cannot be left blank — clear it and the old one simply stays. A task's **description**, the row directly beneath an expanded task, is the exception: it may be emptied, and it saves with ⌘/Ctrl+Enter or by clicking away, because plain Enter starts a new line. Status, priority, owner and dates are all editable on the row itself. Tick some projects and the bar at the foot of the screen sets **status**, **priority**, **manager** or **due date** across every one of them at once, and tells you plainly if only some of them took ("9 updated, 3 failed"). It can only *set* a due date — clearing one stays a single-row edit. **Merging several projects at once.** Tick two or more and press **Merge** on that same bar. They all fold into the **oldest** of them — the lowest PRJ number, which is the one already quoted in emails and on any share link you have sent out, so the merge costs you no reference anybody holds. Everything moves: reports, tasks, steps, purchases, files, work logs and history; each emptied project is then deleted. You are asked to confirm, and shown exactly which numbers are about to disappear. Afterwards you are offered a **new name** for the survivor, because that is precisely the moment its old one stops being true — five reports folded into the project called "Bed" leaves a job about a whole room named after one mattress. **Suggesting a name.** Beside every project's name is a **✨** button — hover the row to reveal it, or on a touch screen it is always there — and the same thing sits on the "⋯" menu as **Suggest a name (AI)…**. It reads the reports inside the project and proposes a title and a one-line description. It only ever *proposes*: you are shown both in full and nothing is written unless you accept, because the title is what staff scan, what the contractor share page leads with and what an email subject quotes. Across the top: counts for **Open**, **In Progress** and **On Hold** — click one to filter the list by it — plus an **Overdue** count. Overdue is not a status: it is every project whose due date has passed and which is not yet Completed or Closed, so a project can be On Hold *and* overdue. The counts are of the whole section, not of what the filters currently show, so they will not add up to the number of projects on screen. **Filters:** free-text search, which matches **any word anywhere inside a project**: its title, description and notes, every task and step, the requests inside it (title, description, location, notes, model number) and its purchases (name, description, supplier). That matters because the reporter typed "window is broken" on the request while a planner later named the project "Room 402 — glazing". Numbers work too: type **PRJ-0012** or **MNT-0042** (or just the digits) to find that project, or the project holding that request; a number also still matches text, so "305" finds "Room 305". Every word you type must match somewhere. Plus, under **+ Filter**, status, building, manager, priority, and source (Housekeeping or Manual). The list opens on **Status is Open +2** (Open, In Progress, On Hold); remove that pill to include Completed and Closed projects. **Two create buttons.** **+ Request** files a new report — use this for anything somebody told you about. **+ Project** opens a job with no report behind it — planned work nobody complained about (a scheduled boiler service, a batch of lock replacements). The new-project dialog offers **Start from the standard tasks**, which lays down *Inspection and disposal → Order parts → Receive and install* in that order, with the first and last already marked as site visits and the middle one not. Leave it unticked for a job that isn't shaped like that. **Statuses look after themselves, with two exceptions.** A project moves to In Progress as soon as a task is started or a visit is booked, and to Completed once every request is finished and every task is done or skipped. **On Hold** and **Closed** are decisions *you* made ("waiting on the landlord", "we're done arguing about this") and nothing automatic will ever undo them — set them from the project's "⋯" menu. There is **one** automatic Closed, and it only ever tidies up: when a housekeeping report is edited so that an issue disappears, the request it raised is closed, and if that leaves a project holding nothing but that request — no step started or booked onto a visit, no steps ticked, nothing bought, no hours logged — the project closes with it. A project anyone has actually planned work on stays open and visible. ## Inside a project Click a project to open it. The title is editable in place: click it to rename (Enter saves, Esc cancels). The panel on the left holds building, unit, manager, priority, due date and notes. Tabs: - **Tasks** — the tasks, in order. Each task has a status (Pending / In Progress / Done / Skipped), an assignee (see below), a scheduled date, a due date, its steps, its own files, and anything ordered for it. Open a task's panel from the small open icon beside its title — hover the row to reveal it, or on a touch screen it is simply always there — or from **Open details**, the first entry in that task's "⋯" menu. That panel is where you tick off the steps, schedule the visit and attach files, and it carries the **"This task is site work (needs a visit)"** tickbox, which is what puts the task in front of field staff. Double-clicking the title renames the task rather than opening it. Add a task with **+ Task**; add a step straight under any task. - **Requests** — one card per report folded into this project: its number, its category, who reported it, whether it came from housekeeping or the public form, its photos, and its own status and priority (both still editable). This is the provenance panel, not a second workspace. **Move to another project…** on a card re-files that one request — its steps, purchases, files, work logs and history go with it, and every purchase is re-booked against the destination's building. - **Files** — the data room (below). - **Purchases** — parts and materials bought for the job: item, which task it belongs to, quantity, unit cost and total, supplier, and status (Pending / Ordered / Shipped / Received / Returned). **These become expenses automatically**, booked against the project's building — so if a purchase moves to another project, its expense follows it. - **Activity** — the full change history plus the hours logged against the job. Field workers write those hours through the share link; here you can only read them or delete one. The header also carries **Share link** (below) and a "⋯" menu with **Change status…**, **Merge into…** and **Delete project**. ## Share links — treat one like a key to the building You cut a share link from a request, so the dialog asks you to pick one. **That choice only records which report the link was cut from. The link opens the whole project.** Anyone holding the URL is inside — no login, no password, no staff account — and sees: - **every request folded into the project**, in MNT order: title, description, category, who reported it, and the photos that came in with it; - **every task, in order**, with its steps, and for a task that rides on a visit, the **date and the arrival window**; - the **purchases** (item, quantity, cost, supplier, status, receipt), the **hours logged**, the **data-room files**, and the **full change history**; - the **building's and the unit's handbook content — entrance code, key box, WiFi password.** The page title is the **PRJ** number, not the MNT number. Nothing in the project is hidden from the holder. **It is not read-only either.** Whoever has the link can: - move a task between **Pending / In Progress / Completed**; - tick and untick **steps**; - **log hours** against the job (those are the hours you read on the Activity tab); - **upload files** into the data room and attach a **receipt** to a purchase; - **create a purchase** — which books an expense **straight to the P\&L**, against the project's building. What it cannot do is mark a task **Skipped**, or put the project **On Hold** or **Closed**. Those stay office decisions, and the project's own status is only ever rolled up from its tasks. So a share link is a building credential and a write handle on the money, in one URL. In practice: - Send it to the contractor actually doing the work, and to nobody else in copy. - **Set an expiry when you create it.** The dropdown defaults to **No expiry**; 7 / 30 / 90 days are right there. - **Revoke it when the job is done** — the Share link dialog lists every link cut for the project, with its click count, and a **Revoke** beside each live one. Revoking is instant and permanent; cut a fresh link if you need one again. - If a project holds work you would not show that contractor — another resident's report, a quote you are still arguing about — **move that request to its own project before you share**, because there is no way to hide part of a project from a link. ## Requests (/admin/maintenance/requests) The inbox. This is the old flat issues list, unchanged in how it works — one row per report — but its job now is **triage**: read what came in, then decide which reports are really one job. Requests arrive three ways: - **Manual** — you or another staff member filed it. - **Housekeeping** — a cleaner recorded an issue during a visit and it was turned into a request automatically, carrying the photos they took. - **Resident report** — a resident submitted the maintenance report form. Columns: created date, request number, title, building/unit, the **project** it belongs to (**Part Of** counts its requests when it holds more than one), category (Plumbing, Electrical, HVAC, Structural, Appliance, Painting, Flooring, Pest Control, Cleaning, Safety, General), priority (Low / Medium / High / Urgent), status (Reported → Scheduled → In Progress → Completed / Closed), **Manager** and **Worker** (a wrench beside the worker means a field visit is booked; hover it for the details), due date, step progress and estimated cost. Created, request number, title and due date are sortable, from the header or the **⇅ Sort** pill. Status and priority are editable straight in the row. **+ Filter** covers status, category, priority, assignee, building and source, plus **Grouping**: **Standalone** (the only request in its project) versus **In multi-request projects** (already grouped with others) — counted across every request, not just the ones currently listed. The list opens on **Status is Reported +2** (Reported, Scheduled, In Progress); remove that pill to include finished requests. The search box matches any word in a request's title, description, location, notes or model number; **MNT-0042** finds that request and **PRJ-0012** the requests in that project. The list itself can be read **Newest first** or **By building**. Select rows and the action bar offers **Group into project…** (two or more) and **Schedule visit…** (which is refused, with a count, if any of the selection is already on a visit or closed). Every request belongs to a project — there is no such thing as a loose request. Filing a new one with **+ Request** quietly wraps it in a new project of its own, so nothing is ever homeless; group it with something else later if it turns out to be part of a bigger job. ## Grouping — the whole point Select two or more rows in the inbox and choose **Group into project**. Either create a new project or fold them into an existing one. The example this was built for: *"window is broken"* and *"wallpaper is damaged"* arrive as two reports about the same room. Grouped, they become **one** project — with the standard tasks, *Inspection and disposal → Order parts → Receive and install* — and Task 1, Inspection, now holds **both** lines: "measure the window frame" and "inspect the wallpaper". One person, one trip, one job. What you need to know before you click: - **Everything the requests brought comes with them** — their steps, purchases, files and history. - **Steps land on the task that matches**, by title. If the target project has a task with the same name, the steps join it; if it doesn't, that task is added at the end rather than the steps being dumped onto task one. A fresh, unplanned request (whose only task is called "Work") sends its steps to the target's first open task. - **Building, unit and priority depend on which of the two targets you picked** — the rules below apply to a **new** project only. - **Into a NEW project.** Building and unit are worked out for you: the project takes the value every selected request agrees on, and is left blank the moment two of them differ. Priority becomes the **highest** of the ones you selected. That is why the dialog warns you when your selection spans two buildings — usually it means you have ticked one row too many. - **Into an EXISTING project.** Nothing about the target changes. It keeps **its own** building, unit and priority, however much the incoming requests disagree with it, and every purchase that comes across is **re-booked against that project's building** — so a request reported for Building B, folded into a Building A project, starts costing Building A. There is no warning for that case: the only warning on this path fires when the *target* has no building at all. Check the target before you confirm. - **A project with no building** sends its visits into the worker's building-less bucket and books its purchases to the P\&L with no building attached. Both paths warn about it, but about different things — the new-project warning is "these requests span different buildings, so the project has no building"; the existing-project warning is "the target project has no building". **Move to project…** on a single row does the same thing for one request — from the inbox, and from its card on the project's Requests tab. **Merge into project…** on a project does it for a whole project: its requests, tasks and files move to the survivor, every purchase is re-booked against the survivor's building, and the emptied project is deleted. **Suggest a name (AI)** is on every project's "⋯" menu, and it exists because grouping makes titles go stale. A project raised from a housekeeping report is named after that ONE report — "Bed", "Vacuum Cleaner" — so the moment a second report joins it, the title describes a fraction of the job. Pick it and the reports inside are read back to you as a proposed title and one-line description. **It proposes; you accept.** Nothing is written until you confirm, and the dialog shows both the new title and the new description in full, because accepting replaces both. Confirming is an ordinary edit: it lands in the project's Activity with your name on it, and you can type over it afterwards like any other title. If the suggestion is poor, cancel and ask again — it is not remembered and nothing changed. It is told the building and room and instructed **not** to repeat them, since they are already on screen beside the title, and it is told not to invent a cause, a part or a cost that is not in the reports. A project with no reports behind it — planned work you opened yourself — will be named from its tasks instead. **Make it a task of…** is the same move with a different shape, and it is the one for the five-reports case. Instead of pouring the source's tasks in beside the survivor's, the whole project becomes **one task** there, named after the project. So five housekeeping reports — five wrapper projects — become one job with five tasks, each still carrying its own report, steps, purchases and files. It **refuses** rather than guess in the two cases where folding would lose something: a project with more than one task (their order would be discarded) and a project whose task is already booked onto a field visit. Both say so, name the project, and tell you to merge normally instead. ## The data room (a project's Files tab) Every project has one, and it is the answer to "where is the quote for that job?". - Filter with the switch above the files: **All · Photos · Documents · Receipts**. Group by task or by request when there are a lot of files. - Upload with a target: the file can sit at project level, or be pinned to a specific task. Photos open in a lightbox; documents open in a new tab. - Files that came from somewhere else — a photo out of a housekeeping report, a resident's upload — are listed here **but cannot be deleted here**. They belong to the report that owns them, and deleting them would blank the photo out of that report. Only files uploaded into the data room itself can be removed. - The same task panel shows the same room, filtered to that task, so a worker looking at "Install" sees the glass measurements and not the whole job's paperwork. ## Field visits (/admin/maintenance/visits) Field visits — a worker physically going somewhere — listed by day: the assigned maintenance-capable staff member, the building, the time window, how many tasks the trip carries, its status (Scheduled / In progress / Completed / Cancelled) and its total cost. Filter by status, staff, building and a date range, and reschedule from the row. A visit is a **trip**, not a job: several tasks, from different projects, can ride on one visit. Booking a task for the same worker, on the same day, in the same building automatically folds it into the visit that already exists rather than creating a second one. That is why the visit count is much lower than the number of tasks scheduled. A visit a worker claimed themselves is theirs immediately. A visit an admin assigned has to be **accepted or declined** by that worker; a past-dated one that was never answered settles itself as accepted, because there is nothing left to act on. ## Visit planner (/admin/maintenance/tasks) Planning a month of field work, in three views — **Calendar**, **Kanban** and **Gantt** — filtered by staff, building and status. Cancelled visits are hidden unless you filter for them. On a phone the Calendar shows one button per day that has visits (the day number over a dot per visit); tap it to list that day's visits under the calendar. Use it to see whether Tuesday is already full before you promise a landlord a Tuesday. ## Timesheets (/admin/maintenance/timesheets) Monthly timesheets for maintenance staff, built from their completed visits — hours, wages and transit — mirroring the housekeeping timesheets. Click a staff row for the per-building month detail. Visits with no building roll into a "No building" bucket. ## Who does a task or a step: the Assignee Every task and every step has an **Assignee** — who does it. The picker lists, in this order: - **Office** — office staff; - **Housekeeping & maintenance** — every active housekeeper and maintenance staffer; - **House leader** — the house leader of the project's building, when it has one. Assignee is not **Manager**: the manager is always office staff and answers for the whole project. When a task or step is given to a **housekeeper, maintenance staffer or house leader**, they get an email naming the project, the place, what to do and the due date, and the work appears in their own list — **My maintenance** for staff, the **Maintenance** page of the house-leader portal for a house leader. From there they can tick the checklist and mark the task done: - given a **task**, they can tick every step under it and mark the task done; - given only a **step**, they can tick that step, and leave the task for whoever owns it. They cannot rename anything, reassign it, or see costs and purchases. Office staff assignment sends no email, as before. Marking a task done this way moves the project's status just as it does from this screen. The work leaves their list once the task is done, or the project is completed or closed. A house leader's assignment counts only while they lead the project's building: if the project moves to another building, or the building gets a new house leader, it drops off their list and they can no longer tick it. Their name stays in the Assignee field until you pick someone else. ## What field staff see on their phones Maintenance staff work from **My maintenance** in the dashboard, not a separate app. It has two views, switched at the top: **Unassigned** (the backlog any maintenance staffer can claim) and **My Tasks** (what that staffer has taken or been assigned). Above them, **Asked of me** lists any task or step assigned to that person. A housekeeper who does no other maintenance also gets **My maintenance** while something is assigned to them, and sees only that section. From a job they can open its **checklist** — tickable one-handed, with a running "3/5 done" count — start and finish a visit, reschedule it, or say they cannot do it. **Handbook**, beside the job's building and room, opens the [staff handbook](/docs/platform/handbooks#the-staff-handbook) for that place: the codes, wifi and house information they need on site. Two things worth knowing when a worker asks: - **Each step shows the MNT number it came from.** That is grouping paying off: one visit can carry two people's complaints, and the worker can tell which line answers which report. - **The tick is two-state — done or not done.** **In Progress** and **Skipped** are office decisions a checkbox can't express, so an item in one of those shows as unticked with its status badge beside it. Ticking it marks it done; nothing is lost. Ticking steps does **not** move the task or close the request. Marking the task done is the office's decision, or the person the task was assigned to. ## Numbers, old links and other gotchas - **PRJ numbers have gaps, by design.** The counter behaves like a ticket machine: a project that was started and rolled back still burns its number. `PRJ-0007` simply may not exist, and the highest PRJ number is **not** a count of projects. Do not try to "fix" it and never quote it as a total — count the rows instead. MNT numbers do the same thing. - **Old MNT links still work.** Every `/admin/maintenance/` link ever pasted into an email, a Slack message or a bookmark now opens the project that request belongs to, with that request highlighted on the Requests tab. Links inside housekeeping reports and move-out reports go the same way. - **A request's number never changes**, even when it moves between projects. Quote MNT numbers to reporters, PRJ numbers to whoever is doing the work. - **Search by number.** Type **PRJ-0012** or **MNT-0042** in either search box. A long run of digits (a model or phone number) is searched as text only. - Requests, projects, tasks and steps are separate things with separate statuses. Closing a request does not finish the job; finishing every task does. ## Quick answers - **"A resident reports a broken aircon."** File it from **+ Request** (category HVAC), set priority and building/unit. If there's already a project for that room, group the new request into it rather than starting a second job. - **"Two reports about the same room came in."** Requests inbox → tick both → **Group into project**. Check the building warning before confirming. - **"Where are the photos / the quote / the receipt for this job?"** The project's **Files** tab. - **"What did we spend on Building X repairs?"** Purchases roll into Expenses automatically, booked to the project's building — filter Expenses by building, or open the project's Purchases tab. - **"What's overdue?"** Projects screen, the **Overdue** counter at the top. - **"Why is PRJ-0007 missing?"** It isn't missing — the number was burned by a project that was never saved. Normal. - **"Who reported this step?"** The MNT number printed beside it. - **"I need to send this to a contractor."** Open the project → **Share link**. Know what you are sending: the link opens the **whole project** — every request in it, the visit windows, the files, and the building's **entrance code and WiFi** — and the holder can tick off tasks, log hours and **book purchases to the P\&L**. Set an expiry, and revoke it when the job is done. Picking a request in the dialog does *not* narrow what the page shows. # Departure Checklists (/docs/platform/move-out-checklists) ## Departure Checklists (/admin/move-out-checklists) When a resident files a move-out notice, or staff record one for them, the resident receives a confirmation email. Below the notice details it carries a **departure checklist**: what to do before leaving the room. This screen decides what that checklist says and which buildings get which one. The rest of the email is fixed. Only the checklist is edited here. ## Which checklist a move-out gets Each checklist applies to a **Property Type** (apartments, sharehouses, or any) and, under **Which buildings**, either to all buildings of that type, including ones added later, or to **Only the buildings I choose**. When more than one checklist matches a building: - a checklist for chosen buildings beats one for a whole property type; - between two equally specific checklists, the higher **priority** wins; - if they are still tied, the most recently edited one is used, and the list warns you about the tie. A building that no checklist matches gets none: its move-out emails go out without a checklist. The list shows which buildings are in that situation, and the **Which buildings** table on each checklist shows what every building will get. A checklist whose **Active** box is unticked is never used. ## Editing a checklist - **Title and intro** open the checklist. Every text has an English and a Japanese field; the email prints English first, then Japanese. - **Sections** hold the items. **Numbered list** prints them as 1, 2, 3…; **Paragraphs** prints each item as its own paragraph, for longer explanations such as bedding disposal. Use the arrows to reorder sections and items. - Leave one language empty and that line is printed in the other language only. The editor tells you when a line prints in one language only. - Write `**bold**` to make words bold. Nothing else is formatted. ## Show only if… Any section or item can be printed only in some cases: only in some buildings, only for apartments, only when the resident has co-occupants, and so on. Click **Show only if…** and build the condition the same way as in a contract template. The chip then reads "Printed only if: …". Clear it to print that part for everyone again. ## Preview Choose a building to see this checklist as a resident there would get it, in both languages, with every condition applied and your unsaved changes included. It shows this checklist at any building you pick; whether that building actually gets this checklist is what the **Which buildings** table says. The preview uses a sample resident, so a condition about the resident (co-occupants, a legal representative) shows how it prints for that sample. ## Quick answers - **Why did a resident get no checklist?** No active checklist matches their building. Open the list: it names the buildings that get none. - **Why is the bedding section missing for one building?** Open the checklist and look at the section's "Printed only if" chip. - **Can I change the rest of the email?** No. The notice details and the closing text are fixed; only the checklist is editable. # Move Outs (/docs/platform/move-outs) ## Move Outs (/admin/move-out-notices) Everything about residents leaving. Two tabs: **Move Outs** (active departures) and **Security Deposit Settlements** (the money side after departure). ## Move-out notices A notice is created when a resident files one from their portal, or by staff on the resident's behalf. Each notice records the notice date and the move-out date. **Move-out time.** Each notice also records a two-hour **move-out time window** (09:00–11:00 through 17:00–19:00): roughly when the resident will return the keys and leave. Use it to plan the key handover and the room check. - **Residents must choose one when they file from their portal.** - **Staff may leave it blank** when recording a notice on a resident's behalf. It shows as "Not specified" in the Create / Edit form and on the move-out card in the reservation drawer. - Automatically created notices, and notices filed before this field existed, have no time. - Where the time shows: - in the list's **Slot** column, next to the Move-Out Date; - on the move-out card in the reservation drawer; - on the move-out calendar event, as a "Move-out time:" line in the description (the event itself stays all-day); - in both notice emails. - Changing the time in the Edit form updates the calendar event. It never affects billing or penalties. **Resident notes.** A resident can add free-text notes when they file from the portal, such as how they will return the keys or a forwarding address. The notes show: - on the move-out report, under the resident details; - on the move-out card in the reservation drawer; - in the staff notification email. They are the resident's own words and staff cannot edit them. Use **Admin Notes** for your own notes. **Refund details.** A resident filing from the portal chooses how their deposit refund should reach them and gives the details: a bank account (bank, branch, account type, account number and holder), a PayPal email, a Wise recipient, or the card they paid with before. They can change these from their move-out page until the report is finalized. Staff can record or change them in the Create / Edit form. The refund method and these details show on the move-out card in the reservation drawer, so you can check where the money goes without opening the form. **Departure checklist.** The confirmation email the resident receives includes a departure checklist: what to do before leaving the room. What it says, and which buildings get which checklist, is set under [Departure Checklists](/docs/platform/move-out-checklists). The rest of that email is fixed. **Notice-period rules:** - The required notice period depends on the contract — a genuinely short contract carries the shorter period, a full calendar month or longer carries the longer one, and **a resident who was already month-to-month when they filed owes the longer period regardless of their original contract length**. Your workspace configures the actual values. Notice is counted **including the move-out day itself**: under a 30-day rule, filing on June 1 for a June 30 move-out is exactly 30 days — OK. - The month-to-month escalation turns on **whether the resident was already month-to-month on the day they filed** — and month-to-month begins when the **notice window opens**, which is one notice period BEFORE the contract end date, not after it. A resident who filed before their window opened keeps the contract's base period even if the move-out date they choose falls past the contract end; a resident who filed inside the window owes the longer period even if the contract had not technically ended yet. A manual month-to-month flip dated on or before the filing counts the same way. - **The "MTM at Submission" column on this screen is the same test the penalty uses**, so the badge and the charge always agree. If the badge says Yes, the longer period was applied. - **Fill in "Notice Received" when back-filling a past move-out.** Left blank, the system falls back to the notice's creation date, and only then to today. It will not charge more than it would have with the date supplied, but the recorded basis is more accurate when you set it. - Less notice than required → a **short-notice penalty** is charged for the missing days. - Leaving before the contract end can trigger an **early-termination penalty** per the contract terms. - **Waiving a penalty.** Staff can waive the penalty as a goodwill decision: tick **Waive penalty** in the Create or Edit move-out form and give a reason (required). The notice then records no penalty: no penalty charge is billed, an unpaid one is cancelled (together with its card payment link), and a later change to the dates keeps it waived. The resident simply sees no penalty. The reason, who waived it and the amount that would have been charged show on the reservation drawer's move-out card and on the move-out report. Untick **Waive penalty** to charge that amount again. - **If the resident has already paid or started paying the penalty** — paid, part-paid, a transfer proof still awaiting your review, or a card payment already taken — the charge is left in place and you see a warning when you waive. Waiving does **not** refund or remove it, and until you settle it (confirm and refund, or cancel) it still counts in the deposit settlement. - When staff enter a move-out date, the dashboard previews the financial impact (prorated rent, penalties) **before** saving — review it with the resident's situation in mind. - A move-out notice **always wins** over the contract end date for billing: rent is billed through the notice's move-out date, even if the resident had continued month-to-month past their contract end. **On the list** you see each notice's progress: room check scheduling, report status, and settlement state. **+ Filter** narrows it by **Property** (it offers every building on the tab, even one the other filters hide) and **Type** (normal vs minpaku); on Move Outs also by **Move-out from** (a pill that starts two weeks back) and **Room check**, and on Security Deposit Settlements by a **Move-out** date range, **Report status** and **Unread**. Filters apply to the whole tab, not just the page on screen. ## Room checks Each departure gets **one room check** (inspection) per turnover. It is scheduled from the notice — or, with automatic room checks on (Settings ▸ Automation), created for you and attached to the notice the same way, so the notice shows it as scheduled and the cleaner's calendar invite gives the move-out date. Deleting an automatic check frees the notice, so you can schedule one yourself. The check appears on the housekeeping calendar, and the inspector records condition and any damage. If you change a move-out date late in the process, double-check the room check afterwards — rescheduling a departure can affect an already-scheduled or completed check, so confirm it still looks right. - **The move-out day itself is fine.** A resident who leaves in the morning can have the room checked that afternoon. Moving a move-out date onto the day of a scheduled check keeps the check; moving it past the check removes it. - **Resident left earlier than the notice says?** In the **Schedule Room Check** dialog, set the **Actual Departure Date**. It is saved to the notice when you schedule, and the room check can then sit on that day. Billing and penalties stay on the move-out date. - **Already done in this room.** If the room check was recorded as an ordinary task on a cleaning event (for example "Move-out cleaning"), the dialog lists the room's tasks around the move-out. **Use as room check** makes that task the notice's room check and keeps its photos, issues and notes: the list then shows the check as done by that housekeeper, and the report shows its findings. A task dated before the departure date stays unavailable until you set the Actual Departure Date to that day or earlier. The same action is on the task itself — see [Housekeeping](/docs/platform/housekeeping). - **Deleting a room check that was made from a task** gives the task back as it was, photos and report included. Deleting any other room check removes its task. - **A cancelled room check no longer blocks the move-out.** When a check is cancelled (for example, a stay was booked over its date), the list shows **Schedule** again with "Previous check cancelled" underneath. - **No room check needed.** When a room needs no inspection (it is already clean, for example), open the resident's **Move Out** tab, click **No Room Check Needed** under Room check and give a reason. No room check is made for that move-out, even if someone is booked after it. A room check already scheduled for it is removed, and its cleaner is emailed; a completed one cannot be marked. The list shows **Not needed** (hover for the reason) and the move-out moves to the Settlement tab. **Undo** in the same place brings the room check back; scheduling a room check also clears the mark. ## The move-out report Every notice has a move-out report (it exists automatically — an empty section just means nothing has been entered yet). Open the notice → **Report**. The report collects: 1. Room condition and damage findings (from the room check). The report also shows the resident's move-in condition report to compare against — after a temporary stay, the one for the room they moved into, not the temporary room. 2. Deductions — cleaning, repairs, unpaid items — each with amounts. 3. The deposit settlement: deposit held − deductions = **refund** (or additional payment if deductions exceed the deposit). The deposit amount on the report is an editable snapshot for this settlement — verify it matches what was actually collected before finalizing. **The Room Restoration Fee row** is filled in for you from the resident's whole stay: every room they lived in during this tenancy, across room changes and co-occupant changes. A room whose fee was already paid adds nothing. A room whose fee was never billed is measured over the time actually spent in it and listed in the row's notes with its dates and amount. A fee that is still billed on an unpaid move-in invoice stays on that invoice and is not added to the row; the report shows a note naming the invoice, so you can collect it there or take it off that invoice and add it to the row by hand. A stay entered by staff (a rent-roll or admin import) counts an upfront fee as paid unless an unpaid invoice in the system bills it. **Publishing:** when the report is complete, **push** it to the resident. That opens the report in their move-out *channel* — a shared thread they can reply in — and sends a short email nudge with the headline figure and a link. The full report lives in the channel, not the email. - Normal push gives the resident a **7-day contest window** (a deadline to reply or dispute deductions). - **Push as final** skips the contest window — the settlement is immediately final. It is deliberately refused when the settlement carries charges the resident never agreed to (anything beyond the contracted room restoration fee, or an unpaid balance). Use it for a clean move-out. - **Utilities Reconciled?** For an apartment or house whose utility providers your company pays, either push first asks whether the utility bills for the stay are reconciled: **Yes, reconciled**, **Not applicable**, or **Not yet: publish anyway**, which needs a reason. Wait for the last bill when you can: once the report is pushed, the net is frozen. The answer, who gave it and when show under the published report, and a “publish anyway” also leaves a staff-only note in the channel. The question is not asked for a sharehouse room, a minpaku or owner-resident stay, a room or occupant change, or a resident who pays the providers directly. Above the answers, the dialog shows where the stay's bills stand, from the utility bills entered for the unit (see [Properties](/docs/platform/properties) for a unit's bills and overuse rule): each utility, and any days of the stay no bill covers yet; the overuse charged so far and how much of it is unpaid (unpaid charges are deducted in the settlement). While a bill is missing or two bills cover the same days, **Yes, reconciled** cannot be chosen; publish anyway with a reason instead. A unit whose bills are not set up shows a note, and the answer is yours to check by hand. - **Residents are told about the wait.** For the same stays, the resident's move-out notice form and the email confirming their notice say that the refund waits for the last utility bills covering the stay, which can take up to two months. - If an email fails to send, the report page shows the failure — resend from there rather than assuming it went out. The resident's statement lists the deposit, each inspection deduction, and every other line that makes up the headline figure: unpaid rent, charges such as a move-out penalty, a forfeit, or deposit moved to another contract. Those lines are fixed as they stood when you pushed, like the headline itself — a payment the resident makes afterwards does not change the statement unless you push it again, which starts a new contest window. On a room or occupant change the inspection items are listed below the total as charged on the new contract instead: the deposit moves there with the change, and the items are billed as one charge on the new reservation once the report is final. The report page has two tabs: **Report** (where you build the settlement) and **Channel** (the conversation the resident sees). The dot on the Channel tab is its status; a red count means unread resident replies. ## Statuses A settlement moves through: **Not started → Draft → Ready for review → Published (contest open) → \[Disputed] → Finalized → Settled.** - **Not started** — every notice has a report automatically, so an empty one is normal. It stays Not started until someone writes the report text or the message to the resident; correcting the security deposit or ticking findings on their own does not change it. Minpaku stays are auto-marked "Report not needed": they carry no deposit. - **Draft** — a report text or message to the resident has been written but not pushed; autosaves. The resident sees none of these figures, which are withheld server-side until you push. - **Ready for review** — optional checkpoint before anything reaches the resident. - **Published · contest open** — pushed; the resident can read, ask and dispute for 7 days. - **Disputed** — the resident disagreed. Auto-finalize stops while a dispute is open. - **Finalized** — the contest window closed with no dispute. A nightly job at 10:20 JST does this automatically. The resident can no longer dispute, and the figures stop changing — **the conversation carries on**, see below. - **Settled** — the money actually moved. **Finalized does not mean refunded.** This is the single most common misunderstanding, on both sides of the conversation. Finalizing *locks the figures* so nobody can contest or change them — it moves no money and sends no email. The refund is a separate action (**Close Out Deposit**), and only that sets **Settled**. A settlement can legitimately sit Finalized for weeks while you wait on a repair quote. Residents see this distinction too: their settlement page shows a **Refund** step after "Amounts final", which stays visibly open until a refund is recorded, then shows the date and method. So once you record the refund, the resident's page answers "where is my money?" on its own. When the deposit did not cover the statement and the resident owes a balance, there is no refund to wait for: that step reads **Balance to pay** instead, the page makes no refund promise and asks for no payout details, and the step closes when you **Settle Move-Out** — so settle the move-out once the balance is collected. The Security Deposit Settlements tab lists departures that still need money movement — work this list until each row reaches Settled/Refunded. ## Closing out the deposit **Close Out Deposit** on the settlement row records what happens to the deposit you still hold. In one step you can: - **Refund** part or all of it (date and method), and/or - **Apply it to rent** at the resident's other place with you, and/or **pay their other bills** there from it, and - whatever is left over is marked **forfeited** — the dialog shows that remainder before you save. **Applying the deposit to rent** is for a resident who has moved from one of your units to another and wants the balance to go toward their next rent instead of a bank refund. The dialog offers their other current or upcoming reservations (matched by the same email address), and for each one the months that can take a credit, with that month's amount due. A month cannot take a credit if it is already paid, in the past, outside the contract (or after a move-out date the resident has told you about), billed on the move-in invoice, or has a card payment in progress — the dialog names the reason. A bank transfer or cash payment the resident has already reported for that month does not block it: the credit lowers what they owe, and you finish reviewing their payment against the new amount. You can spread the amount over several months, but no month's credit can be larger than that month's bill. A stay that ended with a room or occupant change cannot use this: its deposit already moves to the new contract with the change. **The report must be finalized first.** Applying the deposit to rent, or paying other bills from it, is offered only once the move-out report is finalized — the deductions are locked then, so the amount left is final. Before that, Close Out Deposit can still refund or forfeit. What it does: - On the new reservation, each chosen month gets a line **"Deposit applied from \[old building and unit]"**, and the amount due drops by that much — the rent reminders and the resident's payment page ask for the reduced amount. A month the deposit covers in full is marked paid straight away — unless the resident has already reported a payment for it, in which case finish reviewing that payment. - On the old reservation, the row shows **Applied to payments** with the unit and what it went to, and the resident's settlement page says the deposit was applied to their payments there. - In the P\&L, the rent for that month still counts in full once the rest is paid, and the management fee is charged on the full rent. The applied deposit is not income and not a discount; the forfeited remainder is income under Other charges, as with any forfeit. The credit line on the new reservation is locked in Rent Adjustments. If you applied the deposit by mistake, use **Undo Deposit Close-Out** on the settlement row: it removes the credit, any refund and forfeit recorded in the same step, and puts the deposit back to held. It is refused once one of the credited months has been paid — undo that payment first. A notice that was already closed out with **Settle Move-Out** shows **Reopen Move-Out**; reopen it first to get the Close Out Deposit action back. If the resident later gives notice on the new place and a credited month gets shorter (or falls after their move-out), the credit is not moved for you: undo the close-out and apply it again to the months they will actually pay. ### Paying the resident's other bills from the deposit A resident who is still with you at another place may owe something there — a charge, the move-in invoice, a month that came up short. You can pay it from this deposit instead of refunding it: - **From the payment:** on the other reservation's Payments tab, **Mark Paid** and choose **Security deposit**, then pick which past deposit pays. The method appears only when the resident has a past stay whose move-out report is finalized, whose move-out is not yet settled, and whose deposit has something left. For a payment that came up short, add a settlement charge for the difference first, then mark that charge paid with Security deposit. - **From the move-out:** Close Out Deposit's **Pay Other Bills** section lists the other reservation's open charges and move-in invoice, each with **Pay from deposit**. Once nothing is left to refund, the dialog offers to forfeit what remains (the move-out deductions), which records it as income under Other charges. The bill shows as paid with the method Security deposit and a note naming the deposit; the old move-out row lists each one as **Paid from deposit**, under **Applied to payments**. A partial amount leaves the bill short, like any partial payment. The bill's income counts in full, exactly as if the resident had paid it; the deposit used is not income. To undo one, use **Reset Payment** on that bill: the money goes back to the deposit. A payment from the deposit cannot be edited in place — reset it and enter it again. If the old move-out has since been settled, reopen it first, so the money returns to a move-out that can refund it. **Undo Deposit Close-Out** never undoes these payments. Some bills cannot be paid from a deposit: one that already has a payment of its own (money received, proof awaiting review, a cash appointment, a card payment in progress) until that payment is finished, and a move-in record that only holds a deposit because rent is billed monthly. ## The channel is not the contest window Two separate things, often confused because they sit on the same page. - The **contest window** is about the *money*: how long the resident has to dispute the deductions, and when the figures lock. Finalize closes it; **Re-open contest window** opens it again. - The **channel** is the *conversation*. It opens when the report is created and stays open — through Finalized, through Settled, indefinitely. A settlement often sits Finalized for weeks while a refund is arranged, and that is precisely when residents ask where their money is. So **never re-open the contest window just to answer a question.** Re-opening un-finalizes the settlement: the figures unlock, the resident can dispute again, the nightly auto-finalize job starts watching the report again, and on a transition move-out a pending charge on the successor's account is cancelled. Just reply in the channel. To close the window again afterwards, use **Finalize now** — a re-opened report goes back to "contest open" with a fresh 7-day deadline, so the normal lifecycle simply resumes. **Muting a resident.** If a thread stops being productive, **Mute resident replies** on the Channel tab turns off *their* composer. It does not stop you: you can still post, and a public reply still emails them. It deliberately does **not** take away their Dispute button while the contest window is open — contesting the figures is their right, and muting is only a noise control. **Un-mute resident** reverses it, and both actions are recorded in the thread with your name on them, so the history shows who decided what. Minpaku settlements are different again: their channel is a **record only**, with no messages from either side, because those stays carry no deposit to argue about. The channel composer has two tabs: **Reply to resident** and **Internal note** (staff-only; the box turns amber). **✦ Improve** polishes either (same language, same meaning, **↶ Undo** to restore), and **Add to KB** in the channel header suggests knowledge-base entries from the thread for you to review before anything is saved. Attach photos with the paperclip, drag or paste them in, or pick them from the housekeeping report with the photo icon. Hover over a message to **Reply** to it (the answer shows the quote) or **React** with an emoji; quoting an internal note switches to the note tab. A message or note you sent can be **edited** (the resident sees it marked **Edited**) or **unsent** (replaced by "Message unsent", its text and photos deleted) from the same hover bar; an email nudge they already received cannot be recalled. A record-only (minpaku) channel has neither. ## Month-to-month departures A resident past contract end with no notice is month-to-month and still occupied. When they finally file, the same 30-day rule applies from the filing date. Never advertise or promise an MTM-occupied unit until a notice exists. ## Quick answers - **"When can I re-rent the room?"** — after the move-out date on the notice, plus turnover time (cleaning + room check). Check the housekeeping calendar. - **"Resident wants to change their move-out date"** — edit the notice's date; billing re-prorates automatically and the impact preview shows penalties. Re-verify the room check schedule afterwards. - **"Where is the refund?"** — notice → Report → settlement section; the Deposits tab in Rent Roll shows the deposit record itself. If the report is Finalized but not Settled, the refund has not gone out yet — that is a real outstanding action, not a display lag. - **"The resident thinks their deposit is due because the report closed"** — finalizing only locks the amounts. Their page shows the Refund step as still in progress until you record the refund; recording it updates their page with the date and method. - **"The resident is moving to another of our units and wants the deposit to go toward rent there"** — finalize the report first (that locks the deductions), then Close Out Deposit → Apply to rent, or pay their other bills there from the deposit. - **"Can we take what the resident owes from their deposit while they still live here?"** — No. A deposit pays other bills only after that stay's move-out report is finalized. Collect what is owed the usual way. - **"The report is finalized and the resident has a question"** — just answer it in the Channel tab. Both composers stay open after finalizing; you do not need to re-open the contest window, and you should not. # Positions (/docs/platform/positions) ## Positions (/admin/positions) Job openings shown on the careers page. Each position has a bilingual title (EN/JA), department, location, contract type (Full-time, Internship, …), description, and benefits, plus an Active toggle controlling whether it is publicly visible. - Create a position manually or use **AI Generate Position** to draft one from a short brief, then edit before activating. - Deactivate (rather than delete) positions that are filled, so the history stays. - Applications arrive through the careers form with resumes attached — coordinate with the hiring manager on follow-up. # Properties (/docs/platform/properties) ## Properties (/admin/properties) The building and unit catalog that powers the public websites. - **Buildings list** — every property with occupancy summary. Click a building to manage it; **New** adds a building. - **Building detail/edit** — name (EN/JA), address, access/stations, photos (reorder by dragging, or from each photo's **⋯** menu: **Make cover**, **Move earlier**, **Move later**, which also works on a touch screen), amenities, descriptions (AI generation available), house rules, and the building's units. - **Units** — created and edited from within their building: room number, size, layout, bed size, monthly rent, utility fee, deposit-related settings, photos, availability date, and guest capacity (some units are capped — e.g. maximum 2 guests — respect the cap when booking). - **Income Allocation** (a tab on the building's edit page) has no Save of its own: its edits are saved with the page's **Save Changes**. - **Whole-house listings** — some properties are rented as an entire house; they display as a single listing rather than per-room. **Availability reminder:** what the public site shows is date-driven — a future availability date shows "From \[date]", past/empty shows "Available Now", and a month-to-month resident keeps the unit occupied until they file notice. Keep availability dates accurate; they update automatically from move-out notices and are refreshed for some buildings by the availability sync (Settings → Sync). **Archiving a building or a unit:** a building or room you no longer operate can be archived instead of deleted — from its edit page (**Actions → Archive**), or by selecting several in the list and using **Bulk edit → Archived → Yes**. An archived building or unit leaves the public site, offers (waiting list, alternative rooms, room changes, reservation links), the staff unit pickers, occupancy figures, the Rent Roll availabilities tabs and the Properties list. Its history (reservations, payments, P/L) stays exactly as it was. Archiving a building archives its units with it and also hides the building; **Unarchive** brings back the building and the units that were archived with it — a unit archived on its own before stays archived — and leaves the building hidden until you untick **Hidden**. A unit inside an archived building cannot be unarchived on its own: unarchive the building first. The **Archived** filter shows the archive in both views: archived buildings, and archived units under any building. Hidden buildings are also left out of occupancy and the availabilities tabs. Archiving is refused while anything is still live on the room — a current or upcoming stay (a month-to-month resident with no move-out date counts), an open waiting-list offer or an unused reservation link. The message names what is holding it; let those end, cancel them or move them, then archive. A unit's iCal export keeps working after it is archived, so if the room is listed on Airbnb, Booking.com or Vrbo, take the listing down there too — the archive dialog reminds you when the unit has such a link. **Actions menu:** each building and unit edit page has an **Actions** button: **View on public site**, **Copy public link** (units only), **Add unit** (buildings only), **Duplicate** (opens the copy), **Archive / Unarchive** and **Delete**. Delete is refused the same way as from the list (see below); after a delete you return to the list. Duplicating a building does not copy its archived units. **Deleting a building or unit:** deleting a building also deletes its units, photos, amenities, handbooks and inventory, and cannot be undone. The dashboard refuses the delete outright if anything carrying its own history still points at it — reservations, room checks, waiting-list offers, Sodai Gomi requests, or housekeeping visits and cleaning schedule rules. You get a message naming exactly what is holding it and how many; move or remove those records first, then delete. This is a guard, not a glitch: a completed housekeeping visit carries a cleaner's booked hours and pay, and a reservation is a contract, so the delete must not take them with it. **Pricing note:** a resident's rent is snapshotted at booking. Changing a unit's price affects **future bookings only**, never current residents (their changes go through rate periods on the reservation). ## Restoration fee (per unit) Each unit carries its own room-restoration fee, set on **Units ▸ Edit ▸ Pricing**: - **Restoration fee (¥)** — one flat amount. Required; enter 0 if the unit charges none. - **Varies by length of stay** — a switch that replaces the flat amount with five brackets, one per length of stay (under 3 weeks, 3 weeks to 1 month, 1 to 6 months, 6 to 12 months, 12 months or more), so a short stay and a long stay can be charged differently. - **Charge at move-in** — ticked bills the fee on the resident's first invoice; unticked deducts it from the deposit at move-out instead. **Duplicate** on a unit copies all three settings to the new unit. **Bulk edit** (select several units) can set one flat amount across all of them — this clears any brackets they had — and flip **Charge at move-in** for all of them in the same action, which is the fastest way to standardize restoration terms across many units at once. The **properties export** includes the fee, the brackets (if set) and the move-in flag for every unit. A unit with nothing set shows **"Restoration fee not set"** on its edit page and in the units list, and a resident booking it is charged no restoration fee — there is no fallback to a standard amount. **Editing a unit's restoration fee only affects new bookings.** Each reservation freezes the unit's terms as they stood when it was made, so changing a unit's fee later never changes what an existing resident is charged. See [Pricing snapshots](/docs/concepts/pricing-snapshots) for why that history has to survive, and [Move-outs](/docs/platform/move-outs) for how the move-out-time fee reaches the deposit settlement. A room change or a co-occupant change never charges a room's fee twice: it is charged once per stay in a room — see the Room Change and Co-occupant Change tabs in [Reservations](/docs/platform/reservations). ## Utility bills and overuse (per unit) For an apartment or house whose utility providers your company pays, a unit's **Units ▸ Edit ▸ Pricing** also holds: - **Utility Bills** — the bills the unit receives. Tick the utilities each bill covers: one bill can cover several (electricity and gas together, for example), and a unit with no gas simply has no gas on any bill. A utility can be on one bill only. Provider and customer number are optional, for your own reference. - **Utility Overuse** — what a resident may use before the excess of their share of the bills becomes a charge: **No overuse charge**, **Charge usage above a fixed amount** (a monthly amount, which may be lower than the utility fee the resident pays), or **Charge usage above the utility fee**. Leave it on **Company default** to follow the rule set under Settings ▸ Client Settings ▸ Fees & Pricing. The amount a resident may use is prorated by the days they stayed in the month. Overuse is worked out from the utility bills entered for the unit, so nothing is charged for a month until its bills are in. Unlike the restoration fee, the overuse rule is not frozen at booking: it is read when a month is worked out, so a change applies to every month not yet worked out, for current residents too. Neither setting appears when residents pay the providers directly, or for a sharehouse room: a sharehouse's bills are a building expense and are never split between residents. **Duplicate** copies a unit's bills and providers, but not its customer numbers, and its overuse rule. # Property Owners (/docs/platform/property-owners) ## Property Owners (/admin/owners) Landlords who can sign in to the **owner portal** and see their own buildings — a monthly statement, who is living in their rooms, and occupancy. This screen is where you create that account and choose which buildings it covers. An owner cannot sign themselves up. Until you create them here, entering their address on the portal sign-in page does nothing at all — no email, no error. ### Two different things called "owner" Do not confuse them. - **Property owner (this screen)** — one real person or company with a login. This is what the portal reads. - **Owner / brand on the building form** — a source label shared by many buildings (Waclass, CraftFlat, and so on). It has nothing to do with portal access. ### Creating an owner **New Owner** asks for: - **Name** (and optionally the Japanese name). - **Email** — this is how they sign in. Capitalisation does not matter. - **Additional emails** — other addresses allowed into the *same* account, for a co-owning spouse or an accountant. - **Portal language** — English or Japanese. Controls the portal and the emails they get. - **Buildings** — see below. You must have a client selected before you can use this screen. If you see "Select a client first", choose one with the switcher in the top bar — a landlord belongs to exactly one client, so there is no combined view. **One address, one account.** If you enter an email that already belongs to another owner, the dashboard refuses and tells you who has it. This is not a formality: when two owner accounts share an address, the portal cannot tell which one is signing in and **locks both of them out**. The same applies across clients, which is why creating a landlord who already exists under another brand needs the tick-box — only do that when you mean it, and expect to change one of the two addresses afterwards. ### Linking buildings The picker lists every building for the client. Two things are worth reading before you save. **Only managed, non-demo buildings show up in the portal.** Buildings that are owned outright, held on a master lease, or flagged as demo are still linkable — they may change category later — but the portal ignores them today. The picker labels them, and a note under the list counts how many of your selections will not appear. If an owner says buildings are missing from their portal, this is the first thing to check. **Linking a building shows its whole history.** Statements are worked out from who owns a building *right now*; there is no record of when ownership changed. So linking a building today makes **every past month** of its income visible to that owner, including months a different owner held it. If a building has changed hands, check what the previous months will show before you link it. **A building belongs to one owner at a time.** If you pick a building that already belongs to someone else, the dashboard stops and names the buildings and their current owner. Confirming moves them, which removes them from the other owner's portal and from their statements. ### Sending the invitation On the owners list, **Payments** stays on the row; **Edit**, **Send invite** (**Resend invite** once they have signed in), **Log in as** and **Deactivate** / **Reactivate** are in the row's **⋯** menu, a bottom sheet on a phone. Send invite and Log in as are offered for active owners only. **Send invite** emails the landlord to say their portal is ready, in their chosen language, with a link to the sign-in page. The email deliberately carries **no login link**. They enter their email on the sign-in page and receive a six-digit code that lasts ten minutes — so an invitation sitting in an inbox, or forwarded to someone else, is never a way into a landlord's financial records. You can resend it as often as you like. If they never arrive, the **Last sign-in** column tells you: it stays "Never" until they actually complete a sign-in. ### Deactivating There is no delete. **Deactivate** stops a landlord signing in, straight away — even if they are signed in at that moment — while keeping the record and its building links intact. Reactivate puts it back. Deleting outright is deliberately not offered: it would quietly unlink every one of their buildings with nothing recording what it used to be. ### Logging in as an owner **Log in as** opens the portal exactly as that landlord sees it, which is the quickest way to answer "why can't I see my building?". A banner across the top shows whose account you are in; **Exit** returns you to the dashboard. This does not disturb their record — in particular it does not count as their sign-in, so the Last sign-in column keeps telling you the truth about whether they have ever used the portal themselves. ### Payments and balance Select an owner's name (or **Payments**) to open their account: what their statements have earned since their buildings first had income, what has been paid, and the **balance still owed**. Payments to landlords are irregular, so the balance runs continuously rather than month by month. **Record payment** each time money moves: - **Direction** — *Paid to owner* for a transfer to the landlord; *Received from owner* when the landlord pays you, for example to reimburse a month whose costs were more than its income. - **Date the money moved** — the real date, which can be in the past but not the future. Record historical payments with their original dates; the balance only reconciles once they are all in. - **Amount**, **Method** and **Reference** (the bank or Wise transfer reference). - **Proof of payment** — attach the bank slip or transfer receipt (PDF or image). You can save without it, but the payment shows **No proof** until one is added. - **Note to owner** is shown to the landlord in their portal. **Internal note** is never shown to them. The landlord sees every payment, its reference and note, and can open the proof files — only their own, and only while signed in. They also see the same running balance. Delete a payment only if it was recorded in error; its proof files are deleted with it and the balance changes by its amount. **Where a month's figure comes from.** In **Running balance by month**, expand a month to see its statement building by building: rent, utilities and maintenance collected, the management fee, the owner's share of other income, the costs they bear, and the net. Select a month's statement net — or a building's name — to open that month's **Profit & Loss** for this owner's buildings, or for that one building. Its **To Owner** figure is the statement net, and every row of it opens the transactions behind it, as on the Rent Roll's P\&L tab. **Why the balance can move.** It is the sum of the live statements, so a late rent payment raises the month it belongs to. And because statements follow today's building links (see *Linking a building shows its whole history* above), linking a building brings its whole history into the balance — record older payments with their real dates to reconcile. The same goes for **when expenses are booked** (Settings → Client Settings → Accounting): switching to the next month moves every past expense one month later, so past statements change, and an expense dated this month appears on next month's statement, which can show up before that month starts. ### What an owner can and cannot see Owners see, for their own buildings only: the monthly statement (rent collected, management fee, other income, costs, net payout) and the lines behind each figure, the payments made to them with proof and their running balance, their residents' names, rooms, contract dates and rent, and occupancy figures. In the statement detail, rent is listed per room and resident as **collected**; costs show date, description and supplier. Housekeeping labor never names the housekeeper, and income lines never carry free-text notes. They do **not** see any resident contact details, dates of birth, identity documents, employers, emergency contacts, payment status or arrears — and never anything about buildings that are not theirs, or the operator's own position. # Rent Roll (/docs/platform/rent-roll-financials) ## Rent Roll money tabs (/admin/rent-roll) This entry covers the last three Rent Roll tabs: **P/L · Deposits · Reports**. (Availabilities, Unit Map, Residents and Payments are covered in the companion entry.) Expenses used to be a Rent Roll tab. They have their own page now, **Expenses** (Operations → Expenses), with purchases in the same list; the old tab's address opens it. ## P/L tab Monthly profit & loss per building and portfolio-wide: income (rent, charges, move-in invoices, short-stay/check-in revenue, waitlist fees) minus expenses. A waitlist fee that later pays for a booking is counted once, inside that booking's move-in invoice — not again as a waitlist fee. How income is presented: - **Discounts are netted into rent** — a discount shows as reduced rent income, not as a separate expense line. - **Deposit settlement adjustments are excluded** from P/L income — deposit money is not revenue. - Short-stay (check-in link) payments appear as their own income lines. Expenses are grouped by their **Type**. **Bedding** is its own expense row, and when there were bedding fees or bedding costs in the period, the **Bedding** section under the statement sets the two side by side: bedding fees, bedding cost and the margin. In a managed building's owner split, bedding cost is shared the same way as the building's bedding-fee income. Which month an expense counts in: - **The month of its date**, by default. - **The month after it**, if your company books expenses in the next month (Settings → Client Settings → **Accounting**): an expense dated in May counts in June. Only expenses move. Income stays in its own month, and so do house-leader discounts, the management fee, master lease and loan repayments. - The Expenses page's **P\&L month** column shows where each expense lands. Use the **Period** filter to choose the months, and **Building** for one property. If a month's numbers look off, check the Payments tab and the Expenses page for that building first — P/L is a summary of those rows. Click a row to see the transactions behind it. On the rent row, **Covers** shows what each payment is for: the days of the month and that month's full rent, for example "18/30 days of ¥82,000" — the same line an owner sees on their statement. ## Deposits tab Tracks every security deposit: who paid it, how much is held, and where it stands (held → settlement in progress → refunded/forfeited). Deposits are collected at booking (one month's rent) and settled at move-out through the move-out report (see the Move Outs guide). The list opens on the **Unsettled only** pill, which hides reservations whose deposit is fully settled; remove the pill to see those too. Notes: - On a **room change**, the resident's deposit carries over and only the net difference is billed or refunded. - The deposit amount shown on a move-out report is an editable snapshot for that settlement — the Deposits tab remains the record of what is actually held. ## Reports tab Generates rent-roll reports — period snapshots of residents, rents, and balances used for owner reporting and bookkeeping. Pick the period, generate, and download. Past generated reports are listed here for re-download. # Rent Roll (/docs/platform/rent-roll) ## Rent Roll (/admin/rent-roll) The Rent Roll is the money-and-occupancy hub. It has eight tabs: **Availabilities · Unit Map · Residents · Payments · Expenses · P/L · Deposits · Reports**. This entry covers the first four; see the companion entry for Expenses, P/L, Deposits and Reports. ## Availabilities tab Shows every unit with its current occupancy and availability date. Remember the golden rule: **availability is date-driven**. - Future availability date → the unit shows "From \[date]" and can be reserved for after that date. - Past or empty date → "Available Now". - Resident on month-to-month → occupied indefinitely until they file a move-out notice; do not promise the unit to anyone. Use this tab to answer "what can I offer a prospect for July?" Edit availability details from the unit itself (Properties → building → unit) — this tab is the overview. Buildings that are hidden from the public site or archived are left out, in both the grid and the Units view. Buildings of some owners are left out by default: that is the **Owner is not …** pill. Remove it, or choose buildings with **+ Filter** → **Building**, to include them. The **Available Units** view lists the rooms you can offer now or from a confirmed date: "Available now", or the date a filed move-out notice frees the room. Add **+ Filter** → **Include possibly available** to also see rooms that may free up but are not confirmed. They carry an amber **Possibly from \[date]** badge, the same wording the public site uses. That date is either the end of the resident's current contract, while it is still further away than the notice window, or a departure the resident told you about without filing a notice. Neither is certain: the resident may renew month-to-month or change plans, so do not promise these rooms. Once the date arrives without a notice, the room drops off the list, and residents already on month-to-month without a notice never appear. **Available In** counts the days to either kind of date, and the count above the list includes possibly available rooms only while the filter is on. ## Unit Map tab A visual grid of each building's rooms, color-coded by occupancy. Fastest way to see at a glance which rooms are occupied, free, or turning over in a given building. ## Residents tab One row per resident (reservation), with a derived status: | Status | Meaning | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Upcoming** | Not moved in yet: the move-in date is still ahead. | | **Active** | Living in the unit, inside the contract term. | | **MTM** | Past (or near) contract end with no move-out notice — auto-renewed month-to-month — or switched to month-to-month by staff in the drawer. Still occupied, still billed full months. | | **Advertise** | A move-out notice is filed for a date still ahead — you can advertise the unit. | | **Advertising (verbal)** | The resident has said they will leave but filed no notice: an expected move-out date, still ahead, is entered in the drawer's **Expected Move-Out (Verbal)** section. The unit is advertised as possibly available from that date; billing and the contract do not change. A filed notice replaces it. | | **Past** | Moved out. | | **Cancelled** | The reservation was cancelled or refused. | The **Inbox** and **OTA Inbox** show a linked resident's status in the same words and colors. The **Stay** column reads move-in → contract end (hover it for a later arrival date). **Move-Out** stays a column of its own, because a notice can fall after the contract end, and the deposit is split into **Deposit** and **Net Deposit**. Click a resident to open their drawer: a header with their status and key facts, their household, contract and fees, payment history, adjustments, documents and move-out state (the reservation drawer — see Reservations). Common per-resident actions: - **Rent adjustments** — one-off or recurring additions/discounts to a month's rent (e.g. compensation, prorated corrections). Adjustments prorate automatically on partial months. - **Rate changes** — if rent changes mid-tenure (renewal at a new price), record a rate period rather than editing the base rent, so past months keep their historical price. - **Campaign discounts** — discounts from campaigns are shown on the resident and applied to their monthly rent for the campaign duration. ## Payments tab The rent ledger — one row per expected payment (monthly rent, charges, move-in invoices), with columns for property, unit, name, email, type, amount (plus **Received** and **Diff** when the money received differs), due date, method, status, paid date, move-out, deposit and reminder state. **+ Filter** adds type, status (overdue and to-review included), method and staff to the Building and Period filters; **Clear all** clears Building and Period too. **Statuses:** pending (not yet paid) → paid (money received). Bank-transfer and Wise payments can sit in a **verifying** state while an uploaded proof is checked. Overdue pending rows are your follow-up list. **How rent rows appear:** the system generates each month's rent from the resident's contract (base rent + utility + building maintenance where applicable, minus discounts). Move-in and move-out months are prorated automatically by day. When a resident's move-out date changes, affected rent rows are prorated or restored automatically — never hand-edit amounts to simulate proration. **Charges billed with rent:** some charges (e.g. a repair fee agreed to be collected with next month's rent) are merged into the rent invoice, so the resident pays one amount. The rent row shows the merged charge in its breakdown. Overnight-guest fees are always separate and due on the guest's check-in date — they never merge into rent. **Marking payments:** - Card / PayPal payments mark themselves paid automatically when the amount collected is exactly what is owed. A PayPal payment for a different amount, or one PayPal is still processing, is **held for review** instead: the row stays unpaid with a note showing what was collected, staff get an email, and the resident is told not to pay again. Check the amount (or wait for PayPal to complete the payment), then mark it paid or refund the difference. If you set a PayPal-paid row back to unpaid, its PayPal order and capture IDs move into the row's note, so you can still reconcile or refund against them at PayPal. - Bank transfer / Wise: the resident uploads proof from their portal; it is verified automatically (amount + recipient). Verified → paid. Unclear proofs stay in *verifying* for staff review. - Cash: mark paid manually when you receive it (cash pickups can be scheduled as appointments). - PayPay: residents can pay via the building's QR code where configured; mark paid on confirmation. - Security deposit: pays the bill from a past stay's deposit — only for a resident whose earlier move-out report is finalized and whose deposit has something left (see [Move Outs](/docs/platform/move-outs)). It cannot be edited in place; **Reset Payment** returns the money to the deposit. **Reminders:** rent reminders and charge reminders are emailed automatically (charge reminders go out at 13:00 JST). The Reminder column shows what has been sent. Late fees for overdue rent are assessed automatically by the late-fee job. **Do not "fix" intentional mismatches:** occasionally a row is deliberately off (a documented overpayment credit, a historical correction). If a number looks wrong, check the resident's timeline and ask a manager before editing. # Reservations (/docs/platform/reservations) ## Reservations (/admin/reservations) This is the heart of the dashboard. The page has tabs: **Reservations · Calendar · Reservation Links · Check In Links · Import · Room Change · Co-occupant Change · Estimate · Cancellations**. ## The reservations list Every stay is a reservation record, one line each. **Stay** shows move-in → contract end (hover it for a later arrival date), and Temp Stay, Email, Discount and Source have columns of their own. **+ Filter** narrows the list by building, payment status (Pending / Paid / Refunded / Cancelled), payment method, automation status (Awaiting Confirmation, Processing, Completed, Failed, Cancelled, Cancelled by Resident, On Waitlist, …), assigned staff (including Unassigned), discount and source, plus owner when your buildings have more than one. Use **Assign Staff** to set who is responsible for a reservation. **Reservation IDs:** - `RSV-…` — normal reservations, created either by a customer booking online or by staff via the Import tab. - `IMP-…` — historical residents bulk-imported from the old rent-roll sheets. They are real, current residents; just created differently. **How a reservation is born (online booking):** the customer completes a 5-step form (applicant info → stay details → consent → payment → confirmation). After payment, automation runs three steps: a Google Calendar move-in event is created, the contract is sent for e-signature via SignNow (to the resident, any co-occupants, and a legal representative if the resident is under 20), and confirmation emails go out. If any step fails, the reservation still exists — open it: the drawer's Overview tab shows the automation status at the top, with **Retry Automation**. ## The reservation drawer Click any row to open the drawer. Press **Esc** or click outside it to close it. On a phone the drawer fills the screen: the header (name, **Actions**, close) and the tabs stay pinned while the five key facts scroll away, and the phone's Back gesture closes the drawer. **The header** shows who the resident is and where things stand without opening a tab: their status (the same one as the Residents list), and five key facts — **Room**, **Stay** (contract start → end and the length between those dates, or the arrival date when they landed later), **Rent** (with the next bill), **Unpaid** (pending rent and charges) and **Deposit** — *held* once the move-in invoice is paid, *due* until then, and *never collected* on a reservation cancelled before it was paid. **The Actions menu** (top right) holds the one-off operations: **Schedule showing**, **Record move-out notice**, **Add charge**, **Cancel signing invitation…** (before the contract is signed), the reservation-state changes (**Reset to accepted**, **Reset to draft**, **Move to waiting list…**) and, last, the ones that end the reservation (**Cancelled by resident…**, **Refuse reservation…**, **Cancel reservation…**). Anything that changes the reservation's state asks for confirmation first. On a phone the menu opens from the bottom of the screen, and **Log in as** is in it. When you edit someone's details or the contract, **Save** stays at the bottom of the drawer while the form is open. Tabs: - **Overview** — on the left, what you act on: the booking's next step while it is in progress (waiting for the resident, automation status), **Accept Reservation** while it is a draft, the **Household** (the resident, co-occupants and the legal representative — click a person to see or edit their details and ID; their **Messaging** row shows the LINE / WhatsApp handle, **Prefers not to share a messaging app** when the applicant ticked that box on the booking form, or **Not provided**), the **Contract** (dates and monthly fees; **Show all** for the rest, **Edit** to change contract terms), and any temporary stay. On the right: e-signature and condition report, contact details, assigned staff, dashboard access, campaign and the owner-resident setting. In a narrow drawer, or on a phone, the right column moves below. - **Payments** — upcoming and past payments, the booking fee and move-in invoice, the pricing timeline and adjustments, and the deposit, each in its own section. When the resident booked with their waiting-list deposit, the booking fee shows **Waitlist Deposit** (what that deposit paid) and **Charged at Booking** (the rest): the card or PayPal payment you find at the processor is only the second part. **+ Add Charge** is in the Upcoming section; on a phone each payment is a card. A row's due date or proration note is in its **Details** column. Expand a charge to attach its proof of payment — a transfer screenshot the resident sent over LINE, for example — with **Add proof of payment** (then **Replace proof** / **Remove proof**). **Record one payment**, beside **+ Add Charge**, records one transfer or cash payment that paid several of this stay's bills at once: rent, charges, the move-in invoice, even a rent month not billed yet. Tick the bills, then enter what arrived, the date, the method and a reference. When the money does not add up, every bill is paid in full except one (the newest, or the one you mark), which records what is short or over, and the usual shortfall prompt opens for it. The bills stay separate rows tagged **Paid together**: expand one to see the payment and its other bills, and **Undo payment** to set every bill it paid back to unpaid. While a bill belongs to a recorded payment it cannot be reset, edited or deleted on its own. - **Documents** — the signed contract PDF and other documents (for a reservation converted from the waiting list, the **Waiting-list acceptance proof**: the screenshot staff attached, with who confirmed it and when), the **Reservation Form (PDF)**, which prints every resident in full (the applicant, each co-occupant and the legal representative, with their messaging app or the fact that they prefer not to share one, their emergency contact, and whether an ID was uploaded), the move-in condition report, and the contract explanation session (edit, reschedule or cancel it here). A resident with a **temporary stay** has two condition reports, one per room: **Temporary room** (open from move-in, like any report) and **Contracted room from** the transfer date (it opens on that day and locks three days later). Each has its own photos, note, status and **Edit deadline**, and the Overview shows the contracted room's report on a row of its own. The move-out inspection compares against the contracted room's report when there is one. - **Move Out** — the move-out notice (date, time window, refund method and where the refund goes) and settlement status for this resident. Under **Room check**, **No Room Check Needed** (with a reason) says the room needs no inspection: no room check is made for that move-out, even if someone is booked after it, and one already scheduled is removed. **Undo** brings it back. - **Timeline** — chronological history of everything that happened. ## Contract dates — the rules that matter - **Contract start / end** are set at booking and never change. If the agreement genuinely changes (extension, early end), staff set **override dates** with **Edit** on the drawer's Contract section — the dashboard then shows and bills by the override. - **Arrival date** (when the resident physically lands, if later than contract start) affects the calendar event, "arrives …" labels, the move-in condition report deadline, and where the stay's bar begins on the Calendar tab. **Billing always starts from the contract start date**, not the arrival date. - A contract end date in the past does **not** mean the resident left. With no move-out notice they automatically continue **month-to-month (MTM)** and are still in the unit, billed full months, until they file notice. ## Reservation Links tab Custom booking URLs for a specific person/unit with **price overrides** (rent, utility, deposit, management fee, reservation fee), an expiry date, and a single-use flag. Create one when you negotiate special terms — the customer books through the normal flow but with your prices. Click counts are tracked on each link. ## Check In Links tab Tokenized self check-in links for short-stay / minpaku guests. The guest opens the link, verifies their passport (photo ID is checked automatically), uploads documents, and pays. Payments collected through check-in links appear in the P\&L as short-stay revenue. The list has **Upcoming** and **Past** tabs. Its filters (Link Status, Portal, Original Room) and sort cover every booking in the tab, Past included, not just the page on screen. The search box finds a booking by guest name, room, OTA confirmation code or reservation number (`RSV-…`). **Portal** shows as a chip: click it to change it. To change a date in the **Stay** column, double-click it. **Guest names.** Each guest enters their **Family name** and **Given names** in two separate fields; given names can hold first, middle and further names. A guest whose ID shows a single name ticks **"I have no family name"** and enters that name alone. The passport scan pre-fills both fields for the guest to confirm, and only when both are still empty. The dashboard never guesses which word is the surname: the two parts are kept as entered and shown as `FAMILY Given names` (e.g. `RUIZ MENDEZ Javier Anthony`). Given names typed all in capitals or all in lower case are saved with a capital at the start of each name (`JAVIER ANTHONY` becomes `Javier Anthony`, `jean-pierre` becomes `Jean-Pierre`); a name typed in mixed case, such as `McKenzie`, is kept, and so is a name in Japanese, Chinese or Korean script. The same rule applies wherever a resident's given names are entered or edited: the booking form, the drawer, imports, the waiting list and check-in. Several guests are joined with `&`, followed by `+ N more resident(s)` for guests who haven't checked in yet. The same label is used on the rent-roll sheet and on calendar events. To correct a name, open the check-in link and use **Edit** on the guest's card, which has the same two fields plus **One name only**. The rent-roll row updates on the next sync. Guests who checked in before the two fields existed have only the name as they typed it. For those, filling in one field takes the other from the rest of that name: entering `WATCHORN` for "Anna Leigh WATCHORN" gives the given names `Anna Leigh`. To record a single name for them, choose **One name only**. A name that staff typed into the sheet by hand is kept, with one exception: when it contains exactly the same words as the entered name, only in a different order or case, it is rewritten as `FAMILY Given names`. Anything staff added or changed keeps the cell as typed: a corrected spelling, a note, a hyphen or comma, or a name in Japanese, Chinese or Korean script. ## Import tab Manually create a reservation for a resident who didn't book online (walk-in, agent referral, transfer from another system). **No automation runs** — you handle the contract and payments manually afterwards. ## Room Change tab Moves an existing resident to another unit. The form carries the resident's details over, and the deposit is settled as a **net difference** (new deposit minus what they already paid). A room-change calendar event is created for the destination unit. The old reservation is marked as a room change rather than a normal move-out. **Restoration fee.** The **Old Room Restoration Fee (¥)** field is filled in for you: the old room's fee for the resident's whole stay in it, or ¥0 when it was already paid when that room was first booked. You can change it. It is billed on the new contract's first invoice and booked to the old room. The new room's own fee then follows that unit's setting: billed on the same first invoice when the unit charges it at move-in, otherwise deducted from the deposit when the resident finally leaves. The form shows both before you save. Room changes recorded before these rules existed keep the amounts they were billed. If a room of the stay was never billed its fee at all (for example a room change made before these rules, where nothing was billed for the old room), that fee is deducted from the deposit when the resident finally leaves; where staff entered ¥0 for the old room, it counts as waived. ## Co-occupant Change tab Add or remove a co-occupant on an existing reservation mid-tenancy. Updated occupants flow into the contract records. **Restoration fee.** The room is not being vacated, so a co-occupant change never charges the restoration fee again. It is charged once per stay in the room: on the first booking's invoice when the unit charges it at move-in, otherwise from the deposit when the room is finally emptied, measured over the whole stay from the first move-in. ## Estimate tab Generates a price quote (rent, fees, initial cost breakdown) for a prospect without creating a reservation — useful for answering "how much would it cost to move in on X?" by email. Tick **Show reservation fee** to list the unit's reservation fee as a separate payment made at booking. The move-in payment is reduced by the same amount — the reservation fee is credited against it, just as on the move-in invoice — so the estimated total does not change. ## Cancellations tab Every cancelled reservation and every cancelled or expired waiting-list entry whose deposit was paid, with what happens to that deposit. It opens on **Refund owed** — the refunds still to make. **+ Filter** switches to **Refunded** or **Kept (income)**, and the search box finds a name, an email or an `RSV-…` / `WL-…` number. The line under the title counts each. **Refund or keep** follows how it was cancelled: | Cancelled as | The deposit is | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Cancelled by us (**Cancel reservation…**) or **Refused** | refunded | | **Cancelled by resident** | kept — the reservation deposit is non-refundable | | Left the waiting list, or the entry expired | refunded — the waiting-list deposit is refundable until the applicant accepts a room | **A kept deposit is income.** It appears in the P\&L under **Other charges**: a reservation's in the month the resident was due to move in, a waiting-list deposit's in the month you chose to keep it. A deposit you refund never counts as income. Click a reservation row to open its drawer on this page; close it and you are back on the list, filters as you left them. A row that is **Refund owed** has a **Mark refunded** button. Everything else is in the row's **⋯** menu: - **Mark refunded…** — once you have sent the money back: the date and, optionally, how (a Wise transfer, a card refund). The reservation's payment status, or the waiting-list entry's payment, becomes refunded too. It works on a **Kept** deposit as well, for a goodwill refund to a resident who cancelled: say why, and in the same step the deposit switches to refund and leaves the P\&L. - **Undo refund** — if you marked it by mistake. A refund marked on the reservation or the waiting-list entry itself is undone there. - **Keep the deposit instead…** / **Refund instead…** — when the default is wrong for this case, for example a goodwill refund to a resident who cancelled, or an applicant who had accepted a room in writing and then cancelled. Say why; the reason shows on the row. The P\&L follows at once. A deposit already refunded cannot be kept: undo the refund first. - **Open reservation** (the drawer, on this page) / **Open waiting-list entry** (its own page). A row marked refunded but still set to keep is flagged in red: its deposit is still counted as income. Use **Refund instead…** to take it out. **The resident follows it in their portal.** A cancelled or refused booking that held a deposit shows a **Deposit refund** note on its card, and a cancelled or expired waiting-list entry shows one under **Cancelled entries** on their waiting-list page: **In progress** while the refund is owed, **Refunded** with the date you entered, or **Not refundable** when the deposit is kept. Your reason, your note and your name stay in the dashboard. ## Calendar tab A timeline of every room across all properties: who is staying, when rooms turn over, and the housekeeping planned around those turnovers. **Moving through dates** - Scroll sideways to move freely. The calendar starts 30 days back and loads more days on its own as you near the end. - **‹ Week** and **Week ›** move one week; **Today** jumps back to today. From the keyboard: **←** / **→** for a week, **T** for today. - The dates on screen are shown beside the buttons. Reloading the page brings you back to the same place. **Filters** - **+ Filter** offers **Property**, **Moves** (a move-in or move-out in the loaded dates), **Missing room check** (a move-out with a notice and no room check, from a week ago to two weeks ahead, wherever the calendar is scrolled; one marked **No room check needed** does not count), **Conflicts** (a room check that falls inside someone's stay), **Room check answer** (Declined, Accepted, With Weekly Cleaning or Not Accepted) and **Room check made by** (Automatic, Edited by Staff or Staff), both judged on room checks still to be done. Each becomes a pill, such as "Conflicts only", and filters combine. - Counters above the grid show the room checks still to be done in the loaded dates: how many the cleaner **declined**, **accepted** (one bundled with a weekly cleaning counts as accepted) or has **not accepted** yet, and how many were **made automatically** or **made by staff**. Click a counter to filter to it, and again to remove it. They count the rooms your other filters leave, so the property and toggle filters change them. - Filters are remembered: leave the calendar and come back, and they are still on. Remove one with its **×**; **Clear all** resets them. - **Collapse all / Expand all** folds the properties; each property also remembers whether you folded it. On a phone it and **Legend** are under the **Filters** button, so the week buttons keep the bar to one line. **Reading the grid** — open **Legend** for the full key. - Blue bars are long-term stays, orange bars short-term (minpaku/Airbnb) stays, and a dashed bar is a temporary room during a room change. Click a bar to open the reservation. - A bar covers the days the room is **physically occupied**, which is not always the contract. It starts on the **arrival date** whenever one is recorded, so a resident who lands after their contract begins leaves the room showing as empty — and free to schedule a room check in — right up to the day they get there. It ends on the **actual departure date** when a move-out notice records that the resident left earlier than they gave notice for. What you can *sell* still follows the contract: a room someone has booked never appears as available on Rent Roll ▸ Availabilities just because nobody has moved in yet. - Grey striped bands are **partner bookings**: occupancy synced from a partner's calendar feed rather than a reservation made here. They can't be opened, and you can still schedule work on those days. - A red tint marks a turnover that needs attention — someone moves in after a move-out, and the room check is missing or set to the wrong prep type. - Circles are room checks, in their prep's colour (normal or minpaku — see **Legend**). The mark inside is the cleaner's answer: **✓** accepted (or bundled with a weekly cleaning), a red **✕** declined — it needs another cleaner — and a dashed **?** not accepted yet. A small dot on the top-left corner says the room-check automation made it: blue if it is still the automatic one, violet if staff have since changed its date or cleaner; no dot means staff made it. A red ring means the room needs re-prepping, and a pulsing red circle means the check falls inside a stay and should be deleted or rescheduled. A grey dashed circle with a dash, on the move-out date, is a move-out marked **No room check needed**: hover for the reason. It is marked and undone from the resident's **Move Out** tab. **C** and **T** squares are cleaning and other tasks for that room, and the **Visits** row shows which cleaner is already at the building that day. **Scheduling work** - Each day is split into thirds. A move-out ends after the first third and a move-in starts in the last, so the middle of a turnover day stays free. - Point at free time and click the **+** to schedule a room check, a cleaning or another task on that day. Click a room check to see its card: the cleaner, their answer, who made it (with the staff member's name when one did) and any warning. From there, **Mark accepted** / **Mark declined** record the cleaner's answer for them when they tell you by phone or message, **Edit** changes the date, cleaner or prep, **View report** opens a finished check's report, and **Cleaning event →** opens the visit it belongs to. - Without a mouse: Tab into the grid, move with the arrow keys (Ctrl + arrow moves a week), and press Enter. ## Common tasks - **Confirm a bank-transfer booking:** the resident uploads a transfer receipt; it is verified automatically and the reservation is marked paid. If verification is uncertain, open the drawer → Payments and review the proof manually. - **Cancel a reservation:** drawer → **Actions** menu → **Cancel reservation…** (we cancel, the deposit is refunded) or **Cancelled by resident…** (the reservation deposit, 予約金, is kept). Refer to it as the "reservation deposit" when writing to residents. Then follow the refund, or the kept deposit, on the **Cancellations** tab. - **Resend a contract:** while the drawer's Overview shows **Waiting for Resident**, use **Resend Acceptance Email**; to void a sent contract and issue a corrected one, **Actions** menu → **Cancel signing invitation…**. # Reviews, Overnight Guests & Resident Services (/docs/platform/reviews-and-overnight-guests) ## Reviews (/admin/reviews) The moderation queue for resident stay reviews. Residents can leave at most one review when they move out, so volume is low. Tabs filter by moderation state — approve good-faith reviews for display, reject spam/abuse. Handle new reviews promptly so published feedback stays current. ## Overnight Guests (/admin/overnight-guests) Residents must register overnight visitors. Each registration records the resident, guest details, and check-in/check-out dates. - **Overnight guest fee:** charged per stay and **due on the guest's check-in date**. It is always billed as its own separate charge — it is never merged into the monthly rent invoice. - **Capacity limits:** some units/buildings cap total guests (e.g. maximum 2 people including the resident) — check the unit's guest capacity before approving. - Review new registrations, confirm the fee charge was created, and follow up on unpaid guest fees from Rent Roll → Payments (**+ Filter** → **Type** → Charge). - **Deleting a registration:** **Delete** on a row removes the registration together with its guest fee charge. The fee charge cannot be deleted on its own from the resident's payments; it goes with the registration. The delete is refused if any money can have reached that fee: paid, part-paid, a payment proof awaiting review, or a card, PayPal or Wise payment on record. Settle or refund the charge first. - **Residents can withdraw their own guests** from the portal, but only before the guest's check-in day, and you receive an email when they do. From check-in day on, only staff can delete the registration. ## Resident Services (/admin/services) **Not available yet.** The screen exists and works, but the feature around it is not switched on: there is no menu entry anywhere in the dashboard (you can only reach it by typing the URL), there is no resident-facing page to book from, and no workspace has a single service defined. Nothing you do here reaches a resident today. It is documented so that anyone who finds the URL knows what it is, and what it is not. **What it is meant to be.** The catalogue of paid extras a resident could book from their portal — housekeeping visits, arrival help, errands, relocation help. It defines the menu only: what is offered, what it costs, and which charge type the income belongs to. It does not show bookings. The design mirrors Overnight Guests above, which is the one working example of a resident buying something from their portal: a per-use extra, billed as its own charge rather than folded into rent, and chased from Rent Roll → Payments by charge type. **Half of it is unfinished.** An offering can be marked "on request" so that a coordinator quotes it — but nothing can record a quote, and a booking can never move beyond requested or confirmed. Treat the quoting workflow as absent, not as something waiting to be used. ### Three traps, if you do define a service - **A price on an "on request" service is never billed.** Only an instant-booking service charges. The price column still displays the number. - **An instant service with no price, or a price of zero, silently behaves like a request** — it books, and nothing is charged. The list shows a zero price as ¥0 and a missing one as "Quoted", even on an instant service. - **A priced instant service must have a charge type**, or its income lands in no profit-and-loss bucket. This is enforced, but the refusal is worded differently depending on where you hit it. **Adding and editing.** **+ New Service** in the top bar opens a dialog, and a row's **Edit** opens the same one. Besides the name, category, booking mode, price and charge type, the dialog has **Description (English)** and **Description (Japanese)**. They are the text shown under the service's name to residents, and an edit loads each one as stored, so saving keeps it unless you change it. **Delete** is in the row's **⋯** menu. **Delete means two different things.** With no bookings against it, delete is permanent and immediate. With bookings, the menu item reads **Deactivate** and it deactivates instead — and there is no control on this screen to reactivate it afterwards, nor can you recreate it under the same short name. **Charge types are not edited here.** The dropdown reads the workspace-wide list from Settings → Reference Data; a wrong charge type is fixed there, not here. **Not housekeeping.** A service in the "Housekeeping" category has nothing to do with the housekeeping schedule or a cleaner's visits. It is a line on a menu, not a job. # Schedule (/docs/platform/schedule) ## Schedule (/admin/schedule) The staff calendar: who is doing what, when. It brings together staff appointments — viewings, contract-explanation meetings, cash-payment pickups, and other booked slots — plus blocked time, in one weekly view. ## What appears here - **Viewings** — prospect viewing appointments, confirmed on the [Viewings](/docs/platform/viewings) page. **Open Viewing** on one opens it there, to reschedule, cancel or follow up. - **Contract explanations** — the mandatory contract-explanation meetings residents book before move-in. - **Cash appointments** — scheduled cash payment pickups. - **Blocked slots** — time a staff member has marked unavailable. ## Staff availability & booking links Each customer-facing staff member has working hours and availability windows (managed under Settings → Staff Availability) and a personal public booking page (`/book/`), where prospects and residents pick a free slot. Booked slots land on this calendar automatically and block double-booking. ## Using the page - **+ Filter** → **Staff** shows one person's calendar; remove the pill to see everyone together. Type, Property, Date and the Missing Contract / Missing Room Check alerts filter the same way. - Add a manual appointment or blocked slot for a staff member when something is arranged by phone/LINE. - Before confirming any appointment with a customer, check here first — the calendar is the source of truth for staff availability. ## Quick answers - **"Can staff A do a viewing Friday 15:00?"** — Schedule → **+ Filter** → **Staff** → A → Friday; if the slot is free and inside their availability, book it. - **"Resident wants to pay cash"** — schedule a cash appointment so the pickup is on the calendar; the linked payment reminder is suppressed once an appointment exists. - **"Block my afternoon"** — add a blocked slot for yourself; your public booking page stops offering those times. # Settings (/docs/platform/settings) ## Settings (/admin/settings) All configuration lives here, in tabs. Most are set-and-forget — change them only when you know why. | Tab | What it configures | | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **General** | Dashboard basics: staff accounts (add/remove admin users, reset passwords), appearance. | | **Client Settings** | Company-level settings for the tenant (branding, contact details, behavior toggles). The company name, logo, contact details (email, phone, LINE, WhatsApp), office address and legal company name set here are what your residents and applicants see — on the booking page, in the resident portal, in every email, and on the move-in invoice, booking confirmation and estimate PDFs. A field left empty is left out; nothing falls back to another company's details. A logo shows on PDFs only if it is a PNG. Its **Fees & Pricing** section starts with **Utility overuse**, the company's default for apartments whose utility providers you pay: **No overuse charge** (where every company starts), usage above a fixed monthly amount, or usage above the utility fee. Each unit can set its own on its form; a platform admin must select a client before changing it. Below that, the section lists your fees: click a fee's code, its rule count or **Edit** to open it in a side drawer, where you change the fee and add, edit or delete its rules; **Save fee** and **Cancel** sit at the foot of the drawer. Its **Payments** section holds the bank-transfer details residents pay into, including the 4-digit **bank code** and 3-digit **branch code** that Japanese banking apps ask for before the names. Both appear beside the bank and branch names on the booking page, the transfer email and contracts. Its **Accounting** section sets which month of the P\&L expenses count in: **The same month** as their date, or **The next month** (an expense dated in May counts in June). Switching moves every expense the company has recorded, not just new ones, so past P\&L months and owner statements change too. A platform admin has to pick the company first. If a section holds edits you have not saved, leaving asks before discarding them: switching sub-tab, the back arrow, a link in the sidebar or elsewhere on the page, the browser's Back (or a phone's swipe-back), and closing the browser tab. | | **Auto-Replies** *(a separate page, `/admin/auto-replies`, linked from the Settings hub)* | Canned first replies for resident **maintenance reports about appliances**. See below — this is not the inbox's auto-reply. | | **Automation** | The master on/off switches for the automated behaviours: automatic room checks, housekeeping nudges, manual time entry, WhatsApp auto-reply, the **LINE staff assistant** (answering linked staff on LINE from the Staff Knowledge Base), and **Staff assistant database access** (whether the assistant may look up live availability, pricing and residents). Each one states exactly what stops when it's off. | | **Staff members** | The staff roster used for assignment, booking links and attribution — names, contact details, whether a staff member's LINE account is linked to the AI assistant (with **Unlink** to undo it), and their **AI data access** (Grant / Revoke). Distinct from the admin login accounts under General. | | **Email Templates** | The editable email templates the system sends (reminders, notices). Edit text here rather than asking for code changes. | | **SignNow** | E-signature contract templates (apartment/sharehouse × English/Japanese) and connection test. | | **Contract templates** | Write, preview and version contract templates (not yet used for signing). | | **Cleaning Staff** | Housekeeping staff records: wage rates, employment type (employee vs invoice contractor — affects paid holiday), and their dashboard login. **Add staff** (top bar) and a row's **Edit** both open a side drawer; **Set password**, **Log in as** and **Remove** are in the row's **⋯** menu. Set a staffer's password there, or they set their own via the lock icon once signed in with an emailed one-time code; there is no shared starting password. Deactivating a staff member switches their dashboard login off immediately. | | **House Rules** | The house-rule texts shown to residents and used in contracts. | | **Reference Data** | Shared lookup lists every other page picks from — amenities, train stations, bus stops, charge types, supply presets, expense categories and housekeeping task titles (each title also carries a photo category, **Photos required** or **No photos**, which decides whether the cleaner must add an after photo). One tab each. On every tab **+ Add …** is in the top action bar and opens a dialog; a row's **Edit** opens the same dialog, and **Delete** is in the row's **⋯** menu. On the task-titles tab the category and the active switch are changed in that dialog, or from the **⋯** menu, rather than with one-tap buttons. A bus stop that a recorded ride uses cannot be deleted — rename it instead. It used to have its own entry in the left sidebar; it is a Settings section now, because it is configuration rather than day-to-day work. | | **Sync Mapping** | Which Google Sheet each building is linked to. Used by the rent-roll push and by the availability feeds. | | **iCal Feeds / Channel iCals / Channel IDs** | Calendar feeds for units and OTA channel connections (per-channel calendars and listing IDs). **Sync now** is in the top bar, and the page's longer notice is folded behind **More**. | | **Sync History** | What each calendar sync run did, and what it changed. There is no manual "run the sync" button: availability for the Google-Sheet buildings arrives as ordinary iCal feeds now, refreshed automatically each morning, so there is nothing to preview or apply by hand. | | **Gap Report** *(not here — it is **Channel Gaps** under Reservations in the left sidebar)* | Which rooms a channel calendar is still blocking, or has stopped reporting on, while we advertise them as free. **Sync now** is in its top bar too, and the longer notice sits behind **More**. It sits with the reservations it protects rather than in Settings, because it is something to act on rather than something to configure. | | **Errors** | The error dashboard: runtime errors from the sites and admin, searchable, with resolve/bulk-resolve. If a resident reports "the page broke", look here. | | **Staff Availability** | Per-staff working hours and availability windows that drive the Schedule page and public booking links. | | **Freee** | Freee accounting connection settings. | | **Google Workspace** | Whether calendar events and Drive documents are created by the shared service account or by your own Google account, and which of your websites the Analytics ▸ Website tab reads from Google Analytics and Search Console. See below. | **How partner calendars are kept.** Each sync keeps one record of booked periods per room and partner calendar. From today onward the record matches the calendar exactly. Nights already past are never changed, so a stay that drops out of a calendar after checkout still counts in occupancy. Two listings of the same nights count once. Deleting a calendar frees the room from today, but its past nights stay in occupancy history. Availability on your sites only looks at stays that have not ended. **Golden rule:** settings changes take effect immediately for everyone. If you're not sure what a toggle does, ask before changing it — especially anything under Sync, SignNow, or Channel settings. ## Google Workspace (/admin/settings/google) **What it decides.** Whose Google account the system acts as when it creates a calendar event or files a document in Drive — and, once connected, which of your websites it reads traffic and search numbers for. **The default: the shared service account.** Out of the box, the platform has its own Google account — a robot, with an address ending in `gserviceaccount.com` — and you share individual calendars and Drive folders with it exactly as you would with a colleague. It can only reach what you have shared, and you can take that access away at any time from your own Google settings. Most clients never change this, and nothing is wrong with leaving it alone. **The alternative: connect your own Workspace.** Press **Connect Google Workspace** and sign in with your own Google account. Calendar events and spreadsheet access then belong to that account instead of the robot — useful if you would rather not share your calendars with an outside account, or if your organisation's policy does not allow it. **Document filing does not move on its own.** Contracts, invoices and check-in documents keep filing exactly where they file today — into the folders set under Client settings, by the service account — whether or not you connect. A folder you have configured always wins, and connecting never changes it. **If you would rather we owned the folder**, press **Create documents folder** after connecting. We make a ` Documents` folder in the Drive of the account that connected, share it with your whole domain so your staff can open what is in it, and use it **only** for document kinds that currently have no folder set. Nothing already configured is touched. **Timesheets are not included.** Housekeeping timesheets file through the service account into the folder set under Client settings, and stay that way. ### What to know before connecting - **The connection belongs to one client.** If you manage more than one, switch to the right one in the header first; the page will tell you when it has no client to attach a connection to. - **You are asked for Calendar, Sheets, Drive, Analytics and Search Console together.** Google lets you untick any of them on its consent screen. If you untick Calendar, Sheets or Drive, that feature simply keeps using the shared service account rather than breaking. Analytics and Search Console have no such fallback — see below. The page lists each one as Granted or Not granted so you can see what went through. - **Analytics and Search Console are read-only.** We can read the reports; we cannot change a property, a site, a user or a setting in either. - **The Drive permission is deliberately narrow.** It reads *"only the specific Google Drive files you use with this app"* — we can write the documents we create for you, and we cannot read, search or open anything else in your Drive. If you are asked to approve access to *all* of your Drive files, that is not this integration. - **Nothing is migrated.** Events and documents created earlier stay where they are, owned by whoever created them. The change applies from the moment you connect. - **Keep the service account's access for now.** One nightly calendar job still runs platform-wide rather than per client, so it continues to use the shared account. If you remove that account's access to your calendars entirely, that job will stop working for you. - **The documents folder belongs to the person who connected.** Under the narrow permission we ask for, we can only create it in their own My Drive — so if they leave the company and their account is deleted, the folder goes with it. If that matters, make the folder yourself in a Shared Drive, share it with our service account, and paste its id under Client settings instead; that id then wins over anything we would create. - **Renaming or moving the folder is safe. Deleting it is not.** We find it by id, not by name or location. - **Disconnecting is safe and reversible.** Press **Disconnect** and the client goes back to the shared service account immediately. The folder and its contents stay in your Drive; we simply stop filing into it. We also ask Google to withdraw the permission; if that does not go through, the page says so and you can remove it yourself from your Google account's permissions page. You can reconnect whenever you like. ### Websites for Analytics and Search Console Once connected, a second card, **Websites for Analytics and Search Console**, lists your public websites. Each row pairs a name with a Google Analytics property, a Search Console site, or both; the **Analytics ▸ Website** tab reports on whichever you pick there. - **Connected before these permissions existed?** The card says so and offers **Reconnect**. Press it once and accept the two new read-only permissions; nothing else about the connection changes. - **The drop-downs only list what the connected account can open.** They are read from Google with your own account, so if a property or site is missing, give that Google account access in Google Analytics (Admin ▸ Property access management) or Search Console (Settings ▸ Users and permissions), then reload the page. - **There is no shared-account fallback.** Unlike calendars and documents, these numbers are only ever read with your own connected account. That is what makes it impossible for one client to read another client's traffic. - **Add every site you run** — up to ten — and mark one as **primary**. The primary site is the one the Website tab opens on. - **A property you lose access to stays selected**, marked "no access from this account", so saving the card never clears it silently. Remove the row, or restore the access in Google. - **Names can be changed freely.** Renaming a row keeps it the same website, so bookmarks to the Website tab keep working. ## Appliance auto-replies (/admin/auto-replies) Reached from the Settings hub under **Guest communication**. It is its own page, not a tab of Settings. **What it is.** One canned troubleshooting message per appliance, in English and Japanese, with an on/off switch. When a resident files a maintenance report about that appliance from their own dashboard, the message is posted automatically as the first reply on their ticket — self-help before a staff member touches it ("check the plug, check the drain filter, send us a photo of the model sticker"). **It is not the inbox's auto-reply.** The inbox's WhatsApp auto-reply is a different mechanism entirely, switched on under **Automation → WhatsApp auto-reply**. Nothing on this page affects it. **It is off by default and has never fired.** All 14 appliances ship with a full bilingual draft already written, and every one of them ships **disabled**. Until someone ticks a box, residents see nothing. Each appliance is one line on the page: click its name to open its two messages and **Save**; ticking its switch opens it too, so the Save is in view. Once the box is ticked and saved, the message starts going out immediately, with no further review. ### What it covers, and what it does not - **Only the 14 appliances** — air conditioner, refrigerator, microwave, washing machine, dryer, water heater panel, stove/IH, rice cooker, kettle, oven/toaster, dishwasher, TV, Wi-Fi router, vacuum. The other 25 maintenance items a resident can pick (toilet, shower, drain, door/lock, bed, leak, mould, pest, lift, other) have no auto-reply. - **Only a resident-submitted report.** A ticket a staff member opens on the resident's behalf never triggers it, nor does a reply on an existing ticket. - **It sends no email.** The reply is written straight into the ticket thread; the resident sees it next time they open the ticket. The submission email that does go out goes to staff. - **It creates no maintenance work.** One comment, nothing else — no status change, no assignment, no project or task. Turning a ticket into real work is still the manual step on the ticket. **Clearing one language does not disable that language.** If a message has English and Japanese and you delete the English, English-speaking residents are sent the **Japanese** text — the page falls back to whichever language still has content. To stop a message going out, untick the box, or clear **both** boxes. ### Before you enable one - An auto-reply **does not count as your first response**. The ticket's first-response clock keeps running, and the "close without replying?" warning still fires. That is deliberate — a canned message is not an answer — but it means an auto-replied ticket still needs a human. - In the admin ticket view the auto-reply is currently shown with the **resident's** avatar and a "Resident" badge, even though the author name reads as support. Read the author name, not the badge, before assuming the resident said something. - Edit the drafts before enabling them. They are generic starting points, and one of them can be overwritten by a future data migration, so treat the wording as yours to own rather than as a supported default. # Social Media (/docs/platform/social-media) ## Social Media (/admin/social) AI-assisted social publishing to TikTok, Instagram, Facebook, and X. Tabs: **Queue · Compose · Media Library · X Insights · Analytics · Settings**. - **Queue** — upcoming scheduled posts. The **autopilot** generates next-day post drafts automatically every morning (including property montage videos with music and branded overlays); review the queue, edit or delete anything off-brand, and let the rest publish on schedule. - **Compose** — write a post manually: pick platforms, media from the library, caption, and schedule time. - **Media Library** — the pool of photos/videos available for posts, drawn from property photos and uploads. - **X Insights** — market-insight posts for X (housing data, market stats). - **Analytics** — performance of published posts per platform. - **Settings** — platform connections, the autopilot on/off switch and **Name in social posts**: the name AI-written posts speak for. Leave it blank to use your company name from Client Settings. If something is wrong with generated content, pause the autopilot here first, then tell a manager. **Daily habit:** skim the Queue once a day — everything in it will publish as scheduled unless you intervene. # Sodai Gomi (/docs/platform/sodai-gomi) ## Sodai Gomi (/admin/sodai-gomi) Sodai Gomi (粗大ゴミ) is oversized rubbish — a broken chair, a mattress, a shelf — that the ward collects only by appointment, with paid tickets stuck on each item. This page is where those items are reported, where the office records the booking it made with the ward, and where the person who puts the items out says they did. Every request gets a number (**SG-0001**) that never changes. ## The life of a request 1. **Requested** — somebody reported items that need to go. Nothing has been booked yet. 2. **Applied** — the office applied to the ward and entered the booking: the pickup date, the receipt number and who will put the items out. 3. **Put Out** — the items were left at the collection point. A request can be **Cancelled** while it is Requested or Applied (the reason is kept). If the ward did not take the items, **Not collected** moves a Put Out request back to Applied with a new pickup date. ## Filing a request Office staff, housekeepers, maintenance staff and house leaders can all file one. Press **New request**, or **Request Sodai Gomi** on a cleaning event, which fills in that event's building for you (for office staff it is under the **⋯** menu at the top of the cleaning event's page; housekeepers see it inline). - **Building**, and **where the items are**: a unit, or **Common area** with a short note ("bike parking, by the gate"). - **Items** — for each one: what it is, how many, **at least one photo**, and the size (width × depth × height in cm) if you can measure it. The ward asks for sizes when you apply, so a size now saves a trip later. - **Note** — anything the office should know. When a housekeeper, maintenance staff member or house leader files a request, the office is emailed. A request filed by the office itself sends no email. Until it is booked, the person who filed a request can still **Edit** it or **Cancel request**. ## The queue The list opens on everything still open (Requested and Applied). Filter by status, **ward** and building, or search by item name, receipt number, note or SG number. The ward is read from the building's Japanese address (東京都台東区… → 台東区), or from its area when the address has none, so the requests you will apply for in one sitting group together. Click a row to open the request: every item with its photos and size, the building's Japanese address with a copy button, the ward, who asked, and — once booked — the booking and its calendar event. ## Applying (office only) Apply to the ward the usual way, then open the request, press **Apply** and enter what the ward gave you: - **Receipt Number** (受付番号) and the **Booking Password**. - **Pickup Date**. - **Put-Out Date (Calendar)** — the day the items go out, which is the day the calendar event sits on. It is the day before pickup unless you pick another, and it follows the pickup date until you do. It cannot be after the pickup date. **Use the day before pickup** puts it back. - **Put-Out Place** (排出場所), if the ward named one. - **Tickets** (処理券) — one row per ticket price, with how many. The total is worked out for you. Ticket prices differ from ward to ward, so always copy them from the ward's confirmation rather than from an earlier request. - **Instructions for Them** — what the person putting the items out should know. - **Who Puts It Out** — office staff, a housekeeper or maintenance staff member, or the building's house leader. It does not have to be the person who filed the request. Press **Save booking**. **Edit booking** changes any of these later. ## The calendar event and the emails Applying creates an all-day event on the **Sodai Gomi** calendar, on the **put-out date** — the day before the pickup unless you picked another — so it shows up while there is still time to put the items out. Its title is `[who puts it out] Sodai Gomi, `, the person putting it out is invited, and the description carries the booking: collection date, the last four digits of the receipt number, tickets, instructions, the full receipt number and password, the put-out place, the items and a link back to the request. Because the password is in the event, anyone who can open that calendar — and the invited person — can read it. The emails below never contain it, and neither does the app for anyone but office staff. - Editing the booking updates the event. Cancelling a booked request deletes the event and emails the person who was going to put the items out, telling them not to. - The person putting the items out is emailed when the request is booked, again if the pickup date, the put-out date or the person changes, and a reminder on the put-out date (from 17:00). A put-out date on the pickup day itself, for a morning put-out, is reminded the evening before. The emails say which day to put the items out. - **Not collected** with a new pickup date sets the put-out date back to the day before the new pickup. - **An event comes with the booking.** A request that is only **Requested** has no event yet: there is no pickup date to put it on. It appears when the request is booked. - **No calendar set?** The request is still booked and the emails still go out; the Sodai Gomi page shows a warning at the top, and the request says "No Sodai Gomi calendar configured". Set one under Settings ▸ Client Settings ▸ Google ▸ **Sodai Gomi**, then **Edit booking** and save it again to create the event. If a calendar is set but an event could not be created at the time, the request shows what Google said, and saving the booking again retries. After you save, the request shows the event straight away. ## Putting it out Whoever was chosen presses **Mark put out** on the request. Housekeepers, maintenance staff and house leaders must add a photo of the items at the collection point; for office staff the photo is optional. ## Who sees what - **Office staff** see every request and can do everything above. - **Housekeepers and maintenance staff** see the requests they filed and the ones they were asked to put out. They can file, edit or cancel their own until it is booked, and mark put out the ones assigned to them. They never see the password. - **House leaders** see every request for their own building in their portal, file new ones for it, edit or cancel their own until booked, and mark put out the ones assigned to them. # Reports (/docs/platform/tickets) ## Reports (/admin/reports) The ticket system for resident-reported problems and requests. Residents submit reports (complaints, facility issues, cleaning problems, billing questions); staff can also open tickets internally. - **The counters** above the list (**Open**, **In Progress**, **Urgent**, **Overdue**) count every matching ticket, not just the page on screen. They follow the search and the other filters you add, but not the status and priority filters the counters themselves toggle, so each number stays the size of the queue it opens. Click one to filter by it. - **The list** opens on the **Status is Open +1** pill (open + in-progress tickets); remove it to see resolved and closed ones too. **+ Filter** adds category (Facility Issue, Cleaning, Complaint, Calculation Error, Dashboard Issue, …), priority, assignee, and label. Subject and the resident's email are separate columns. - **Ticket detail** — the conversation with the resident, status changes, and assignment. Reply to the resident from the ticket; keep status current: open → in progress → closed. The steps along the top of the side panel show where the ticket is — click a step to move it there. **Mark resolved** (or **Reopen**) and **Create task** sit in the header; the **SLA** bars fill toward the first-response (24 h) and resolution (72 h) targets and turn amber, then red, as they run out. - **On a phone or tablet** (1024 px wide or less) the ticket shows one pane at a time: a **Conversation** / **Details** tab strip at the top switches between them (swiping does too). A dot on **Details** means something there needs attention. - **The box under the conversation has two tabs.** **Reply to resident** is seen by the resident (and emails them); **Internal note** is staff-only and turns the box amber so the two can't be confused. Notes appear in the thread, amber, next to the messages they are about. If a reply fails to send, the reason shows right above **Send** and your text stays in the box — press **Send** again to retry. - **Reply to one message in particular**: hover over it and click **Reply** — your message shows the one it answers. Quoting an internal note switches the box to **Internal note**, because a note can never be quoted to the resident. **React** (the smiley) adds an emoji; residents can react to your replies too. - **Edit** or **Unsend** a message you sent: hover over it and use the pencil or the curved arrow. An edited message is marked **Edited** for the resident; an unsent one is replaced by "Message unsent" and its text and photos are deleted. The email the resident already got about a reply cannot be recalled. Residents' own messages can't be edited or unsent by staff. - A **closed** ticket shows **Reopen** in place of the box; reopen it to reply or add a note. - **✦ Improve** (reply box and internal note) polishes your own text without changing its meaning or language; **↶ Undo** restores it. **Draft a reply with AI** (the ✦ icon on the Reply tab) can be undone the same way. Attach photos with the paperclip, or drag / paste them onto the box. - **Add to KB** (top of the ticket) suggests knowledge-base entries from the thread for you to review and save. Internal notes can inform a Staff KB entry but never a customer one. - **Labels** — create and apply custom labels for your own workflow (e.g. "waiting on vendor"); manage them from the label manager. - **New report** — open a ticket on a resident's behalf when an issue arrives by phone/LINE, so tracking is in one place. - **Analytics** — response metrics per period: first-response and average-response times, volumes per category. Watch this to keep response times healthy. **Relation to Maintenance:** a ticket about a physical repair should get a linked maintenance issue for the actual work; the ticket tracks resident communication, the maintenance issue tracks the job. **System replies on a ticket.** If **Settings → Auto-Replies** has been enabled for an appliance, a resident's maintenance report about that appliance gets an automatic first comment before any staff member sees it. Two things to know when you read such a thread: the admin view currently shows that comment with the **resident's** avatar and a "Resident" badge even though the author name reads as support, so read the name rather than the badge; and it deliberately does **not** count as your first response, so the ticket still needs a human reply. See [Settings](/docs/platform/settings). # FAQ & Troubleshooting (/docs/platform/troubleshooting) ## "Where did that page go?" — moved pages Several old pages moved; old bookmarks still redirect, but here's the map: | Old location | Now lives at | | -------------------------- | ----------------------------------------- | | Residents | Rent Roll → Residents tab | | Contracts | Rent Roll → Residents (open the resident) | | Amenities / Reference Data | Settings → Reference Data | | Stations | Settings → Stations | | Email Templates | Settings → Email Templates | | SignNow | Settings → SignNow | | Sync | Settings → Sync | | Errors | Settings → Errors | | Staff Availabilities | Settings → Staff Availability | | Market | Analytics → Pricing → vs Market | | Expenses | Rent Roll → Expenses tab | ## Common confusions - **"The unit shows occupied but the contract ended"** — no move-out notice means the resident auto-renewed month-to-month and is still there. Contract end ≠ departure. - **"Availability looks wrong"** — availability is date-driven. Check the unit's availability date and any move-out notice; the label follows the date. - **"Two knowledge bases?"** — yes: Content → Knowledge Base is customer-facing (powers the public Moly assistant); AI Chat → Knowledge Base is internal staff knowledge (powers the staff assistant, contains this guide). - **"Two handbooks?"** — yes: Handbooks = resident handbooks; Minpaku Handbook = short-stay guest handbooks with entrance codes. - **"A payment amount looks wrong"** — check the resident's timeline first; move-in/move-out months prorate automatically, some charges merge into rent, and a few historical rows are intentionally unusual. Ask before "fixing" money rows. - **"My list filters disappeared"** — on most lists the filters (the pills above the table) live in the URL, so a bookmarked or plain URL opens without them; some screens do not keep them yet and reset when you leave. Re-apply them and bookmark the filtered URL. - **"An email says it sent but the resident didn't get it"** — check the record's send status (e.g. move-out report page shows failed sends) and History pages before resending. - **"I can't see a page a colleague sees"** — housekeeper accounts see a reduced dashboard; some pages are admin-only. ## When something is actually broken 1. Reload the page and try once more. 2. Check Settings → Errors — the failure is often recorded there with details. 3. Report it as a ticket (Reports) with the page URL, what you clicked, and a screenshot, or tell a manager directly. ## Who to ask - Money questions (rent, deposits, settlements) → the manager responsible for billing. - Contract/SignNow questions → the reservations manager. - Anything technical (errors, sync, integrations) → the tech/development contact. - Or ask the **AI Chat** first — it answers from this guide. # Viewings (/docs/platform/viewings) ## Viewings (/admin/viewings) Every viewing, from the moment a prospect asks to see a room until they book it or the lead is closed. Viewing requests from the websites land here, not in Contacts. The page has four tabs. Each one is a to-do list for one step, and a viewing moves from left to right: | Tab | What is in it | What you do | | --------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **To Schedule** | Requests with no date yet, oldest first | Assign a staff member in the **Staff** column, then **Confirm** a date and time, or **Cancel** | | **Upcoming** | Confirmed viewings from today on, soonest first | Change the staff member, **Reschedule**, **Send Resident Notice** to the current residents, open the calendar event, or **Cancel** | | **Follow-Up** | Viewings whose date has passed, most recent first | **Close** the lead (with a note), add a note to come back to it, or **Reschedule** if they want to come again | | **Closed** | Booked, cancelled, no-show, not interested | **Reopen** if it was closed by mistake | The sidebar badge counts the requests waiting in **To Schedule**. ## Dates and staff - **Date filter.** **To Schedule** and **Upcoming** open from today, as a **Date** pill you can change or remove. A request's date is the latest of the dates the prospect asked for, so a request whose dates have all passed drops out of view; remove the pill to see those too. **Follow-Up** and **Closed** open with no date limit. The tab counts follow the same rule. - **Staff.** Choose who shows the room straight from the **Staff** column on **To Schedule** and **Upcoming**. On an upcoming viewing, changing the staff member replaces its calendar event, which names them; nobody is emailed, because the time has not changed. - **No confirmation without a staff member.** **Confirm** stays greyed out until someone is assigned. ## Booked is automatic You never mark a viewing as booked. When the prospect makes a reservation, the system finds it by their email address or phone number and links it to the viewing: - a request still in **To Schedule**, or a viewing whose date has passed, moves to **Closed** as **Booked**; - a viewing that is still ahead stays in **Upcoming** with a **Booked** label, so you can decide whether to keep it or cancel it. Only a reservation made after the viewing request counts, within six months of it. A reservation the person already had (a resident asking to see another room) is shown under **Linked** but does not make the viewing booked. If the booking is later cancelled, the link is removed and the viewing goes back to where its date puts it. ## Everything about the same person Click a row to open the viewing. Besides the viewing itself (room, the dates they asked for, the confirmed time, staff, the residents' notice) and the prospect's details, the **Linked** section lists what else the same person has with you, found by email or phone: - their booking and any other reservations; - their other viewings (click one to open it); - their other inquiries in Contacts; - their Inbox conversations. The **Note** is your follow-up log: what they said, when to call back. It shows who last edited it and when. **Add a note** in a Follow-Up row opens the viewing with the cursor in the note. ## Confirming, rescheduling and cancelling - **Confirm**: pick one of the three dates the prospect asked for or another date, and a time; the assigned staff member is filled in. The prospect gets a confirmation email and the viewing goes on the Showings calendar. If the room is occupied, the current residents get the **showing notice** automatically, each in their own language; the dialog names them before you confirm. **+ New Viewing** does the same. - **Reschedule** moves a confirmed viewing to a new date, time or staff member and replaces the calendar event. It asks each time: - **Email the prospect** with the new time (ticked by default); - **Send the residents a notice for the new time**, offered when the residents had a notice for the old time. - **Cancel** needs a reason (cancelled by the prospect, or by you), deletes the calendar event, and asks each time: - **Email the prospect** that the viewing is cancelled (ticked by default); - **Tell the residents** that nobody is coming, offered only when they already received a notice for it. - **Close** ends a follow-up without a booking: **No-show**, **Not interested** or **Other**, with an optional note. Nothing is sent. - **Reopen** puts a closed viewing back on its date. A cancelled viewing comes back to **To Schedule**, because its calendar event was deleted: confirm a new time. Rescheduling and cancelling also email the team, as confirmations always have. If the showings calendar could not be updated, the page says so: fix the event by hand in Google Calendar. **No Showings calendar set?** The page shows a warning at the top, and confirming creates no calendar event. Set it under Settings ▸ Client Settings ▸ Google ▸ **Showings**. ## Creating a viewing yourself **+ New Viewing** books a viewing arranged by phone, LINE or in person. You can also start one from an inquiry (Contacts → **Schedule Showing**) or from a reservation (**Actions → Schedule showing**). All of them land here. ## Quick answers - **"Lead asked for a viewing tomorrow"** — Viewings → **To Schedule** → pick the staff member in the **Staff** column (check their time on the Schedule page) → **Confirm**. - **"Where is the request from last month?"** — **To Schedule** → remove the **Date** pill: requests whose dates have passed show again. - **"Prospect can't make it, wants Thursday instead"** — **Upcoming** → the viewing → **Reschedule**; leave **Email the prospect** ticked. - **"Who did we show the room to last week?"** — **Follow-Up**, or **Closed** for the ones already handled. - **"Did this viewing turn into a booking?"** — open it: **Linked** shows the booking. Closed viewings say **Booked**. # Waiting List (/docs/platform/waiting-list) ## Waiting List (/admin/waiting-list) Prospects who paid a waitlist fee to be matched with a room. Tabs: **Entries · Matches · Import**. - **Entries** — each entry records the prospect's desired move-in window (the **Move-In Window** column: the earliest and the latest day they could move in, a range for the move-in day, not the length of their stay), budget, and preferences, plus their waitlist fee payment. Statuses run from active → offered → converted (became a reservation) or expired/declined. Stale entries expire automatically. - **Matches** — the matching view: for each entry, candidate units that fit their window and preferences. Each applicant's header reads **Wants to move in \[earliest] → \[latest]** with their budget; each room below shows its own **Available from** date, so you can compare the two. A room matches when it frees up by the applicant's latest date and no more than 30 days before their earliest. Send an **offer** for a specific unit; the prospect accepts or declines from the link they receive (no login needed). A declined offer returns the entry to the pool — record the reason. - **Import** — adds one entry for a prospect who applied outside the website. Drop their filled-in form (a PDF or an image) on **Upload Form** to pre-fill the fields, then check them before you save. **Preferred Areas** and **Preferred Layouts** are toggles: click each one that applies. Under **Payment**, record how their waitlist fee was paid: the method, whether it is paid or still pending, the amount, and the PayPal or Wise transaction ID where there is one. - Click an entry for full details, offer history, and conversion actions. Converting creates a reservation for the chosen unit and links the waitlist fee to it. - **Converting needs written proof.** The waitlist fee is refundable until the prospect accepts a room, so converting records that they accepted and the fee stops being refundable. The **Convert to Reservation** dialog warns you, and **Create Reservation** stays greyed out until you tick **I have the applicant's written acceptance of this room** and attach a screenshot of it (an email, a LINE or WhatsApp message): paste it with **Ctrl+V**, drop it, or click to choose the file. The screenshot is kept on the reservation, under **Documents** → **Waiting-list acceptance proof**. A prospect who accepts an offer themselves, from the offer link, needs none of this. **Notes:** - A reservation can also be **converted to waitlist** (from the reservation side) when their desired room falls through — the reservation is closed and a linked waitlist entry carries on. Such closed reservations are not occupancy. - A waitlist fee is **not income** while the prospect waits: it is refundable money. Used for a booking, it is counted inside that booking's move-in invoice. When an entry is cancelled or expires, its fee shows on **Reservations → Cancellations** as a refund owed; if you keep it there (with a reason), it becomes income under **Other charges**. # Completing a cleaning event (/docs/help/housekeepers/completing-a-visit) Record what you actually did: when you started and stopped, how you travelled, and photographs of the room. ## Photos **Finish stays disabled until the after-photos exist.** That is deliberate, not a bug. The after-photos are what settle a later dispute about the state a room was left in, and nobody goes back for them. Take before-photos too where the room needs them. A before-and-after pair is worth far more than either on its own, because it shows what *you* changed rather than what was already there. ## Work periods Log your work periods **as you go**, not from memory at the end of the day. They are what your timesheet is built from, and a remembered time is a guess. Typing a time into the box is not the same as saving it. If you type a start time and then navigate away without saving, the box can still show what you typed while nothing has been recorded. **Save each period before you move on**, and if you come back to a cleaning event and a time looks right but the total does not, that is the thing to check. You can log more than one period on a cleaning event — start, break, resume — and they add up. ## Why your paid hours may be more than you worked This is the most common question, and the answer is in your favour. Certain tasks carry a **three-hour minimum**. If a task with that guarantee takes you ninety minutes, you are still paid for three hours. Where a cleaning event covers several guaranteed tasks, the minimums **stack**. So the hours you are paid are **the greater of** the minimum for that cleaning event and the time you actually logged — never the smaller. The "Labor" figure on a cleaning event is the **billed** hours, which already includes any minimum. It will not always equal the sum of your logged periods, and when it is larger, that is the guarantee doing its job. Do not adjust your periods to make the two match — the periods should say what really happened. Some cleaning events are **fixed price** instead. On those there is no hourly rate and no minimum; the agreed amount is the amount. Your periods still matter as a record of the work, they just do not drive the payment. ## Travel Record travel separately from work time. Transit fares are set per building and applied for you, both ways, so you do not need to keep receipts for the usual journeys. An unusual journey — a taxi with heavy items, an unexpected route — should be raised with your coordinator rather than absorbed into a work period. ## If you find something broken Report it on the cleaning event. It becomes a maintenance request automatically; you do not need to tell anyone separately, and you should not try to fix it yourself unless that is what you were sent to do. Include a photo. A request with a photo gets dealt with; a request that says "the tap is broken" usually generates a second visit just to look at it. See also [Your cleaning events](/docs/help/housekeepers/your-visits) and [Timesheets and pay](/docs/help/housekeepers/timesheets-and-pay). # For housekeepers (/docs/help/housekeepers) Cleaning and maintenance staff work in one place: the dashboard, narrowed to your role. Sign in and you land on your own cleaning events, timesheets, resident info for your buildings, and paid holiday if you are eligible. You cannot reach other staff's data or any money page. - **Cleaning events** — your schedule, room checks, and the photos a cleaning event needs before it can be marked done. - **Errands** — log a one-off task that is not a scheduled cleaning event, then start and finish it from its own page. - **My maintenance** — if your account also does maintenance work: your own jobs, and, for maintenance staff, the open backlog you can claim. Work through a job's checklist, start and finish a visit, reschedule it, or say you cannot do one. When the office asks you to handle a maintenance task (or a few checklist steps of one), you get an email and it appears under **Asked of me** — even if you only do housekeeping. Tick what you were given; press **Mark task done** when the whole task is yours. - **Sodai Gomi** — report oversized rubbish (粗大ゴミ) from the menu, or with **Request Sodai Gomi** on a cleaning event: what it is, how many, a photo, and its size if you can measure it. When the office asks you to put a booked request out, it appears in your list with the date and instructions; press **Mark put out** and add a photo once it is done. On a phone your places are in the bar at the bottom of the screen, and everything else (Display, Change password, Logout) is under **More**. To choose which places the bar holds, open **More** › **Bottom bar**. # Room checks (/docs/help/housekeepers/room-checks) A room check is the inspection between one resident leaving and the next arriving. It is assigned to you like a cleaning event, and you accept or decline it the same way — see [Your cleaning events](/docs/help/housekeepers/your-visits). What you record feeds the departing resident's **deposit settlement**. It is read by people who were not there, sometimes weeks later, and sometimes while disagreeing with the resident about money. Write it for that reader. ## Record what changed, not what is imperfect Compare against the room's **move-in condition record** where one exists. Your job is to identify what changed during this tenancy. A mark that was there when the resident arrived is not theirs. Listing it anyway is worse than saying nothing: it makes the whole report look careless, and one demonstrably unfair item is enough for a resident to reject the parts that were fair. Normal wear is not damage. A room that has been lived in for two years is expected to look lived in. ## Photograph everything you describe A sentence without a photograph is an opinion. A photograph without a sentence is ambiguous. Together they are evidence. - Photograph the **whole** of anything you are flagging, then close up. A tight crop of a stain proves it exists but not where or how big. - Photograph the room generally too, not only the problems. A settlement is easier to defend when the report shows the room as it was overall. ## Be specific "Kitchen dirty" cannot be priced, defended or fixed. "Grease on the extractor hood and the wall behind the hob, not removable with normal cleaning" can be all three. Say where it is, what it is, and — if you can tell — whether it can be cleaned or needs replacing. You are not deciding the money; you are giving the person who does something they can act on. ## If the room is fine Say so, clearly, and photograph it anyway. A clean check is a useful result: it is what lets a deposit be returned in full quickly and without argument. An empty report is not the same thing — it reads as a check that never happened. ## Timing Do the check **before** cleaning where you can, or record the state you found before you change it. Once you have cleaned, evidence of what the resident left behind is gone, and the settlement loses the thing it needed. If you are doing both in one cleaning event, photograph first. See also [Completing a cleaning event](/docs/help/housekeepers/completing-a-visit). # Signing in (/docs/help/housekeepers/signing-in) You sign in at the dashboard with your email, and either your **password** or a **6-digit PIN** sent to your email: choose **Sign in with email PIN** on the login page. If you land on the residents' sign-in instead, choose **Staff** in the switch at the top of the page. ## Sessions A session lasts about a day. You get a warning before it expires and can refresh it without losing what you are in the middle of. Refresh when you are warned rather than at the end of the day. Signing back in mid-cleaning-event is possible but it is one more thing to do with cold hands. ## Setting your password There is no shared starting password. If you have never set one, sign in with an emailed PIN, then choose a password under the lock icon at the top of the screen (on a phone: **More** › **Change password**). Use the same place to change it later. ## Forgot your password Choose **Forgot password?** on the login page and type your email. Enter the PIN we email you together with a new password, and you are signed in straight away. ## Where you land Where you land depends on what your account is allowed to do: housekeeping, maintenance, or general tasks. Two people signing in side by side can correctly see different home screens. If something you expect is missing entirely — timesheets, say — that is a permission, not a fault. Your coordinator can change it. ## What you can see You see your own cleaning events, timesheets and paid holiday. Everything else — money, settings, other people's work — is closed to your account, not just hidden. That restriction is by design — see [Roles and portals](/docs/concepts/roles-and-portals). ## Leaving If you leave, your coordinator switches your account off, and it stops working at once. See also [Your cleaning events](/docs/help/housekeepers/your-visits). # Timesheets and pay (/docs/help/housekeepers/timesheets-and-pay) A monthly timesheet per building, built from your completed cleaning events: hours worked, wage, and transit fares. You do not fill a timesheet in. It is assembled from the cleaning events you completed, so everything on it traces back to a cleaning event you closed. ## Your rate Your rate is applied **as it was at the time of each cleaning event**. A rate change applies going forward; cleaning events already recorded keep the rate that was in effect when you did them. That is why a month spanning a rate change shows two different rates. It is correct — each cleaning event was paid at the rate agreed when you did it. ## Why your hours may be higher than the time you logged Certain tasks carry a **three-hour minimum**, and where a cleaning event covers several of them the minimums stack. You are paid the greater of the minimum and the time you actually logged. So a ninety-minute guaranteed task appears as three hours. That is the guarantee, not an error, and you should not adjust your work periods to "correct" it — the periods should record what really happened. See [Completing a cleaning event](/docs/help/housekeepers/completing-a-visit). ## Fixed-fee cleaning events Some cleaning events carry a **fixed labour fee** instead of hourly pay — a flat amount agreed for that job. Those show the flat fee regardless of how long it took, and carry no minimum. ## Transit Fares are set per building and applied both ways automatically. They appear separately from your labour, and they are not part of your hourly total. ## Paid holiday Paid holiday appears only for employed staff. Contractors who invoice separately do not accrue it, and its absence on your timesheet is not a mistake if that is how you are engaged. ## When a timesheet looks wrong Work through it in this order — the first two explain nearly everything: 1. **A cleaning event finished without its work periods logged.** This is by far the most common cause. The cleaning event is closed, so it counts, but it contributes no hours. Check the cleaning events behind the total. 2. **A period that was typed but never saved.** The box can show a time that was never recorded. See the warning in [Completing a cleaning event](/docs/help/housekeepers/completing-a-visit). 3. **A cleaning event assigned to a different building.** Timesheets are per building, so the hours may be present, just on another sheet. 4. **A cleaning event still awaiting approval.** It may not be counted yet. If none of those explains it, raise it with your coordinator with the specific date and building — a total on its own cannot be investigated. # Your cleaning events (/docs/help/housekeepers/your-visits) Your scheduled cleaning events: which building, which unit, when, and what kind of work. ## Where a cleaning event comes from Cleaning events arrive two ways, and both look the same to you: - **Someone schedules one directly** — a turnover after a resident leaves, a one-off job. - **A recurring rule generates it** weeks ahead — common areas every Tuesday, for instance. You do not need to know which is which to do the work. It matters only if a recurring cleaning event is consistently wrong, in which case the *rule* needs changing rather than each generated cleaning event. ## Accept or decline — do not just leave it If an assigned cleaning event is wrong for you — wrong day, wrong building, not your job — **decline it**. An unaccepted cleaning event is visible to whoever is coordinating; a silently ignored one looks accepted until the day it is missed. Declining is not a complaint. It is the only signal the coordinator gets that the cleaning event needs to go to someone else, and the earlier it comes the easier it is to reassign. ## Cleaning event states | State | What it means | | --------------- | ----------------------------------- | | **Scheduled** | Assigned, not started. | | **In Progress** | You have started work. | | **Completed** | Finished, with the required photos. | | **Cancelled** | Called off. Do not travel to it. | Some cleaning events also need **approval** after you finish — a coordinator confirms the work before it is closed off. A cleaning event sitting in that state is not waiting on you. ## On the day Check the cleaning event before you travel. A cancellation or a time change made that morning shows here, and it is a wasted journey otherwise. Start the cleaning event when you actually start, not when you set out. Travel is recorded separately — see [Completing a cleaning event](/docs/help/housekeepers/completing-a-visit). ## If you cannot get in Report it on the cleaning event rather than abandoning it silently. An access failure is useful information: it usually means a lock code changed, a resident is still in the room, or the departure moved. All three need someone to act, and none of them is your fault. See also [Room checks](/docs/help/housekeepers/room-checks). # Documents (/docs/help/owners/documents) This section is **not built yet**. The portal shows a "coming soon" placeholder, and that is all it does today. It is intended to hold downloadable copies of your monthly owner statements. In the meantime, the figures are on [Statements](/docs/help/owners/monthly-statements), and we can send you a copy on request. This page exists so the empty section in your portal is explained rather than looking broken. ## What to do meanwhile - **Statement figures** are on [Monthly statements](/docs/help/owners/monthly-statements), with the last twelve months available. - **A copy for your accountant** can be sent on request — ask for the building and the months you need. ## Why the empty section is still there Removing it and adding it back later would move the portal's navigation twice. Leaving it in place, clearly labelled, means nothing shifts under you when it does start working — and it is honest about what exists rather than hiding a gap. # For owners (/docs/help/owners) If you own a building that is managed on OmniPM, the owner portal shows you how it is performing without you having to ask for a report. Five sections: your monthly statements, the payments made to you and your balance, who is currently in your units, occupancy over time, and documents. # Your monthly statements (/docs/help/owners/monthly-statements) One statement per building, for a single month or a run of months: choose **From** and **To** and press **Show**. A range is simply the months added together — every figure, and every list behind it, covers the whole range. The pickers reach back 36 months. Each line reads: | Line | What it is | | ------------------ | -------------------------------------------------------------------------------------------------- | | **Rent collected** | Rent taken for your units that month, **already net of any discount applied** | | **Management fee** | The fee for managing the building | | **Other income** | Your share of short-term contract, bedding, restoration and room-change fees, and of other charges | | **Your costs** | Maintenance and cleaning charged to you | | **Net** | What is payable to you | "Rent collected" being net of discounts is the line most often misread. A month with a promotion shows lower rent rather than rent plus a deduction — the discount never appears as a separate cost. If no buildings are linked to your account yet, the page says so; that is a setup step on our side, not something you can fix from here. ## Seeing what a figure is made of Select any figure — for one building, or on the **Total** row — to open the lines behind it. The panel has a tab for each column, and every list adds up to the figure you selected. | Tab | What it lists | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rent collected** | Each rent payment received: its **Paid date**, room, resident, what it covered (rent, utilities, a discount…), the month it was billed for, and under **Covers** the days of that month it pays for and the month's full rent — for example "18/30 days of ¥82,000" — so you can check the amount yourself | | **Management fee** | The rate and the rent it was charged on — or the fixed monthly amount — and the rent payments that make up that base | | **Other income** | Each fee or charge you share in, the percentage that is yours, and the payments behind it | | **Your costs** | Each cost charged to you — repairs, cleaning, supplies — with date, description and supplier, and your share where it is split | | **Net** | How the four columns combine into the net | The rent list shows only what was **collected**. It never shows what is outstanding or how a resident pays. Payments made to you, and your running balance, are on [Payments and balance](/docs/help/owners/payments). ## Reading a month that looks wrong Three things account for most surprises: - **A discount month.** Rent collected is net, so a promotion shows as *lower rent*, never as an extra cost line. Compare against the unit's normal rent rather than against last month. - **A part month.** A resident who arrived or left mid-month is billed for the days they had, so their rent is a fraction of the usual figure. The **Covers** column shows the days and the full monthly rent it was worked out from. See [Proration](/docs/concepts/proration). - **A move-in month with no rent.** A resident moving in later in the month may have had that period collected on their move-in invoice instead, so the rent appears in a different month than you expect. ## Timing A statement covers calendar months and is available once a month has closed. The pickers reach back 36 months; older months open from [Payments and balance](/docs/help/owners/payments). Figures can still move after a month closes — a late payment, a settled deposit, a maintenance invoice arriving after the fact. The statement reflects the current position rather than being frozen on a date. ## If a figure still does not look right Ask, with the building, the month and the line. Every figure traces back to individual records, so a specific question can be answered precisely; "the total seems low" cannot. # Occupancy (/docs/help/owners/occupancy) Total units, how many are occupied, on month-to-month, reserved or available, and the resulting occupancy rate. **Reserved units are not counted as occupied.** Nobody has moved in and no rent is accruing, so counting them would make the rate say something it does not mean. Occupancy counts occupied plus month-to-month units only. That is the difference between this page and a letting report: this one tracks income that exists, not income that is expected. ## The four states | State | Counted as occupied? | | ------------------ | --------------------------------------------------- | | **Occupied** | Yes | | **Month-to-month** | Yes — someone is living there and paying | | **Reserved** | **No** — contracted, not moved in, no rent accruing | | **Available** | No | ## Why reserved units are excluded Counting a reservation as occupancy would report income that has not started. A reservation can also move or fall through, and an occupancy rate that falls when nothing physically changed is worse than useless. If you want to know what is coming, [Your residents](/docs/help/owners/your-residents) shows "moving in" separately, with dates. ## Reading a trend A rate that dips for one month around a turnover is normal — a unit cannot usually be re-let for the same day it is vacated. What matters is whether it recovers. A unit sitting available across several periods is the thing worth asking about, and the answer is usually pricing, timing or works in progress. # Payments and balance (/docs/help/owners/payments) This page answers two questions: **what have you been paid**, and **what is still owed to you**. ## Your balance The figure at the top is your running balance: > the net of every monthly statement since your buildings first had income, > **less** every payment made to you, > **plus** anything you paid us. - **Balance owed to you** — we still owe you this amount. - **Balance owed to us** — more has been paid out than your statements add up to, or a month's costs were more than its income and have not yet been reimbursed. - **All settled** — the two match exactly. Payments are not tied to a single month. If two months are paid together, or a payment covers part of a month, the balance simply reflects what has actually moved. The current month is still **in progress**. Rent is still being collected and costs are still arriving, so its figure — and therefore your balance — can change until the month is complete. ## Payments Each payment shows the date the money moved, the amount, how it was sent, the bank or transfer reference, and any note we added. **Proof** links open the bank slip or transfer receipt we attached. They open only while you are signed in, and only for your own payments. A payment with no proof listed was recorded without one — ask us and we will send it. "Received from you" marks money you paid us, for example to reimburse a month whose repair costs were more than its rent. ## Balance by month Each row shows that month's statement net, what was paid either way during that month, and the balance at the end of it. Select a month to open its statement. Only months with something in them are listed. ## Past figures can move Statements reflect the current position, not a snapshot. A late rent payment recorded today raises the net of the month it belongs to, and your balance with it — you are owed that money whenever it arrives. See [Monthly statements](/docs/help/owners/monthly-statements). # Signing in (/docs/help/owners/signing-in) Enter your email address and a six-digit code is sent to it. There is no password. If you land on the residents' sign-in instead, choose **Owner** in the switch at the top of the page. Only registered owners can sign in, so the address has to be the one your buildings are linked to. A signed-in session lasts about a week before you are asked for a new code. Codes expire after ten minutes. If yours has, request another rather than retrying the old one. ## Why a code and not a password An owner signs in occasionally — monthly, often less. A password used that rarely is either forgotten or written down, and neither is good. A code sent to the address on your record avoids both. ## When a code does not arrive 1. **Check the address.** It must be the one your buildings are linked to. Another address you also own will not work, and will not tell you so — there is nothing to send a code to. To fix a typo, choose **Use a different email**. 2. **Check spam.** It is an automated message and filters sometimes take it. 3. **Request another.** Only the newest code works. A handful of requests an hour are allowed; past that, the page asks you to wait before trying again. If none of that works, the address may not be registered against your buildings yet. That is a setup step on the operator's side; ask them. ## Sessions A session lasts about a week. After that you are asked for a new code — there is nothing to renew and nothing is lost. Signing in on a phone and a laptop separately is fine; they are independent sessions. # What you can and cannot see (/docs/help/owners/what-you-can-see) You see your buildings and nothing else — not other owners' properties, not portfolio-wide figures, and not the operator's own dashboard. Within your buildings you see occupancy, contract dates, monthly rent, your statements with the rent and costs behind them, and the payments made to you. You do **not** see resident contact details, arrears or how they pay, their correspondence, or anything they have reported. A statement's detail lists the rent **collected** for each room in the month — that is what the statement is made of — with the days each payment covers and the room's monthly rent, but never what is still unpaid. That is a privacy boundary, not an oversight: your residents did not enter into an agreement with you to share it. Anything you legitimately need about a resident, ask us for and we will pass it on. ## In short | You see | You do not see | | --------------------------------------------------- | -------------------------------------- | | Your buildings and units | Any other owner's property | | Occupancy and contract dates | Resident contact details | | Monthly rent per unit | Resident arrears or payment methods | | Your statements, and the rent and costs behind them | Resident messages or reported problems | | Payments to you, with proof | | | | Portfolio-wide or operator figures | ## Why the line is drawn there Two different reasons, worth telling apart: - **Other owners' data** is not yours to see for the obvious reason. - **Your own residents' personal data** is withheld because their agreement is with the operator. They provided contact details, payment information and problem reports for the purpose of being managed — not for onward sharing with a landlord they never dealt with. ## What to do when you need something Ask. A legitimate need — a legal notice, an insurance claim, an access arrangement — is handled by the operator, who can contact the resident directly and pass on what is appropriate. That is slower than looking it up yourself, and deliberately so: it means every disclosure has someone accountable for it. ## Living in your own unit An owner residing in one of their own units is a distinct case: they occupy it, but it is not an ordinary tenancy, and it is treated separately in reporting. See [Availability](/docs/concepts/availability). # Your residents (/docs/help/owners/your-residents) Each of your units with its current resident, their move-in date, contract end date, status and monthly rent. The statuses mean: | Status | Meaning | | --------------------- | ----------------------------------------------------------------------------------- | | **Living here** | In the unit, within their contract | | **Month-to-month** | Contract end has passed with no notice given — still in the unit, no departure date | | **Moving in** | Contracted but not yet arrived | | **Moving out** | Notice given, departure date set | | **Expected to leave** | Contract ending soon, no notice yet — a forecast, not a commitment | Contact details are deliberately not shown. If you need to reach a resident, ask us and we will pass it on. ## What "expected to leave" is, and is not **"Expected to leave" is a forecast, not a commitment.** It means a contract is ending soon with no notice filed, or a resident has mentioned an intention without filing. The date can move, and it often does — many residents simply stay and roll onto month-to-month. Do not plan around it as though a departure were confirmed. "Moving out" is the status that means a notice exists with a date. ## Month-to-month is not a problem A contract ending without a notice does not mean anything is wrong. The resident stays on, billed a full month at a time, until they give notice. See [Month to month](/docs/concepts/month-to-month). For an owner it is usually good news: continued occupancy with no void and no re-letting cost. ## Rent shown here is the contracted monthly rent It is what the resident pays in a normal, whole month. A given month on your [statement](/docs/help/owners/monthly-statements) can legitimately differ — a part month, a discount, or a first month collected on the move-in invoice. ## Contact details Contact details are deliberately not shown. Your residents' agreement is with the operator, not with you, and their details were not given for onward sharing. If you need to reach a resident, ask and it will be passed on. See [What you can and cannot see](/docs/help/owners/what-you-can-see). # Ask the assistant (/docs/help/residents/assistant) The **Assistant** answers questions about your own stay in plain language, in whatever language you write in. It is there for the questions you would otherwise send to the office and wait on: the Wi-Fi password, which day the plastic goes out, where to give your move-out notice, what you owe right now. ## What it knows It answers only from three things: - **Your handbook** — the same sections you see on your building's handbook page: Wi-Fi, mailbox, garbage days, house rules, common areas, emergency information. - **Your own reservation** — your building and room, your contract dates, a temporary room if you have one, a move-out notice you have filed, and what is billed and still unpaid. - **Your workspace's resident guides** — the answers the office has written for common questions. It knows nothing about anyone else, and it never shows you another resident's details. ## What it will not do - **It cannot act for you.** It cannot book, cancel, pay, change a date or send anything to the office. It tells you which page does it, or how to reach the office. - **It does not guess.** If an amount, date or rule is not in the information above, it says so and sends you to the right page or to the office rather than estimating. Fees, penalties and notice periods are set in your contract, not by the assistant. - **It does not decide.** Whether a contract change is possible, and what it would cost, is a question for the office. **AI answers can be wrong.** For anything that matters — money, dates, your contract — check the page it points you to, or ask the office on the [Contact](/docs/help/residents/contact) page. ## Emergencies If you describe a fire, a medical emergency, a crime or anyone in danger, it tells you to call **119** (fire and ambulance) or **110** (police) first. For a gas smell, a leak or a power cut it gives your handbook's emergency information and the office contact. Do not wait on a chat in an emergency — call. ## Your conversation The conversation stays in this browser tab and is gone when you close it; **New conversation** clears it sooner. If you ask a great many questions in a short time you are asked to wait a little before asking more. # Contact and directions (/docs/help/residents/contact) Office contact details, opening hours and directions, including a map. Use this for anything that is not already a button elsewhere in the portal — maintenance requests go through [Reports](/docs/help/residents/living/report-a-problem) and rent questions through [Payments](/docs/help/residents/my-lease/pay-your-rent), both of which reach the right person faster than a phone call. ## Use the right route, and it is faster | What you need | Where | | ---------------------------------- | ---------------------------------------------------------------- | | Something broken or not working | [Report a problem](/docs/help/residents/living/report-a-problem) | | A question about rent or a payment | [Pay your rent](/docs/help/residents/my-lease/pay-your-rent) | | A receipt or invoice | [Receipts](/docs/help/residents/living/receipts) | | Registering a guest overnight | [Overnight guests](/docs/help/residents/living/overnight-guests) | | Leaving | [Give notice](/docs/help/residents/living/give-notice) | | Anything else | Here | These are not just links to the same inbox. A maintenance report creates a tracked job with your photos attached and reaches the person who schedules the work; the same thing described in a phone call has to be re-entered by someone before anything happens. ## Emergencies For anything involving safety — gas, water pouring in, fire, a lock that has failed and left you outside at night — call rather than submitting a report. A report is read during office hours. The emergency number is shown with the contact details, and it is also in your building handbook. # For residents (/docs/help/residents) Your resident portal is where you review and sign your contract, pay rent, register overnight guests, report problems, and eventually give notice. It changes as your tenancy does. Before you have signed, you will see your contract to review; once you have moved in, you will see payments and your move-in condition report instead. If something you expected is not in the sidebar, [that is usually why](/docs/help/residents/why-a-tab-is-missing). # Signing in (/docs/help/residents/signing-in) The resident portal has no password. Enter your email and choose **Send Verification Code**: a 6-digit code is sent to that address. Type it in and choose **Verify** to sign in. Use the same address your reservation was made with — the portal finds your tenancy by email. If the code does not arrive, check spam before requesting another. Codes expire after 10 minutes, on purpose: an old code in an inbox should not be a way into your tenancy. ## Why there is no password There is nothing to forget, nothing to reuse from another site, and nothing to leak. A code sent to the address on your tenancy is both simpler and safer than a password you would use twice a year. ## A code works only where you asked for it A code works only on the screen where you requested it, and expires after 10 minutes. Once you request another, only the newest one works. If you and a partner both need access, ask to be registered as co-occupants rather than sharing codes. Choose **Resend code** whenever you need a new one. If you ask for too many in a short time, the screen asks you to wait and try again. ## If the code does not arrive 1. **Check spam.** It is an automated message. 2. **Check the address you typed.** The code goes to exactly that address. If it is wrong, choose **Use a different email**, correct it and send a new code. 3. **Request another** with **Resend code**. Only the newest code works. ## If your reservation is not there Any address can receive a code, so you can be signed in with one that is not on your reservation: the portal then says "No reservations found for this email address." Sign in again with the address your reservation was made with. If that is the one you used, the address on your tenancy may be wrong or out of date — contact the office and they can correct it. ## Staying signed in A session lasts about a week. After that you are asked for a new code. Your phone and your laptop are independent, so signing in on one does not sign you out of the other. Some emails from the office — a move-in invoice, a rent reminder — have a button that opens the right page of your portal already signed in, without a code. # Why a tab is missing (/docs/help/residents/why-a-tab-is-missing) Nothing is hidden from you arbitrarily. Each item appears once it can actually do something, and the most common support question is "where is X?" when X simply is not relevant yet. | You will see | Once | | ------------------------------------------------------ | ------------------------------------------------------------- | | **Favourites**, **Showings**, **Reports**, **Contact** | Always | | **Assistant** | You have a reservation | | **Waiting List** | You have joined a waiting list | | **Contract Review** | There is a contract waiting for you to check | | **Contract Explanation** | An explanation session has been arranged | | **Payments** | Your reservation is confirmed **and** your contract is signed | | **Overnight Guests** | Your reservation is confirmed | | **Move-In Condition**, **Move Out** | Your contract is signed | | **Receipts** | Your reservation is confirmed **and** your contract is signed | | **House Leader** section | You are the house leader for your building | A coloured dot on an item means something needs you — an unreviewed contract, a date to propose, or rent that is overdue. ## The pattern Almost everything in the portal is gated on one of three things: your reservation being **confirmed**, your contract being **signed**, or you having **started something** (joined a waiting list, been offered a contract explanation). So the portal grows as your tenancy progresses. A tab that is missing today usually appears on its own once the step before it is done — no one has to enable it. ## Two that surprise people - **Payments needs both** a confirmed reservation *and* a signed contract. A confirmed booking on its own does not show it, because there is nothing to pay against until the contract exists. - **Move Out** appears once your contract is signed, not near the end of your stay. It being visible from the start does not mean anything is expected of you. ## The coloured dot A dot means something needs **you**, not that something is wrong: a contract to review, a viewing date to propose, rent that is overdue, an offer waiting for an answer. It clears itself once you have acted. If a dot persists after you have done the thing, the action may not have saved — open the item and check. ## Still missing something If a tab you expect is absent and the step before it is definitely complete, contact the office. It is more likely to be a record that has not been updated than a fault in the portal — for example a contract signed on paper that has not been marked as signed. # Duty reports (/docs/help/residents/house-leader/duty-reports) Report when a scheduled duty was missed, so there is a record rather than a disagreement. Reports go to staff, not to the other residents. This is deliberate: it keeps a shared-house problem from turning into a doorstep argument, and it gives staff something factual to act on if it keeps happening. ## What to write Keep it factual: the date, the duty, and what happened. "Bins not taken out Tuesday 14th, collection missed" is enough. You do not need to interpret it, assign blame, or suggest a consequence. A one-off is usually a genuine mistake; the value of a report is that a **pattern** becomes visible. ## Why reports go to staff Reports go to staff, **not** to the other residents. That is deliberate: it keeps a shared-house problem from turning into a doorstep argument, and it means you do not have to be the one enforcing anything. ## When to file one - A scheduled duty was missed. - It has happened more than once. - You would otherwise have to have an awkward conversation about it. Not for something broken — that is a [problem report](/docs/help/residents/living/report-a-problem). Not for a rota that is simply out of date — that is [yours to fix](/docs/help/residents/house-leader/garbage-schedule). # The garbage schedule (/docs/help/residents/house-leader/garbage-schedule) Set the rota for taking rubbish to the collection point, week by week. You can copy last week's rota forward rather than rebuilding it each time. Collection days and the burnable / non-burnable / recyclable split are set per building, because they are set by the municipality — the rota says who, not when. Keep it current. It is the thing residents check when they are unsure, and an out-of-date rota causes more friction than no rota. ## What the rota does and does not set The rota says **who**, not **when**. Collection days and the burnable / non-burnable / recyclable split are set per building, because they are set by the municipality — you cannot change them and neither can staff. ## Keeping it current Keep it up to date. It is the thing residents check when they are unsure, and an out-of-date rota causes more friction than no rota at all — someone follows it, gets it wrong, and reasonably feels they did what they were told. You can copy last week's rota forward rather than rebuilding it each time, which makes keeping it current a few seconds' work. ## When someone moves in or out Update the rota then, rather than when their turn comes round. A departed resident sitting in next week's slot is the most common reason a collection gets missed. ## When a turn is missed File a [duty report](/docs/help/residents/house-leader/duty-reports). It creates a record rather than a doorstep argument, and it gives staff something factual to act on if it keeps happening. # Being a house leader (/docs/help/residents/house-leader) A house leader is a resident who helps run the shared parts of a building. If you are one, an extra **House Leader** section appears in your portal; nobody else in the building sees it. It covers four jobs: asking for supplies when the building runs out, keeping the rubbish rota, reporting when a duty was missed, and reporting oversized rubbish (Sodai Gomi) — and putting it out when staff ask you to. Being a house leader is a role, not a job title — it usually comes with a discount on your rent, arranged separately by staff. ## What the role is Being a house leader is a role, not a job title. It usually comes with a discount on your rent, arranged separately by staff — it is not something you claim from the portal. You are not responsible for cleaning the building, resolving disputes between residents, or enforcing rules. You keep the shared logistics running and tell staff when something is not working. ## What you are not expected to do If something needs confronting — a resident repeatedly ignoring the rota, noise, anything uncomfortable — that is a [duty report](/docs/help/residents/house-leader/duty-reports) or a [problem report](/docs/help/residents/living/report-a-problem), not a conversation you have to have. Reports go to staff, not to the other residents. ## Stepping down Tell staff. The role moves to another resident, and your discount arrangement ends with it. Nothing in the portal changes until they make the change. # Maintenance (/docs/help/residents/house-leader/maintenance) Sometimes the office asks the house leader to help with a small maintenance job in the building — changing a bulb in the hallway, checking a bin store, letting a contractor know where something is. When they do, you get an email, and the job appears on the **Maintenance** page of your portal. ## What you see Each job shows what it is, where, and when it is due, with its checklist. Tick each item as you finish it. - If the office gave you the **whole task**, you can tick every item and press **Mark task done** when it is finished. - If they gave you **only some checklist items**, you tick those; the rest of the task is someone else's, and they mark it done. You never see prices or receipts here — those stay with the office. ## When you cannot do it Tell the office as soon as you can, so they can ask someone else. Nothing in the portal needs to change; they reassign it. # Sodai Gomi (/docs/help/residents/house-leader/sodai-gomi) Sodai Gomi (粗大ゴミ) is oversized rubbish — furniture, a mattress, a large appliance — that the ward only collects by appointment. Report it here; staff book the collection with the ward. ## Reporting items Press **New request** and say where the items are — a room, or a common area with a short note — then add each item: what it is, how many, at least one photo, and its size in centimetres if you can measure it. Staff need the size to book, so measuring now saves a second visit. You see every request for your building, whoever reported it. Until staff have booked it, you can still edit or cancel a request you made. ## When you are asked to put it out Staff sometimes ask the house leader to put the items out. If they choose you, you get an email with the collection date, the collection number, the tickets and any instructions, and a reminder the evening before. The request shows the same details in your portal. Put the items out at the time and place the booking gives, with the tickets attached — wards differ, so follow the instructions on the request rather than habit. Then press **Put out** and add a photo of the items where you left them. If you cannot do it, tell staff as soon as you can so they can ask someone else. If staff cancel a collection you were asked to put out, you get an email saying so — do not put those items out. # Supply requests (/docs/help/residents/house-leader/supply-requests) Request consumables for the shared areas — cleaning products, bin bags, light bulbs — and mark a request urgent when something has actually run out rather than is about to. Ask before the cupboard is empty. Requests are batched into ordinary deliveries; urgent ones are not, which is why they should stay rare enough to mean something. ## Ask before the cupboard is empty Requests are batched into ordinary deliveries. Urgent ones are not — which is why they should stay rare enough to mean something. Mark a request urgent when something **has actually run out**, not when it is about to. If everything is urgent, nothing is. ## What to include - **What**, specifically. "Bin bags, 45L" rather than "bin bags". - **How many**, and roughly how long that usually lasts. - **Where** it goes, if the building has more than one shared area. ## What this is not for Supplies for the shared parts of the building only. Something broken is a [problem report](/docs/help/residents/living/report-a-problem); something you bought yourself is a [receipt claim](/docs/help/residents/living/receipts) — and that needs agreeing first. # Favourites (/docs/help/residents/searching/favourites) Save any room you are considering and it appears here, so you are not keeping a list of tabs open. Favourites are tied to your account, not to the browser, so the list follows you between your phone and your laptop. Removing one does not affect anything else — it is a shortlist, not an application. ## What a favourite is not Saving a room does **not** hold it, reserve it, or tell anyone you are interested. A favourited room can be let to someone else the same day. If you want a room, arrange a [viewing](/docs/help/residents/searching/showings) or contact the office. If nothing suitable is free, join the [waiting list](/docs/help/residents/searching/waiting-list). ## Practical notes - The list is tied to your **account**, not the browser, so it follows you between your phone and your laptop. - Removing one changes nothing else. It is a shortlist. - A room that has been let may disappear from the list, or show as unavailable. That is the listing being kept honest, not the favourite being lost. # Showings (/docs/help/residents/searching/showings) Your upcoming and past viewings, each with its date, the room, and the staff member meeting you, including how to contact them. If you need to move or cancel a viewing, contact the staff member shown on it rather than booking a second slot — a duplicate booking holds a time nobody needs. ## Changing or cancelling Contact the staff member shown on the viewing rather than booking a second slot. A duplicate booking holds a time nobody needs, and on a busy property that is a slot another applicant could have used. Cancel as early as you can if you no longer want to go. There is no penalty, and it frees the room and the person. ## On the day Bring photo identification if you were asked for it. Arrive on time — viewings are often booked back to back, and a late arrival usually becomes a shorter viewing rather than a later one. If you are running late, message the staff member directly using the contact shown on the viewing. ## After a viewing A viewing is not an application and does not hold the room. If you want it, say so promptly — rooms shown to several people in a day are usually taken by whoever confirms first. # The waiting list (/docs/help/residents/searching/waiting-list) When nothing suitable is free, you can join a waiting list with the dates and kind of room you want. This tab appears only once you have an entry. When a matching room comes up you are sent an **offer**, which you accept or decline from here. Offers expire — they are held for you, which means they are held *from* everyone else, so they cannot be held indefinitely. You can edit your preferences while you wait, and retry the joining fee if a payment did not go through. ## How an offer works When a matching room comes up you are sent an **offer**. Accept or decline it from this tab. **Offers expire.** While an offer is open the room is held for you — which means it is held *from* everyone else — so it cannot be held indefinitely. Letting one lapse without answering is the same as declining, but slower for everybody. Declining does not remove you from the list. You stay on it for the next match. ## Your preferences Edit them while you wait. Dates, budget and the kind of room you want all drive what you get matched against, so preferences that no longer reflect what you want produce offers you will decline. The **desired move-in period** is a window for the day you move in: the earliest and the latest day you could move in. It is not how long you will stay. Fields marked \* are required when you join. Widening your dates or areas is usually what turns a quiet waiting list into offers. ## An entry with another company You can have one open waiting list entry at a time. If yours is with a different management company from the one whose portal you are signed in to, it is listed here with that company's contact details. To change it, pay for it or cancel it, contact them; it cannot be managed from this portal. ## The joining fee Where a joining fee applies and a payment did not go through, you can retry it from here. An entry whose fee has not been paid may not be matched. If you joined a while ago and have heard nothing, checking the payment status is the first thing to look at. ## If you leave the list You can cancel your entry from this tab. A cancelled or expired entry whose joining fee was paid stays here, under **Cancelled entries**, with a **Deposit refund** note: **In progress** while it is being refunded, **Refunded** with the date it was sent, or **Not refundable** when the terms you agreed to do not refund it. If the note does not match what you were told, use **Contact us** on the note. ## If you are offered a room and accept The offer converts into a reservation, and the portal changes accordingly — contract review appears, and the waiting-list tab stops being the centre of things. See [Why a tab is missing](/docs/help/residents/why-a-tab-is-missing). Pricing is taken at the point the reservation is created, not when you joined the list. See [Pricing snapshots](/docs/concepts/pricing-snapshots). # Giving notice (/docs/help/residents/living/give-notice) Filing notice is what ends your tenancy. Until it exists, your tenancy continues even after your contract end date has passed — see [month-to-month](/docs/concepts/month-to-month). Give the date you are leaving, which is your **last day in the room**, not the day after. Before you confirm, the form shows what the departure will cost: the final month's rent, prorated to that date, and any short-notice or early-leaving charge. The notice period runs from the day you file, not from the day you decided. Filing a week late can move you into a charge, so file as soon as you know. Those charges are billed to you. They are not taken out of your deposit — see [deposits](/docs/concepts/deposits) for why that distinction matters. Moving to another room in the same portfolio is a **room change**, not a move-out: ask staff rather than filing notice, because a room change carries your deposit across and raises no leaving charge. ## Before you file Two decisions are worth making first, because they are hard to undo: - **Is this a move-out or a room change?** Moving to another room in the same portfolio is a **room change**, not a move-out. Ask staff rather than filing notice: a room change carries your deposit across and raises no leaving charge. - **Is the date right?** Give your **last day in the room**, not the day after. Rent is charged through that day. ## What the form shows you Before you confirm, the form shows what the departure will cost: the final month's rent, prorated to your date, and any short-notice or early-leaving charge. The notice period runs **from the day you file**, not from the day you decided. Filing a week late can move you into a charge that filing promptly would have avoided, so file as soon as you know — even if the date might shift slightly. **The longer month-to-month period applies if you were already month-to-month on the day you filed.** Month-to-month starts earlier than most people expect: it begins when your notice window opens — one notice period *before* your contract end date — not when the contract ends. If you have not given notice by then, your contract has already rolled over. So filing **early**, before that window opens, holds you to your contract's own notice period, even if the date you are leaving falls a little past your contract end. Staying a few extra days does not change the rule you were held to when you filed. Filing **inside** the window means the longer period applies, even if your contract end date has not arrived yet. ## Two charges, never both If you leave before your contract ends, or with less notice than required, one charge may apply. They never stack: only the larger of the two is billed. See [Move-out penalties](/docs/concepts/move-out-penalties). **Those charges are billed to you.** They are not taken out of your deposit — though anything still unpaid at settlement is netted off it then. See [Deposits](/docs/concepts/deposits). ## After you file Your move-out gets its own page — see [The settlement](/docs/help/residents/living/the-settlement). If your plans change, tell staff rather than filing a second notice. A date can be moved, and moving it recalculates the final month automatically. # Your move-in condition report (/docs/help/residents/living/move-in-condition) When you move in, photograph and describe anything already marked, broken or worn, and upload it here. At move-out, this is the record that separates damage that was already there from damage attributed to you. **It locks at its deadline.** After that you cannot add to it, and anything you did not record is no longer distinguishable from wear you caused. This is the single most valuable thing you can do in your first days, and it is the one most often skipped. The window is measured from when you actually arrive, not from your contract start — arriving weeks late does not cost you the report. Photos and video both work. Some camera formats are rejected with an explanation; if that happens, a normal photo from your phone's default camera app will upload. ## What to record Anything already marked, broken or worn. Be thorough and be boring about it: - Marks on walls, floors and worktops. - Scratches, chips, dents — furniture and fittings included. - Anything that does not work: a slow drain, a loose handle, a blind that sticks. - Appliances, inside and out. - The bathroom, in detail. It is where most disputes happen. Photograph the whole of something and then close up. A tight crop proves a mark exists but not where or how large. ## The deadline **It locks at its deadline.** After that you cannot add to it, and anything you did not record is no longer distinguishable from wear you caused. This is the single most valuable thing you can do in your first days, and the one most often skipped. The window is measured from when you actually **arrive**, not from your contract start — arriving weeks late does not cost you the report. See [Contract dates](/docs/concepts/contract-dates). ## If you start in a temporary room If you live in a temporary room first and move into your own room later, you get **two reports**, one for each room, shown one above the other. - **The temporary room's report** works like any other: it opens when you move in and locks at its deadline. - **Your own room's report** opens on the day you move in there, and locks a few days after. Until that day it shows the date it opens. Fill in both. At move-out your room is inspected against **your own room's** report, so a mark that was there before you moved in is only protected if you photographed it after the move. ## Formats Photos and video both work. Some camera formats are rejected with an explanation; if that happens, a normal photo from your phone's default camera app will upload. ## Why it matters later At move-out the room is inspected against this record. Its job is to establish what changed **during** your tenancy — so a mark you recorded on day two cannot be charged to you on your last day. See [The settlement](/docs/help/residents/living/the-settlement). # Registering an overnight guest (/docs/help/residents/living/overnight-guests) Register anyone staying overnight, with their name and the dates. If your building charges for guests, the fee is **per night** and the form shows you the nights and the total before you submit — no surprise on the next bill. Register in advance rather than afterwards. An unregistered guest is a house-rules problem for everyone sharing the building, not an administrative detail. ## Register in advance An unregistered guest is a house-rules problem for everyone sharing the building, not an administrative detail. Register before they arrive, not after they leave. Registration exists for two reasons that matter to you as much as to anyone else: in an emergency, whoever responds needs to know who is in the building; and in a shared house, the other residents agreed to a rule about guests too. ## The fee, if your building has one Where your building charges for guests, the fee is **per night**, and the form shows the nights and the total before you submit. There is no surprise on the next bill. Whether a fee applies, and how much, is set by your workspace — see [The fee catalogue](/docs/concepts/the-fee-catalogue). Another resident's building is not a guide to yours. ## Longer stays A guest staying repeatedly, or for an extended period, is usually a co-occupant rather than a guest. That is a change to your contract, not a registration — speak to staff. The distinction is not bureaucratic: occupancy affects the guest surcharge on your bill, insurance, and the house rules everyone else agreed to. ## Changing or cancelling If plans change, update the registration. A cancelled stay should not be left registered — where a fee applies, it is calculated from the nights recorded. # Submitting a receipt (/docs/help/residents/living/receipts) If you have bought something for the building — cleaning supplies, a replacement part — upload the receipt here to be reimbursed. The line items are read from the photo automatically so you do not have to type them, but check them before submitting: the extraction is a convenience, not an authority. Claim only what was agreed in advance. A receipt is a claim, not an approval. ## Get agreement first **A receipt is a claim, not an approval.** Claim only what was agreed in advance. Uploading a receipt for something nobody asked for does not create an obligation to reimburse it. If something needs buying, raise it first — through your house leader for shared supplies, or as a [report](/docs/help/residents/living/report-a-problem) for anything else. ## Check the extracted lines The line items are read from the photo automatically so you do not have to type them. **Check them before submitting**: the extraction is a convenience, not an authority, and it can misread a smudged total or a folded receipt. The amount you submit is the amount that gets considered, so a misread figure costs you either way. ## Photographing a receipt - Flat, in good light, with the whole receipt in frame. - Make sure the **total, the date and the merchant** are legible. - Long receipts: one photo per part rather than one distant photo of all of it. ## After you submit The claim is reviewed. Reimbursement follows once approved, and how it reaches you depends on your workspace's arrangement — as a credit or a payment. If a claim is declined you are told why, and it is nearly always because it was not agreed in advance. # Reporting a problem (/docs/help/residents/living/report-a-problem) Report anything that needs attention — a broken appliance, a leak, a noise problem, a question about your tenancy — and attach photos. Each report becomes a conversation you can follow: staff reply on the report itself, so you can see what was said and when, instead of losing it in a chat thread. A repair is usually two things at once: the conversation with you, and the physical work. You only need to file the first; staff raise the second from it. Use this rather than messaging a staff member directly. A report is visible to whoever is on duty, so it survives holidays, handovers and people leaving. ## What makes a report actionable - **Say where.** The room, and whereabouts in it. - **Say what happens**, not just what is wrong. "The shower runs cold after two minutes" is fixable; "the shower is broken" needs a visit to find out what you meant. - **Attach photos.** A photo usually saves an entire visit. - **Say when it started**, and whether it is getting worse. ## What happens next A repair is usually two things at once: the conversation with you, and the physical work. **You only need to file the first** — staff raise the work from it, and it may be grouped with other jobs in your building into one visit. Staff reply on the report itself, so you can see what was said and when, instead of losing it in a chat thread. To answer one message in particular, hover over it (on a phone, press and hold it) and choose **Reply** — your answer shows the message it refers to. You can react with an emoji the same way. ## Use this rather than messaging someone A report is visible to whoever is on duty, so it survives holidays, handovers and people leaving. A message to one staff member does not. ## Emergencies Anything involving safety — gas, water pouring in, fire, a failed lock leaving you outside at night — needs a phone call, not a report. Reports are read during office hours. The emergency number is on [Contact](/docs/help/residents/contact) and in your building handbook. # Getting your deposit back (/docs/help/residents/living/the-settlement) After you give notice, your move-out gets its own page: the current status, the key dates, and a channel to talk to staff about it. The room is inspected after you leave. Anything deducted is listed as its own line with a reason, and set against your [move-in condition report](/docs/help/residents/living/move-in-condition) — which is why that report matters so much. The statement shows the deposit held, each deduction, any unpaid charges netted off, and what is left to return to you. If a deduction looks wrong, raise it on that page within the window shown; that is what the window is for. A remaining balance is still owed if the deductions come to more than the deposit. The deposit is a security, not a cap. Once the window closes the amounts are final and can no longer be disputed — but the channel stays open. You can keep asking there while the refund is arranged, and staff reply in the same thread. To answer one message in particular, hover over it (on a phone, press and hold it) and choose **Reply**; you can react with an emoji the same way. ## The stages | Stage | What is happening | | ---------------- | ------------------------------------------------------------------- | | **Notice filed** | Your date is set; the final month is prorated to it. | | **Inspection** | The room is checked after you leave. | | **Settled** | Deductions and unpaid amounts are worked out; the figure is agreed. | | **Refunded** | The money has actually been sent. | **"Settled" and "refunded" are different.** A settlement concluding that nothing is returnable is a complete, correct outcome — but it is a **zero refund**, not a refund. Only "refunded" means money has left. ## Deductions Anything deducted is listed as its own line with a reason, set against your [move-in condition report](/docs/help/residents/living/move-in-condition) — which is why that report matters so much. Normal wear is not damage. A room lived in for two years is expected to look lived in. ## If a deduction looks wrong Raise it **on that page, within the window shown**. That is what the window is for, and it is much easier to resolve while the photographs and the inspector's notes are fresh. Be specific: which line, and why. "The cleaning charge is unfair" is harder to act on than "the mark on the bedroom wall is in my move-in photos, dated the 3rd". ## If you are staying with us at another place If you have another current or upcoming stay with us, part of your deposit can be put toward what you owe there — rent, the move-in invoice or a charge — instead of being refunded. Your settlement page then says how much went to which place, and anything left is refunded as usual. ## If deductions exceed the deposit A remaining balance is still owed. **The deposit is a security, not a cap** — it reduces what you owe, it does not limit it. Equally, unpaid rent or charges from during your tenancy are netted off at this point, which is why a settlement can be smaller than you expected even with no damage at all. See [Deposits](/docs/concepts/deposits). # Your contract explanation (/docs/help/residents/my-lease/contract-explanation) A member of staff walks you through the contract before you sign it, and this is where that session is arranged. The tab appears only when one has been set up for you. Depending on how it was arranged you will either propose three dates that suit you, or pick from slots already offered. Once it is confirmed, the joining details appear here. A dot on the tab means you still need to propose or choose a time. ## What the session is A member of staff walks you through the contract before you sign it: what each fee is, what the notice period means in practice, and what happens at the end. It is a chance to ask about anything you did not want to ask in writing. Nothing is signed during it. ## Arranging it Depending on how it was set up you will either **propose three dates** that suit you, or **pick from slots** already offered. Once confirmed, the joining details appear here. A dot on the tab means you still need to propose or choose a time. Propose dates that genuinely work. Three near-identical times on the same afternoon usually means none of them fits the other side either, and the round trip starts again. ## If you need to change it Use the contact shown with the booking. Rearranging is normal; not turning up delays your contract, because the explanation usually has to happen before signing. ## Language Say if you would prefer the session in another language when you propose times, rather than discovering the mismatch on the call. # Reviewing your contract (/docs/help/residents/my-lease/contract-review) Before a contract is issued you are asked to check what it will say: who is living there, the dates, and the monthly cost. This is the cheap moment to fix a mistake. Once a contract has been signed, changing a date means an amendment and, depending on what changed, money. Confirming here includes acknowledging the notice period you will have to give to leave. Read that part rather than clicking past it — it is the term residents most often discover too late. ## What to check, in order 1. **Names.** Everyone who will live there should be listed. Adding someone later is an amendment, not an edit. 2. **Dates.** Your move-in date and contract end date drive the rent. A date that is wrong here is money that is wrong later. 3. **The monthly cost**, line by line — see [Understanding your bill](/docs/help/residents/my-lease/understanding-your-bill). 4. **The room.** Building and unit, not just the building. 5. **The notice period**, below. ## The notice period Confirming here includes acknowledging the notice you must give to leave. Read it rather than clicking past it — it is the term residents most often discover too late, usually when they have already committed to a moving date. Leaving with less notice than agreed, or before your contract ends, can attract a charge. See [Move-out penalties](/docs/concepts/move-out-penalties). ## Why this moment matters This is the cheap point to fix a mistake. Once a contract is signed, changing a date means an amendment, and depending on what changed, money. Nothing here is a commitment to sign — you are confirming that what the contract will say matches what you agreed. ## If something is wrong Say so here rather than signing and sorting it out afterwards. Raising it now costs a message; raising it after signature costs an amendment. # Paying your rent (/docs/help/residents/my-lease/pay-your-rent) Everything you owe and everything you have paid, in one list: your move-in invoice first, then rent month by month. The tab appears once your reservation is confirmed **and** your contract is signed — before that there is nothing to pay. A dot on it means something is overdue. You can pay by card, or upload proof of a bank or app transfer; a cash appointment can be scheduled instead where your workspace offers it. Whichever you use, pay against the row shown here rather than sending money against an old reference — that is what keeps your ledger straight. ## Pay against the row Pay against the row shown in the list, not against an old reference or a remembered bank detail. Payments are matched to the charge they were made against; money sent against a stale reference has to be found and reallocated by hand, and until it is, your account still shows the amount as unpaid. ## Proof of transfer If you pay by bank or app transfer, upload the proof here. That is what lets the payment be matched before it clears. Upload the confirmation showing the **amount, the date and the recipient**. A screenshot of just a success message cannot be matched to anything. ## If a payment is late A dot on the tab means something is overdue. Pay it if you can; if you cannot, say so early. A late payment that has been discussed is an arrangement, and one that has not is a debt collection problem — and unpaid amounts are also netted off your deposit at the end. See [Deposits](/docs/concepts/deposits). ## One transfer for several bills If one transfer paid several bills (a month's rent and a charge, say), each bill still shows on its own, marked paid, with a **Paid together** line giving the transfer's total and how many bills it covered. ## Receipts Every payment produces a receipt, available from [Receipts](/docs/help/residents/living/receipts). # Payment methods and saved cards (/docs/help/residents/my-lease/payment-methods) Cards you have saved, which one is the default, and the ability to add or remove them. Card details are held by the payment provider, not by the platform — removing a card here removes it everywhere it would have been offered to you. Removing your only card does not cancel anything; it just means the next payment needs a method choosing. ## Where card details actually live Card details are held by the payment provider, not by the platform. Nobody at the office can see your card number, and removing a card here removes it everywhere it would have been offered to you. ## Removing your only card This does not cancel anything and does not stop your tenancy. It just means the next payment needs a method choosing — you will be asked at the time. ## Choosing a default The default is what is offered first. If you keep more than one card, make the default the one you actually want charged, rather than relying on picking correctly each month. ## If a payment fails A failed card payment does not mean the charge has gone away. It stays on [Pay your rent](/docs/help/residents/my-lease/pay-your-rent) as outstanding until it is paid by some method. Common causes are an expired card, a bank blocking an unfamiliar merchant, or a limit. Updating the card here and retrying resolves most of them. # Understanding your bill (/docs/help/residents/my-lease/understanding-your-bill) Your monthly total is not one number. It is rent plus whatever else your contract includes — typically a utility fee and a building maintenance fee, sometimes a guest surcharge — and any discount is shown as its own line. **Rent never silently includes utilities.** They are separate lines because they are separate agreements, and seeing them separately is how you can check them. Two months in a tenancy usually look different from the rest: the first and the last. Both are normally charged for the days you actually occupy the room rather than the whole month — see [proration](/docs/concepts/proration). Your first month may also be folded into the move-in invoice instead of appearing as rent. Amounts and which fees apply are set by your workspace, so another resident's bill is not a guide to yours. ## What a normal month looks like | Line | Notes | | ------------------------ | --------------------------------------------------------------------------------------------------------- | | **Rent** | The base amount for the room. | | **Utility fee** | Where your contract includes one. A fixed monthly fee, not metered usage, unless you were told otherwise. | | **Building maintenance** | Upkeep of shared parts of the building. | | **Guest surcharge** | Only where more than one person occupies the room. | | **Discount** | Shown as its own line, reducing the total. | ## Why your first and last months differ - **A part month is billed by day**, at both ends of the tenancy. February and a 31-day month give different daily rates for the same rent, which is correct. - **Your first month may not appear as rent at all.** It is often collected on the move-in invoice, together with the deposit and one-off fees. If you move in after the middle of the month, that invoice can cover the following whole month too — so your first ordinary rent charge may be later than you expect. See [Proration](/docs/concepts/proration) and [Contract dates](/docs/concepts/contract-dates). ## Rounding Each line is rounded to the yen on its own, and the total is their sum. On a part month that can differ by a yen from multiplying the monthly total by a fraction yourself. The itemised figure is the one you are charged. ## If something looks wrong Compare against your contract first — it states the fees that apply to you. Amounts and which fees apply are set by your workspace, so another resident's bill is not a guide to yours. Then ask, quoting the month and the line. A specific question gets a specific answer; "my rent seems high" cannot be checked. # Your reservation (/docs/help/residents/my-lease/your-reservation) Your tenancy as the platform holds it: the room, your move-in date, your contract end date, and what stage you are at. Your documents live here too — the signed contract, your confirmation, and the move-in package — available to download at any time. Past tenancies stay listed, so a reference request years later does not depend on your own filing. If a date here does not match what you agreed, say so before signing rather than after: dates drive the rent. ## Your documents The signed contract, your confirmation, and the move-in package are all downloadable here, at any time. Past tenancies stay listed. A reference request or a tax query years later does not depend on your own filing. ## Check the dates before you sign If a date here does not match what you agreed, say so **before** signing rather than after. Dates drive the rent: your move-in date sets what your first invoice covers, and your contract end date sets your notice period and whether leaving counts as early. Changing either after signature is an amendment. ## Stages The stage shown tracks where you are: booked, contract issued, signed, moved in, notice given, moved out. It changes on its own as each step completes — there is nothing for you to update. A stage that has not moved after you have done your part is worth querying; it usually means something on the other side has not been recorded yet. ## If your booking is cancelled A cancelled booking stays listed, marked **Cancelled**. If you had paid a deposit for it, the card shows a **Deposit refund** note saying where that deposit stands: | Note | What it means | | ------------------ | ------------------------------------------------------------------------ | | **In progress** | The deposit is being refunded and has not been sent yet. | | **Refunded** | The money has been sent. The date shows when it was sent. | | **Not refundable** | Under the terms you agreed to when booking, the deposit is not refunded. | Whether a deposit is refunded depends on the terms of your booking and on how it was cancelled. If the note does not match what you were told, use **Contact us** on the note. ## After you leave Your reservation does not disappear. It keeps the record of what you paid, what was settled and what was refunded, which is what lets a later question be answered properly. See [The tenancy lifecycle](/docs/concepts/the-tenancy-lifecycle).