Read Me First

Vacation Rental Management — an orientation for someone meeting this software for the very first time.

This page is written for a person who rents out places to stay, not for a programmer. It explains who the software is for, what it does, what it does not do, what you have to set up yourself, and what a normal week with it looks like. Read it once, end to end — about half an hour — and afterwards you will know exactly what you are getting. The last few sections are lookup material: a glossary, a guide to the other documents, and a list of the things that catch people out. Come back to those as you need them.

Everything below describes what the software actually does today. Where something is missing, half-built or needs setting up before it works, this page says so plainly rather than glossing over it.

---

1. Who this is for

The main reader is a host with a small number of holiday lets — one to five places, run alongside a job or a family. You are comfortable with the apps on your phone. You are not a software person, and you do not want to become one. You open a tool like this in gaps in the day, to answer one question and leave.

It also suits a professional property manager looking after ten to two hundred places for other owners, and larger operators beyond that — the operations board and the owner statements are aimed squarely at that job.

One important note about who owns an installation. One running copy of this software belongs to exactly one business — yours. Your bookings never sit in the same system as a stranger's. That is a deliberate design decision, and it means that if you manage properties for several separate companies that must never see each other's data, you run a separate copy for each.

There is one honest requirement. Setting this up is not a matter of signing up on a website and clicking through a wizard. Somebody has to install it on a computer, connect a database, and register it with a sign-in service. If that is not you, you need somebody who can do it — a technical friend, a contractor, or someone from the community mentioned at the end of this page. Once it is running, using it needs none of that.

---

2. What it does

It is one place to run your short-term rental business, instead of a calendar in one app, a spreadsheet of takings, a messaging thread with each guest, and a folder of receipts for the accountant.

In one sentence: it holds your properties, keeps your calendars in step with the booking sites so the same night is never sold twice, prices and records your bookings, and gathers guest messages into one inbox.

Behind that, and reachable by anyone building on top of it, it also tracks cleans, repairs, payments, lodging tax and money owed to property owners.

Two things are worth knowing straight away, because they shape everything else:

• A double booking is impossible inside this system. Not "unlikely", not "you get a warning". The database itself refuses to hold two overlapping stays for the same place. Whether the second booking comes from you, from an imported calendar, or from two things happening at the same instant, it is refused. Across booking sites there is still a window while each site is checking your calendar — no product using shared calendars can close that, and section 4 explains why.

• Where the software acts on your behalf, it shows you and lets you stop it. It will write a reply to a guest for you. It will not send that reply. You read it, change it, and press send. There is no setting that turns that off, because the part of the software that writes drafts has no way to send anything at all.

---

3. The business this software is for

If you already run holiday lets, skip this section. If you are new to the trade, here is the setting.

The trade. People rent out homes, flats, cabins and rooms by the night. Guests find them on booking sites — the big marketplaces plus dozens of small regional ones — or book direct. A host might have one flat; a management company might look after two hundred on behalf of the people who own them.

The daily problem is the calendar. The same place is usually advertised on several sites at once, because that is how you stay full. But each site sells independently. If one sells the first week of June and the others do not find out, one of them sells it again. Two guests turn up. You cancel one, refund them, apologise, and take a public rating hit that costs far more than the booking did. Keeping every calendar in step is the single most important job in this business, and it is the job this software does first.

The money is fiddly. A stay is not one number. It is nights at a nightly rate, possibly a different rate at weekends, plus a cleaning fee, plus a service fee, plus tax — and in most places the tax is several separate taxes (state, local, and a bed or occupancy tax) at percentages that depend on where the property is. If you manage places for other people, you also owe each owner their share, minus your fee, minus what the repairs cost. Getting this wrong is not a rounding error; it is somebody's income.

The paperwork is real. Many towns now require a permit to let a place short-term, and require the occupancy tax to be collected and handed over.

And then there is the guest. Most guest messages are the same six questions: where do I park, what time can I get in, what is the wifi, is there a cot, how do I get the key, can I stay a bit later. They come in at all hours and they arrive through whichever route the guest used. Answering them fast is a large part of what your rating is made of.

The words the trade uses, and that this software uses too: a property is a place you let; a listing is that property as it appears on one booking site; a stay or reservation is one guest for one set of dates; a hold is dates blocked off because somewhere else sold them; a clean is the turnover between guests; a payout is money owed to the property's owner.

---

4. Where it fits

Who uses it

• You, the host or manager. You are in it most days.
• Your colleagues. Other people can be given accounts at one of five levels of access, and the level genuinely decides what they can reach and change. Read "Who can do what" below before you hand any out.
• Your cleaners and handymen get accounts of their own. A cleaner signs in to a single screen showing the jobs assigned to them and nothing else — not your bookings, not your guests, not your money.
• Your guests never sign in. They never see this software. They email or message you as they always did; their messages arrive in your inbox here.

What it works alongside

Booking sites. This is the important one, and it is important to be precise. The software exchanges calendars with booking sites, using the standard calendar-sharing format that every one of them supports — the same format your phone's calendar uses. It publishes a web link listing the dates your place is busy, which you paste into each booking site; and it reads the equivalent links that each site publishes for your listings, turning the dates they have sold into blocks here.

It does not plug into the booking sites' own private systems. Doing that requires being granted approved partner status by each company individually, which this project does not have. So: no direct connection to any of the big sites' internal systems, and no way to push a booking made here out into one of them. Calendar sharing is the mechanism, and it is the mechanism they all support, including the small sites where double-booking risk actually concentrates because those are the ones people forget to block by hand. No booking site is a partner in, sponsor of, or in any way associated with this project.

The practical consequence: each site checks your calendar link on its own schedule, typically every few minutes to a few hours. Changes take minutes to hours to appear over there, not seconds. Nobody can promise you faster over calendar sharing, and this software does not pretend to.

A sign-in service. There is no username and password box in this application. Signing in hands you over to a separate sign-in service, you sign in there, and it sends you back. The software never sees or stores a password. This means you must have such a service and must register the application with it before anybody can sign in at all. It is a hard requirement, and it is the step that most often stalls a first installation.

Your email provider. Guest emails arrive by your mail provider forwarding them in, and replies go out through your mail server. Both need setting up.

A payment provider. Card payments are handled by an outside payment company. Card numbers go straight from the guest's browser to that company and never touch your server, which is the safe arrangement. This needs setting up too.

An AI provider. Optional. It powers one button — "draft a reply for me" — and nothing else. Without it, that button politely says the feature is unavailable and everything else carries on exactly as before.

A database. All your information lives in a PostgreSQL database that you run or rent. It is a normal, open, well-documented database, so you or your accountant can read from it directly if you ever want to.

What you actually see on screen

What is in your menu depends on who you are — see "Who can do what" below. An owner or an administrator gets all of this:

1. Properties — the list of places you look after.
2. A property's own page — its month calendar showing which nights are taken, its pricing, its public calendar link, and the calendars it watches.
3. Reservations — every stay, the form for taking a new booking with the price appearing live as you pick dates, and cancelling one.
4. Operations — one board carrying every clean and every repair, grouped by what stage each is at.
5. Inbox — guest conversations, with saved templates and the draft-a-reply button.
6. Finance — the report, owner statements, payments and tax. Owners and administrators only.
7. Messaging — the rules that send messages on a schedule, the queue of what is about to go out, and your notifications.
8. Settings — calendar feeds in and out, and the channels guest messages arrive on. Owners and administrators only.

A cleaner sees none of that. They get one screen, My tasks, with the jobs assigned to them and nothing else.

Some setting-up still has no page. Tax percentages, permit and insurance details, listings, saved message templates, editing or deleting a property once it exists, and changing somebody's access level are all done through the software's programming interface — which means somebody writing a little bit of code, or a tool that talks to it, rather than a page you click.

Throughout this document, wherever something says "through the programming interface", read it as: this exists and works, but somebody technical sets it up or runs it for you. If you need those areas as screens, that is work somebody would need to add — and it is exactly the kind of work the community mentioned at the end of this page exists to help with.

---

5. First run

If you are just having a look

There is a ready-made evaluation package — a single self-contained bundle with the software, a database and a set of made-up demo data already loaded (six properties, fourteen listings, fourteen guests, thirty-six stays, six guest conversations, eleven messages, five team members, forty-two cleans, twelve repairs, forty-six payments, thirty-six tax records and twelve owner statements). Every screen has something real on it from the first second. It needs nothing else installed. preview/README.md in this project has the exact command.

One thing will surprise you: it still requires a real sign-in. The package deliberately ships without a sign-in service configured, because building one in would let anyone who downloads the package sign in as anybody. So out of the box you will land on a sign-in page and clicking sign in will fail. To actually get in, you supply the details of your own sign-in service when you start it — three values, and preview/README.md shows exactly where they go.

If you are setting it up for real

The very first thing to do, before anything else, is decide who the first administrator is — and set them up while the system is being prepared.

Here is why this matters more than it sounds. Because sign-in is delegated elsewhere, anybody who signs in for the first time gets an account created automatically at the lowest access level — and that includes you. At the lowest level you cannot save a message template, set up a messaging connection, or create a rule for self-sending messages, which means you cannot finish setting the system up. There is deliberately no "set up the first administrator" page, because a page like that, sitting there unprotected forever, would be a permanent way in for anyone who found it.

So the first administrator has to be established during setup. There are two ways, both covered step by step in user-docs/production-initialisation.md:

• Best: get your sign-in service to tell you the internal identifier it uses for that person, and pass it in during setup. They are a full owner from their very first visit.
• Otherwise: have them sign in once — they will land at the lowest level, which is expected and not a fault — and then promote them with a single follow-up command. They sign in again and they are an owner.

If you have just installed this, you are signed in, and you are being refused when you try to save a message template or set up a messaging connection, this is why. It is not broken. See "Who can do what" below for exactly which actions the access level does and does not govern today — the answer is narrower than you might expect.

After that first sign-in you land on the properties list, and it is empty. That is the correct starting point for a real business. Everything from here is you putting your own places in.

---

6. Setting up

Work through this in order. Each step is described in plain terms here; the exact detail is in the documents named at the end of each part.

Step 1 — Get it running

Somebody installs three pieces of the software — the main service, a background helper that does scheduled work, and the website you look at — and points all three at one database. They can run on one machine or several. Detail: collateral/install/installation-guide.md.

Step 2 — Connect the sign-in service

Register the application with your sign-in service. The one thing that goes wrong here, almost every time, is the return address: the address the sign-in service sends people back to must match what you registered exactly — same spelling, same port number, no extra slash on the end. If sign-in loops or complains about an invalid address, that is what it is. Detail: collateral/integration/sso-oidc-integration.md.

Step 3 — Prepare the system and set the first administrator

Run the one-time preparation step described in user-docs/production-initialisation.md. It writes your default currency and time zone, sets up four starter message templates, and — if you give it the right detail — creates your first administrator. It deliberately creates no properties, guests or bookings; you are starting a real business, not a demo.

Be aware this step empties the database it is pointed at. It has several safety gates for exactly that reason, including a rehearsal mode that shows you what it would do without doing it. Use the rehearsal first, every time.

Step 4 — Add your properties

On the Properties screen, "New property" gives you a short form: name, address, town, county or state, postcode, bedrooms, bathrooms. That is the whole form and it should take seconds.

Two further parts of a property matter a great deal, and both are set through the programming interface, not on that form:

• Tax percentages. Each property carries its own state, local and occupancy tax rates. Every time a booking is made, the tax is worked out from those rates and written down against that booking. Because it is recorded at the moment of booking, changing a rate next year does not quietly rewrite last year's figures. Get these right once. If you leave them empty, bookings simply record no tax.
• Permit and insurance details. You can record these against a property so they are all in one place. Be aware the software stores them and does not watch them. Nothing will remind you that a permit expires next month.

You can also record a listing for each site you advertise on — again through the programming interface, and today it is a label for your own organisation, not a live connection to that site.

There is no screen for editing or removing a property once it is created, either.

Step 5 — Set prices

Give each property a rate plan: a nightly rate, a different weekend rate if you want one, a cleaning fee, a service fee percentage, and minimum and maximum nights. From then on, bookings price themselves and the booking screen shows a live quote for any dates you pick.

Pricing is on the property's own page, underneath its calendar. Change it and it prices every quote from that moment on; the prices it produces appear on the booking form and in the reservations list.

You can still take a booking for a property with no rate plan. The quote panel says plainly that the property has no rate plan yet and the booking is created without a price, rather than refusing to let you continue.

Step 6 — Connect your calendars, both directions

This is the step that stops you being sold twice, and both halves are needed.

Sending yours out. Turn on the calendar link for a property. You get a web address. Paste that address into the "import a calendar" box in each booking site's availability settings. Those sites will then check it regularly and stop selling dates you have already sold.

The link contains one fact per booking: these dates are not available. No guest name, no email, no message, no price, no booking reference. Anyone who gets hold of the address learns when your place is busy and nothing else. If you ever paste it somewhere you should not have, you can roll it over — which issues a new address and kills the old one immediately, so you must then re-paste the new one into every site that was using it — or switch it off entirely.

Bringing theirs in. Each booking site publishes the reverse: a calendar address for your listing there. Copy each one and add it to that property here, with a clear label — the label is what tells you which site disagreed when a clash appears later. Choose how often to check it; hourly is the default, and anything from five minutes upward is allowed.

From then on it runs on its own. After each check you can see, on that property's page, how many blocks came in, how many were already known, exactly which dates clashed, when it last ran, and any error. Each connection also has buttons to check it right now, pause it, change it or remove it. If one connection is broken, the others keep working.

Both halves of this are set up entirely on screen, on the property's own page.

Two protections worth understanding. An imported block genuinely blocks — it stops a booking exactly as a real booking does, rather than just showing grey. And if an incoming block clashes with a booking you already have, your booking wins: the block is refused, the clash is written down with the exact dates, and the rest of the calendar still imports. Nothing outside can ever delete a stay you sold. If a check fails altogether, your existing blocks are left exactly as they are — an outage at the other end can never open up your calendar.

One thing that catches people out: calendar addresses you add must be secure web addresses, and must not point at a private or local machine. If you are testing against a calendar server on your own laptop, it will be refused. That is correct behaviour, protecting your server from being used to reach inside your own network. Detail: collateral/integration/channel-calendar-integration.md.

Step 7 — Connect guest messaging

Set up a mail connection so guest emails arrive here and your replies go out.

The one thing to check, and then check again. If no mail server is configured, the software will record your reply as sent successfully — and send nothing. This exists so that developers can work without a mail server, and it is by a distance the most confusing thing that can be misconfigured. If your messages show as delivered and your guests say they received nothing, that is the first thing to look at.

Text messages: there is no way to send them. The inbox understands text messages arriving, but nothing is built that can send one out. Do not plan around sending texts.

There is also a general-purpose forwarding connection for anything else — a chat platform, your own bridge — which posts your outgoing message to an address you choose.

While you are here, save the messages you send constantly as templates: check-in instructions, directions, the wifi. Templates fill in the guest's name, their dates and the property automatically, and if a template cannot fill something in, it tells you rather than sending your guest a message with a gap in it. Preview a template against a real booking before you rely on it.

You can also set up messages that send themselves — "three days before check-in, send the arrival instructions". These become scheduled messages attached to each booking, visible before they go and cancellable. If a booking's dates change they reschedule; if it is cancelled they are cancelled too. And if one falls more than a day behind — the system was off overnight, say — it is skipped and marked skipped with the reason, rather than sending a welcome message two days after checkout.

Two of these three are now on screen. The mail connection is set up under Settings, on the "Message channels" tab, and the self-sending rules under Messaging. Writing the saved templates themselves is still done through the programming interface — you can pick one from the inbox and use it, but not compose a new one. Nothing sends itself until somebody has created the rules; a freshly prepared system has none. Detail: collateral/integration/messaging-channels-integration.md.

Step 8 — Payments, if you take money here

This is a go-live check you must not skip. If no payment provider key is configured, the software uses a built-in pretend payment system. It returns realistic-looking references and statuses and moves no money whatsoever. That is exactly right for trying things out and exactly wrong for real life.

A test payment that succeeds instantly in a fresh setup is the pretend one until proven otherwise.

There is a second setting alongside it: a signing secret, which lets the software verify that messages arriving from the payment company are genuinely from them. Without that secret, those messages are accepted unverified. Set both, not one.

Refunds and paying money out to owners are not built. Detail: collateral/integration/payments-stripe-integration.md.

Step 9 — Optional: turn on draft replies

If you want the "draft a reply for me" button to work, supply an AI provider key. Without one, no request is ever made to any outside AI service and the button simply reports that drafting is unavailable. Everything else — replying, templates, scheduled messages, delivery, retries — is untouched.

If you turn it on, be aware that using the button sends that one conversation's history, plus the stay dates, property name and guest's first name, to an outside company. There is no reading across your other guests or conversations. If you have obligations about where your data may go, leave it switched off.

Step 10 — The go-live checklist

Before you point real guests at it:

• Real payment provider key set — otherwise payments are pretend.
• Payment signing secret set — otherwise incoming payment notifications are unverified.
• Mail server set — otherwise messages silently vanish while showing as delivered.
• The encryption key kept somewhere safe outside the running system, and identical across the pieces that need it.
• Sign-in return addresses matching your registration exactly, over a secure connection.
• The public web address set, so your calendar links come out with an address the booking sites can actually reach rather than an internal one.
• Your first administrator promoted.
• Backups scheduled and a restore actually tested.

---

7. Day to day

A normal day is short. Most days you will do two or three of these.

Check who is arriving. Open Reservations. The top line tells you how many stays are on the books and when the next guest arrives — and if somebody is arriving today, it says so instead. You do not have to read the table to get the answer.

Take a booking. Pick the property, type the guest's name and email, choose the dates. The price appears as soon as there are dates, broken into nights, cleaning fee, service fee and tax, before you commit to anything. If the dates are taken you cannot book them, and you get a plain message saying so rather than a warning you could click past.

Back-to-back stays are fine: one guest leaving on the 14th and another arriving on the 14th do not clash.

When a booking is created, two things happen at the same moment without you asking: a turnover clean is created for the checkout date, and the tax lines for that stay are worked out and recorded.

Work the board. Open Operations and you have the day in front of you: every clean and every repair, in columns by what stage each is at. The line at the top says how many cleans are due today and how many repairs are still open.

A clean starts life waiting for somebody. Give it to a cleaner and it moves along; they start it, and when it is done it is closed with a rating out of five and a checklist, so you still have the record weeks later when a guest complains. If you close one by mistake you can reopen it, and the completion is cleared with it rather than left lying around.

Switch the same board to maintenance for the things that break. A repair carries a category, how urgent it is, who has it, and what it was expected to cost against what it actually cost — and that last figure is what flows through to the owner's statement at the end of the month.

Answer guests. Open the Inbox. The top line tells you how many people are genuinely waiting on a reply — and says so plainly when that number is zero, which is the message that lets you close the laptop.

Each conversation is one guest, in order, matched to the right stay wherever the software could work it out. If it could not work out who a message is from, it does not throw it away: the conversation still appears, visibly unattached, so you can see it and deal with it.

Reply by typing, or pick a template and it arrives already filled in from the real booking — and if anything could not be filled in, it tells you before you send. For anything that is not routine, press draft-with-AI, read what it wrote, change what you like, and press send. Nothing goes out without you seeing it. Your own replies carry their delivery status, so you can tell what has reached the guest from what is still on its way.

Some inbox housekeeping is not on the screen yet: attaching an unattached conversation to the right guest, handing one to a colleague, marking one handled, and retrying a message that failed all exist and work, but through the programming interface. Conversations do reopen by themselves when a guest writes again.

Glance at the calendar connections. On a property's page each connection shows when it last ran and what it found. You are looking for two things: a recent time, and no repeating error. If a connection reports conflicts, that means a booking site believes it sold a night you sold elsewhere. Your booking is untouched; go and sort it out with that site. There is a button to check any connection right now if you do not want to wait for its next scheduled check.

A note on cancelling. Bookings can be cancelled from the reservations screen, and it asks you to confirm before it does anything. Cancelling one also cancels any of its messages still waiting to send, and frees its dates for rebooking.

---

8. Ongoing care

Every week or so

• Look over the calendar connections for any that have stopped running or keep erroring — the site may have changed the address.
• Look for messages stuck as failed.
• If you take payments, confirm they are still going through the real payment provider and not the pretend one.

Every month, or whenever you settle up

• Tax. Each stay has its tax written down as separate lines. When you have handed the money over, mark those lines remitted and the date is stamped. Worth repeating: this software records tax, it does not file it and it does not pay it. Nothing here is tax advice.

• Owner statements. For a property and a period, generate a statement. It shows the gross takings from stays that started in the period, your management fee as a percentage, the repair costs settled in the period, and the resulting payout — every line itemised, so any figure traces back to the booking or repair behind it. If a late invoice turns up, regenerate it: it updates in place rather than making a second copy, and it goes back to draft, because a changed number should not keep an old approval.

  Statements are information, not documents. There is no printable statement and no emailing one to an owner — you export the figures and present them yourself.

• The overall picture. Ask for a financial report over any date range and you get bookings, gross and net takings, tax collected, payments received, repair costs, nights sold, and the three numbers the trade uses: average nightly rate achieved, revenue per available night, and occupancy percentage.

All three of those — the tax lines, the statements and the report — are on the Finance screen, on tabs of their own. It is restricted to owners and administrators.

Every quarter

• Test that you can restore a backup. An untested backup is a hope. Restore it into a spare database and sign in against it.
• Check your encryption key is written down somewhere other than the running system. This is the one that ruins people: a perfect database backup, restored, with no record of the key — and your calendar connections are permanently unreadable.
• Review who has which access level. Is anyone still an owner who should not be?
• Roll over any calendar link that has been pasted anywhere shareable.
• Check the two areas of the database that grow forever — the history log and the stored messages — and decide what you want to keep.

Backups are yours

Nobody else is doing them. There is no company behind this holding a copy of your data. That is the trade you make for running it yourself: nobody can raise your price, lock you out, or read your bookings — and nobody will save you if you lose the database.

Back up before every upgrade, and never let an upgrade change the database and the software in the same breath. collateral/install/upgrading-and-backup.md is short and it is the one operational document worth reading in full.

---

Glossary

Word	What it means here
Property	A place you rent out.
Listing	That property as it appears on one booking site.
Stay / reservation	One guest, one set of dates.
Guest	The person staying.
Hold	Dates blocked off because another site sold them. It blocks a booking exactly as a real stay does.
Clean	A turnover between guests. Created automatically for every booking's checkout date.
Rate plan	The rules that decide what a stay costs — nightly rate, weekend rate, fees, minimum and maximum nights.
Quote	The price for a set of dates, broken down, before you commit.
Payout	Money owed to a property's owner.
Owner statement	The itemised sum for one property over one period: takings, minus your fee, minus repairs, equals the payout.
Occupancy tax	The bed tax many towns charge on short stays, on top of ordinary sales tax.
Booking site / channel	Where guests find you.
Calendar link	A web address ending in .ics that lists busy dates and nothing else. The universal way calendars are shared between sites.
Conflict	An imported block that clashed with a booking you already have. Recorded, never applied.
Average nightly rate	What you actually got per night sold.
Revenue per available night	Takings spread across every night, sold or not.
Occupancy	The percentage of available nights that sold.

---

The other documents here

Everything in the user-docs folder, and what each is for:

Document	Read it when
READ-ME-FIRST.md	This page. Start here.
production-initialisation.md	You are preparing a real system for its first use. The most important document here after this one — it covers the first-administrator problem described in section 5. Current and accurate.
login-bypass.md	Only if you are automating tests or capturing screenshots. It describes a deliberate hole in sign-in that works on a developer's own machine and refuses everywhere else. Not something a host ever needs.
useful-commands.md	You are running the software from the source code day to day. Written for a developer.
api-reference.md and openapi.yaml	You or somebody you hire is building something that talks to this software directly, rather than through its screens.
getting-started.md	A short developer tour.
testing.md	You want to know what has been checked and why you can trust it.

A caution about age. The documents in this folder have since been brought in line with the software as it is: they no longer describe usernames and passwords, or several separate businesses sharing one installation, neither of which has been true for some time.

target/README.md, the note aimed at programmers, has not. It still describes row-level security, an unprivileged vrm_app database role and separate organisations — all of which went when multi-tenancy was removed. Its quickstart commands work; the architecture it describes around them does not. Prefer this page, production-initialisation.md and the documents under collateral/ wherever anything disagrees.

There is a much larger set of documents under collateral/, aimed at different readers — a fuller user guide, installation and configuration, connecting calendars, messaging and payments, and a long, blunt question-and-answer list. collateral/README.md tells you which is which. If you only read one more thing after this page, make it collateral/user-guide/user-guide-plain-english.md.

---

Who can do what

There are five levels of access — owner, admin, member, cleaner, viewer — and everybody who signs in has one of them.

These are a real boundary, not labels. Every action that changes something declares which levels may perform it, and the check happens on the server — so it holds whether somebody uses the screens, guesses at a web address, or talks to the software directly. Roughly:

• Owner and admin — everything, including the money and the settings.
• Member — the daily work: properties, bookings, the operations board, the inbox, messaging. No finance, no settings.
• Viewer — can look at the daily screens and change nothing.
• Cleaner — one screen, showing the jobs assigned to them. They cannot open another cleaner's job even if they know its address.

What the level does not do is partition your business: everyone who can see your bookings sees all of them. There is no "this person handles only these three properties".

Three practical points:

1. New people arrive at the lowest level. Anyone signing in for the first time gets an account created for them automatically as a viewer. That is why the first administrator has to be arranged deliberately during setup (section 5) — otherwise nobody can manage templates, messaging connections or automatic messages at all.

2. Changing somebody's level is still not something you can click. There is no screen for it. Today an owner changes it directly in the database, or by using the promote command in user-docs/production-initialisation.md.

3. After a change, they must sign in again to pick it up. If you have just promoted somebody and nothing has changed for them, that is why.

---

The demo data, and starting fresh

The evaluation package ships with an invented business already loaded, so there is something to look at from the first second: six properties, fourteen listings, fourteen guests, thirty-six stays spread across past, present and future, six guest conversations, eleven messages, five templates, five team members (including two cleaners), forty-two cleans across every stage, twelve repairs, forty-six payments, thirty-six tax records and twelve owner statements over two closed periods. Every name in it is obviously fictional. Nothing in it is real, and nothing in it reaches the outside world.

The dates are worked out relative to the day you load it, so the calendar and the board always look like a business running this week rather than a snapshot of whenever the data was written. Reloading it reproduces exactly the same starting point.

One more thing about the evaluation package. It leaves out the background helper — the part that does scheduled work. So in the package, calendar checks do not actually run and queued messages do not actually go anywhere, even though you can add connections and press the buttons. Everything you can see and click is real; the clockwork behind it is not running. A real installation includes it.

Starting fresh depends on what you are doing:

• Just looking? The demo data reloads from scratch every time the evaluation package starts. Stop it and start it again and you are back to the same clean demo. Nothing you do can permanently spoil it.
• Want to keep what you enter while evaluating? Attach a storage volume and turn off the reload on later runs. preview/README.md gives the exact commands.
• Ready for real use? Do not try to clean the demo data out by hand. Run the preparation step in user-docs/production-initialisation.md against your real database. It empties everything and writes only the base settings, your first administrator, and four starter templates — no properties, no guests, no bookings.

---

Common questions and things that catch people out

"I have signed in but I am refused when I try to save a template or add a messaging connection." You are a viewer. Everyone starts there, and those are among the few actions that actually check your level. See section 5 and "Who can do what".

"Can I give somebody an account that only lets them look?" Not reliably. The levels exist by name, but only three areas enforce them today. See "Who can do what".

"Sign-in loops, or says the return address is invalid." The address registered with your sign-in service does not match exactly. Compare them character by character, including the port number and any trailing slash.

"My messages say delivered but my guests got nothing." No mail server is configured. The software records the send and does nothing. This is the single most common serious misconfiguration. Fix it before anything else.

"I want to text my guests." Not possible. The inbox understands incoming texts; nothing exists that can send one out.

"My test payment succeeded instantly." Almost certainly the pretend payment system, because no payment provider key is set. Verify before you take real money.

"The draft-a-reply button says drafting is unavailable." No AI provider key is configured, or the provider did not answer. Write the reply yourself; nothing else is affected.

"Will it set my prices for me?" No. Rate plans do exactly what you tell them. There is no automatic pricing, no market watching and no competitor tracking.

"Will it spot a maintenance problem in a guest's message?" No. Maintenance jobs are ones you create.

"Will it remind me before a permit expires?" No. It stores permit details and nothing scans them. Keep your own reminder.

"Can I get a printable owner statement, or email one to an owner?" No. Statements are figures you export and present yourself.

"Can it pay owners, or issue a refund?" No. Neither is built.

"Why does it take so long for a change to show on a booking site?" Because each site checks your calendar link on its own schedule — minutes to hours. That is inherent to calendar sharing and nobody using it can promise faster.

"Could a booking site's calendar wipe out one of my bookings?" No. If an incoming block clashes with a confirmed booking, the block is refused, the clash is recorded with the exact dates, and your booking is untouched.

"Can two management companies share one installation?" No. One installation, one business. Separate companies means separate installations — more setting up, and a much stronger guarantee that neither can see the other.

"Why won't it accept my calendar address?" It must be a secure web address, and it must not point at a private or local machine. A calendar server on your own laptop will be refused, correctly.

"Where are the cleaning and money screens?" Operations, for cleans and repairs, and Finance, for the report, statements, payments and tax. If Finance is not in your menu, your account is not an owner or an administrator.

"I found settings for AI pricing and a tax service. What do they do?" Nothing. A handful of switches are stored in the settings but no part of the software reads them. Turning them on or off changes nothing at all. Do not plan around them.

"Nothing is sending itself, even though the software supports it." A freshly prepared system has no self-sending rules set up. Create them under Messaging. They will still send nothing until a mail server is configured under Settings.

---

Where to get help

This software is part of the worlds-biggest-software-project initiative — https://wbsp.ai.

That is where to go to:

• ask questions and find people who already run this,
• find someone who can install it, connect it up, or build the screens it does not have yet,
• suggest what it should do next,
• report a security problem — please do that there rather than in public.

One thing worth knowing about what you are looking at. This is deliberately a core application: the working machinery, and almost none of the decoration. Plain type, plain tables, no logo, no branding. It is meant to be dressed in your colours, worded the way your team already talks, and extended into the areas it does not yet cover. Plenty of people in that community have built their own versions of this and other applications, and one may already be closer to what you need than this one is.

---

Any booking site, payment company, mail provider or other business referred to here is mentioned for description only. No partnership, sponsorship, certification or endorsement is claimed or implied. Nothing on this page is tax, legal, accounting or financial advice.