User documentation

Introduction & roles

Villantis is one dashboard for managing holiday rentals: bookings, guest communication, properties, agents, commissions and reporting.

There are three roles:

• Platform administrator — sees all properties and the platform dashboard.
• Owner owner — automatically sees all of their own properties.
• Agent rental manager — sees the properties linked to them; can also create their own (owner-less) properties.

Signing in

Go to my.villantis.com and sign in with your email address and password. Forgot your password? Click "Forgot password", enter your email address and you will receive a reset code by email.

Your profile

Click your email address at the top right to open your profile. There you set your name and language (NL / EN / FR), change your password and manage 2FA.

Two-factor authentication (2FA) required for platform

Secure your account with an authenticator app (Google/Microsoft Authenticator, 1Password, …). For platform administrators 2FA is mandatory: at your first login you set it up once — scan the QR code (or enter the key manually) and confirm with the 6-digit code. Tick "remember this device" to skip entering a code on your own computer for 14 days (even after signing out); leave it unticked and the next login will ask for a code again. Owners and agents can optionally enable 2FA themselves via their profile (click your email at the top right). Lost your authenticator? The platform resets your 2FA via Agents → user → Reset 2FA, after which you set it up again.

Getting started — your first property in six steps

New to Villantis? This walkthrough takes you from first sign-in to a property that is ready to rent. Every step links to the detailed section, so this page doubles as your map of the documentation.

1. Sign in for the first time

You received your email address and a one-time password from whoever invited you. Go to my.villantis.com and sign in — see Signing in. First thing to do: click your email address at the top right and set your name, your language (NL / EN / FR — the whole portal follows it) and, if you like, a new password and 2FA.

2. Create the property

Go to Properties and click + Property. Only two things are truly required to save: a property-id (short, lowercase, becomes part of your links — choose once, it cannot change) and a name (guests see it in every email and on every page). Everything else can be filled in later; the tabs below tell you where.

3. Walk through the tabs — what every setting does

• General — identity and money basics. Name, tagline, address and country (used in the contract and arrival info), max. guests (caps the booking form), check-in/out times and changeover day (drive the calendar's half days), logo and accent colour (brand every guest email and page), languages (which languages guests can book in), owner email (guest replies and notifications land there), and the bank details + landlord name/address — these appear verbatim in the contract and payment instructions, so the contract waits until they are filled. The "live" checkbox is explained in Live or in preparation: tick it when the property really rents.
• Prices & costs — the money engine, see Prices & costs. Weekly rates for four seasons plus the season calendar (or a flexible per-period model), the down payment percentage, the security deposit (0 = no deposit and no deposit emails), tourist tax, final cleaning, linen, pool heating, EV charging, pets and your own custom costs. Per cost you choose invoice (counted into the offer and the total) or on site (listed, but paid at the house) — that choice decides what the guest's total says, so check it before the first offer goes out.
• Availability — which booking years are open. A year that is not opened yet is closed everywhere at once: calendar, iCal and channels. Optionally give a year its own season periods.
• Communication — when emails leave and what the guest may do, see E-mails and My booking. The day-counts steer the balance reminder, deposit request, arrival info and review request; the switches turn the guest page, review requests, extras offers and the address form on or off per property.
• Site — a ready-made page for the property on villantis.com, see Property site. One switch, four styles, your photos and texts.
• Services — gardener, pool service, concierge and their days; they appear in the guest's arrival info automatically.
• Access owner — invite rental agents to this property and set their commission, see Agents.
• Integrations — everything that connects outward, see Booking widget & links: the widget snippet for your own website, the public availability feed, your private iCal calendar and the week overview link for on your phone.
• Contract — the cancellation ladder (what a guest owes when cancelling, per period), how fast the security deposit is returned, and your signature (image or a name in a handwriting font). Custom contract terms are premium — we review them before they go out.
• Premium — per-property extras: sending from your own domain, a custom email flow, custom contract terms and the OpenGDS channel connection.

4. See what the guest will get

Open E-mails in the menu and preview every email with your property's real prices and branding — before any guest sees one. The texts are editable per property; the standard flow works out of the box.

5. Do one test booking

Click + Booking on the board, pick your property and use your own email address. Drag the card to Offer and you will receive exactly what a guest receives — offer, contract, the lot. Emails leave a few minutes after your last change (the card shows ✉ sends in ~X min), so several changes bundle into one message. Done testing? Delete the booking via the card.

6. Go live

The short checklist: prices filled in · bank details and landlord details complete (the contract needs them) · check-in/out and changeover day correct · emails previewed · test booking received and cleaned up. Then tick "This property is live" on the General tab and put the booking widget on your website — or switch on the property site if you don't have one. From then on the nightly quality control watches your configuration strictly.

The board

The home page: all your bookings as cards, spread across columns (swimlanes) per status.

How you work

• Drag a card to another column to change the status. That automatically triggers the matching email to the guest.
• Click a card to open and edit the booking.
• At the top you can filter on a specific property.
• Bookings from previous years are collapsed per year in each lane (e.g. "▸ 2025") to keep the board tidy — click to expand.
• The header of each column shows the count and the total amount of the cards that are open there: this year and further ahead. Each collapsed year keeps its own count and total below that.

Recording a booking yourself

At the top of the form, under Existing guest, you pick someone from your contacts — name, email address and phone number are then filled in and remain editable. For a new guest, leave that choice on new guest and type the details yourself.

Returning guests often call, text or email directly. Click + Booking at the top right to put such a reservation on the board straight away. You fill in the property, the name, the dates and the amount; the number of guests and the reference number are handled by the system. From there the booking follows exactly the same path as an enquiry via the form: the same email flow, calendar, iCal and reporting.

Already know whether a dog is coming along or that they want an extra? Tick it right away — the dog appears if the property allows pets, the extras once the period is chosen, with the price calculated. Because you are taking the booking yourself it is confirmed immediately, and the guest gets no separate question about it.

You pick the period in a calendar that shows that property's occupancy: crossed-out days are occupied and cannot be clicked, half-shaded days are changeover days — one guest leaves in the morning and the next can arrive in the afternoon. Fixed closures and years that have not yet been opened for booking are shown too. If an existing booking cuts through your selection, the selection starts over instead of creating a double booking.

Badges on a card

• 🏠 property name (with multiple properties) · 👤 assigned agent · via channel · discount
• deposit ✓ — security deposit received · 📋 details ✓ — address received · 📄 contract ✓ — contract sent
• 👁 shadow — shadow booking (no emails) · ⛔ do not rent — flagged guest
• ✉ sends in ~X min — a guest email is ready and waiting for the quiet period: mails go out a few minutes after your last change, so several changes bundle into one message and you keep a short correction window. Hover the badge to see which emails are queued. It comes from the same decision logic that actually sends, so it never disagrees with what happens.

The statuses

A booking moves through these stages. Moving between stages automatically sends the right email:

1. Enquiry — new enquiry received (auto-reply to the guest).
2. Offer — you send a quote; the guest gets the price + a button to fill in their details.
3. Confirmed — down payment received; the booking is fixed. The contract follows once the guest details are complete.
4. Paid in full — full payment received.
5. Stayed — the stay is over.
6. Deposit returned — the security deposit has been refunded.
7. Cancelled — with an automatic cancellation settlement according to the contract terms.

Editing a booking

Click a card to open the detail screen. You can:

• Change the status, edit guest + email + phone, set the amount & discount, change the number of guests.
• Under Payments, tick that the down payment, the balance and/or the security deposit has been received, along with the amount. The confirmation email to the guest only goes out when you tick the box — not already when you drag the card. If the property asks no deposit (deposit = 0), that checkbox is not shown.
• The balance payment and the Paid in full swimlane move together: tick it off and the booking moves along; drag the card into the lane and the box gets ticked. Untick it and the card goes back to Confirmed. From Stayed onwards the checkmark stays.
• The amounts next to those checkboxes (down payment, balance) come from the same calculation as the guest emails: including costs, tourist tax and chosen extras.
• Confirm or decline a requested pet or requested extras. As long as something is waiting for you, the card shows a badge. Only after confirmation do the amounts count in the guest emails.
• Type a reply to the guest — this is emailed on the next processing round.
• Set a booking to shadow (no emails).
• Under Cancellation you see what a cancellation today means according to this property's cancellation scale (percentage, amount, and whether the guest gets money back or still owes more). There you also set the cancellation amount: empty = according to the scale, 0 = waived, or your own amount. Set it before you drag the card to Cancelled — at that moment the cancellation email goes out with that amount in it. If the email is already gone and you correct the amount afterwards, save and use Resend cancellation email; otherwise the guest keeps the old settlement. If your amount differs from the scale, the email states both: what the terms prescribe and what you turned it into, with a sentence saying you adjusted it.
• The settlement counts everything that has come in and names it separately: down payment received, balance received and security deposit received. Whatever remains after deducting the cancellation costs is refunded to the guest; if it falls short, it states what the guest still has to pay. If the checkboxes under Payments are off, that money does not count — the email calculates with what you have ticked off, not with an assumption.
• View the communication history: every sent email can be read back.
• Upload and record documents — e.g. the signed return contract the guest sends back, but also ID or extra agreements. Pick a type, upload a PDF or image, and download or delete later. As soon as you upload a signed contract, a ✍️ signed ✓ badge appears on the card and a line in the communication history. The files are stored safely and privately; downloading works via a temporary, protected link.

Calendar

The occupancy per property, in three views (switch at the top right with Month · Week · Day). Confirmed bookings are terracotta, options (enquiry/offer) amber, free is sand.

• Month: four months per property as a calendar. Changeover days are shown diagonally (departure = morning, arrival = afternoon), and you hover over a day for the ref + tenant name.
• Week: per property a strip that runs from changeover day up to and including the next changeover day — that changeover day (Sat or Sun) is recognised automatically per property, so each property shows its own rental week. The strip is 8 days so that the closing changeover day — which carries both this week's check-out and the next guest's check-in — stays visible. With the guest name in the cell plus 👤 number of persons and the price.
• Day: one line per property — who is arriving (➡), departing (⬅) or staying (🏠), with persons, price, channel and the stay period (nights).
• Click a booking (in any view) to open the full booking details.
• Browse with ‹ › (per 4 months / week / day). Export all reservations to CSV with the ⬇ button.

Exporting to Excel

With ⬇ Export you download a week overview as a CSV file that Excel opens directly. Next to it you pick the year — the current year by default.

The overview runs chronologically through all weeks of that year, including the weeks with nothing booked: those appear as an empty row with only the dates and the status free. That way you see at a glance where the gaps are. The weeks run from changeover day to changeover day; if a property has no fixed changeover day, Saturday is used.

If a booking lasts more than a week, the details are on the first week; the following weeks are marked occupied but with empty numbers, so you can add things up in Excel without double counting. The export follows the property filter at the top: if that is set to one property, only that property is in the file.

Contacts

All guests, with name, email, phone, language, year of last booking and any rebooking discount.

• Search by name, email or phone; click a column header to sort.
• Click a contact for the details: bookings, communication history, and the "Do not rent again" flag (with a mandatory, factual reason).
• Under Address is the address the guest entered themselves via the details link in the offer — the same address that goes on the contract. You can correct it here, for instance a typo in the street name. If this guest books the same property again later, the address is already waiting for them on that page; they can still adjust it there.

Importing

Put an existing schedule (e.g. an Excel or Google Sheets export) on the board in one go.

Click ⬆ Import at the top right, choose the property and upload a CSV file. The portal recognises the columns by the header row and shows a preview before you import.

Not sure which columns you need? Click ⬇ Download sample file in the import window — you get a ready-made CSV template with the right header row and a few sample rows that you can open and fill in with Excel or Google Sheets.

Columns (by header name, order does not matter)

• Arrival and Departure — as YYYY-MM-DD or DD/MM/YYYY (required).
• Name (required), and optionally Channel, Adults, Children, Guests, Email, Phone, Amount, Status.

For every row with a valid email address a contact is automatically created/updated. The status is derived from the dates (past → Stayed, future → Confirmed), unless you supply a Status column.

Properties

Manage your properties and all their settings.

Per property you set: name, address, country, max. guests, branding (logo + colours), bank/IBAN details, owner signature, language versions, and the integrations (public availability, iCal calendar, booking widget link).

Quality control — what exactly is tested?

A check run covers the whole platform and sends the result as a report to Slack, with version number and commit. Below is exactly what gets checked. A report is only green when everything below passes.

1. Integration tests (OpenGDS)

These run against the official sample message from OpenGDS itself — not against a test message we made up.

• A complete reservation is fully parsed: reservation number, hotel code, arrival, departure, amount, currency, guest name, email, number of adults and children, sales channel, promo code, room type, rate and the booked extras.
• The name of the sales partner (e.g. Nice2stay) is read, even when OpenGDS appends a partner code to it. This drives the commission attribution.
• A reservation message in the alternative OTA format is processed just as well.
• An unusable or corrupted message never produces a phantom reservation, so the endpoint can reject it and OpenGDS sends it again.

2. Email checks — every email, every property, every language

All email types (enquiry confirmation, offer, down payment, balance, paid in full, security deposit, deposit received, extras, welcome info, refund, contract, signed contract and reply) are rendered for every property in every configured language and checked for:

• the email builds without error and is not empty;
• no placeholders are left unreplaced (such as {bedrag});
• nowhere does undefined, NaN or other technical debris appear in the text;
• no cost item is mentioned twice — exactly the bug that once made the final cleaning show up double;
• down payment + balance is exactly equal to the total amount;
• the cost lines in the table add up to the amount included in the total;
• all amounts are valid numbers.

3. The contract

For every property and every language the contract PDF is built and checked:

• the file is complete (not truncated);
• the tourist tax in the contract equals the one in the offer email — the contract counts adults, exactly as the contract text itself says;
• down payment plus balance equals the rental price;
• the custom terms do not mention a security deposit while Deposit (€) is set to 0, and the first step of the cancellation scale matches the down payment percentage;
• the landlord and bank details are actually filled in — name, address, account holder, IBAN and BIC. Those appear verbatim in the contract and in the payment instruction; a placeholder value there means a guest with an unusable account number. This applies to live properties.

4. Public endpoints and the changeover day

• the public availability returns valid data and contains no guest data;
• there is no property still pointing to a published availability file. The booking widget, a property's website and the iCal feed all get their availability directly from the same source; a second copy could silently go stale;
• the Domain field is a bare hostname (pand.nl, not https://pand.nl/) and the website URL is valid — otherwise a broken link sits in the footer of every guest email;
• the private iCal rejects a request without a token and delivers a valid calendar with a token;
• the changeover-day restrictions sent to OpenGDS are correct: a fixed changeover day applies all year round, the high-season variant only in high and peak season, and the switch falls exactly on the season boundary.

5. Published pages

The booking form in the iframe, the details and extras pages and this documentation live as separate files on villantis.com. They belong to the code but do not travel with the rest, so a half-finished publish used to be invisible. Every page now carries a build stamp, and the check reads back whether they are all reachable and carry the same stamp. If a guest page also exists on the portal domain, that is a second copy that will sooner or later drift — that is reported too.

6. Language, bookings and the OpenGDS integration

• Language: every text in the portal has an English and a French translation. If one is missing, a foreign user would silently see Dutch — that can no longer happen unnoticed.
• Bookings: all bookings are checked. The most important rule: a shadow booking must never have produced a guest email, because for channel bookings the channel handles that communication. Also: no bookings on a non-existent property, no missing dates, and departure always after arrival.
• OpenGDS: for connected properties, OpenGDS itself is asked whether the configured room and rate codes still exist there. OpenGDS manages those codes itself; if one disappears or is renamed, we would be sending availability into the void without any error.

6. Property configuration checks

Only for properties marked as live:

• Error: a live property without weekly prices and without a flexible pricing model — an enquiry would get € 0 as an indicative price.
• Attention point: a tourist tax mode that calculates with a rate while the rate is 0.
• Attention point: a cost with an amount but no chosen payment method (a default is then used).
• Attention point: maximum number of guests or languages not set.
• Attention point: a property not marked as live that does have real bookings.

Live or in preparation

Every property has the checkbox "This property is live" under General. Tick it as soon as the property really rents to guests. In the property overview you can tell by the labels live and in preparation.

The checkbox determines how strictly the automatic quality control watches: live properties are fully checked on prices, costs and emails, while properties in preparation may still be incomplete without raising false alarms.

Prices & costs

Pricing model

Choose fixed weekly prices per season, or the flexible pricing model: prices per free-form period, optionally per occupancy (number of persons).

Season periods

Determines which weekly price applies to which date. You set them as dd-mm, for example 05-07 → 05-09 for the peak season. Dates outside every period fall back to the default season. A period may run across the turn of the year (for example 20-12 → 05-01).

Opening booking years

Per year you specify from when it is opened for bookings, and optionally its own season periods for that year (empty = the pattern above). As long as a year is not opened, it is closed everywhere: the booking calendar shows it as blocked, the iCal feed blocks it for partners reading that feed, and OpenGDS gets zero availability. Even an enquiry sent directly to the API is rejected. Leave the date empty to open a year immediately.

Not asking a security deposit

Set Deposit (€) to 0 if a property asks no security deposit. The contract then states that no deposit is asked and that damage or breakage established after departure will still be charged at the repair or replacement cost — no deposit does not mean damage is at the owner's expense. If you do enter an amount, the usual text with amount and refund term appears. This carries through everywhere: the deposit request and confirmation email no longer go out, the contract states that no deposit is asked, the deposit disappears from the amounts in the guest emails, and the Deposit received checkbox disappears from the board.

Fixed closures

On the Availability tab you find Fixed closures: periods in which the property is not rented at all — renovation, own use, or a property not yet opened. Enter a start and end date plus a short reason; the end date is the day the property becomes available again.

Such a period is closed everywhere: not bookable in the calendar and the booking widget, blocked in the iCal feed (with the reason attached, so you can see in your calendar why), and set to zero availability at OpenGDS. For a connected property this goes out immediately on save.

Difference with Opening booking years: a closure is "the property is unavailable during this period", an opening date is "this year may only be sold from this date". If a property is closed until some point in the future, use a closure.

Which contract does a property use?

At the top of the Contract tab it says whether this property sends the platform's standard contract or a customised version. You can switch between them yourself. If you temporarily choose the standard, any custom terms you entered are preserved — they are just not sent. The property overview shows per property which variant applies.

Custom general terms are entered as articles with a heading (e.g. PAYMENT) and a text, per language separately. Leave a language empty and the contract uses our standard text there. This is a legal document: always have a custom text reviewed by the owner.

The cancellation terms are set on that same tab as steps — from so many days before arrival this percentage of the rental price remains due. That scale appears verbatim in the contract and drives the calculation in the cancellation email, so the two can never contradict each other. Below it is the deposit term: within how many days after departure the security deposit is refunded.

Viewing your contract

On the Contract tab you find the Rental contract block. Choose a language and click Download contract (PDF): you get the contract that guests of this property receive, as an empty template. Guest name, dates and amounts stay open (dotted lines); everything that comes from the property settings — landlord, address, bank details, security deposit, final cleaning, tourist tax, down payment percentage and balance term — appears exactly as it will be sent with a real booking. If you have just changed something, save the property first.

Want to use a different contract? You cannot do that yourself: the contract text is legally fixed in the platform. Ask a question via 💬 Support in the left menu (see Support) — we will then set it up for that property.

Mind the fields Landlord, Landlord address, Account holder, IBAN and BIC: they appear verbatim in the contract and in the payment instruction of the guest emails. If a placeholder value is still there, the quality control reports it as an error as soon as the property is live.

Tourist tax included

If a property charges no separate tourist tax but includes it in the rental price, choose the option included under Tourist tax → mode. Nothing is then calculated separately, the sentence "plus the tourist tax" disappears from the balance email, and the contract states that the tax is included in the rental price. This previously only worked with the flexible pricing model; with fixed weekly prices the tax was calculated anyway.

When does which email go out?

Three settings on the Communication tab determine the moments, per property. Note: they are days before arrival, so a larger number is earlier:

• Down payment (days after the offer) — how many days the guest has to transfer the down payment (default 7). That date appears in the offer ("transfer the down payment of 30 % (€ 675) before 20 August"), and if the date passes without the money coming in, the card on the board gets ⏳ down payment overdue. It is never set later than the balance date or the day before arrival.
• Balance (days before arrival) — when the balance reminder goes out, and until when the guest may pay (default 56 days = 8 weeks).
• Deposit request (days before arrival) — when the security deposit request goes out (default 14).
• Welcome info (days before arrival) — when the practical arrival information goes out (default 7).
• Review request (days after departure) — when the review request goes out (default 7), if reviews are enabled for the property or the booking. Note: this counts after departure, the others before arrival.

Below the fields the order is stated in plain language (down payment (30 %) 7 d after the offer → balance reminder 56 d → deposit request 14 d → arrival information 7 d before arrival), and it turns orange as soon as you get them mixed up — for example the deposit before the balance. The nightly quality control reports that as well.

The deadline for the security deposit shifts with the moment you ask for it: normally a week before arrival, and if you ask later than that, the guest keeps two days to transfer. The contract states exactly the same term.

What you find where: Communication = when we send the guest something. Contract = the terms the guest is held to and that appear verbatim in the document (cancellation scale, deposit back within … days after departure). Both tabs refer to each other. The balance term belongs to both — it sits under Communication, with a note that it is also the payment date in the contract.

These dates also appear in the guest emails themselves: "we will send the practical arrival information around 27 February 2027" instead of the vague "shortly before your stay". And in the E-mails overview each email shows the real number of days for the selected property.

Guest replies

If a property has no custom sender domain, guest emails go out from no-reply@villantis.com. To make sure a guest who hits Reply still reaches you, we automatically set a reply-to address on the email: the address under Owner email, otherwise the one under Sender email. So always fill in at least one of those two — if neither is set, the guest's reply disappears.

That same address appears at the bottom of the email under "Questions? Just reply to this email, or write to us at …". no-reply@villantis.com never appears there — writing to a no-reply address is pointless. If the property has no address of its own, the footer names none and only "reply to this email" remains.

What the guest sees in the emails

Since 13 August 2026 those three checkboxes live on their own tab: Communication in the property settings. See My booking (guest page).

Pets

Under Pets → mode you choose none, on request or allowed. The guest gets the question both in the booking form and on their details page, with the surcharge shown.

• allowed — approved immediately, the surcharge counts in the amounts straight away;
• on request — it becomes a request. You get an email and a Slack alert about it, see it on the card with Confirm / Decline, and the surcharge only counts once you confirm. The guest sees the status on their details page, and gets a short email with your decision: on confirmation that the dog is welcome and how the surcharge is settled, on decline that it will not work for this stay. Both appear in the E-mails overview;
• none — the question is not asked and nothing is charged.

If a guest travels without a dog, nothing is charged, of course.

Mandatory costs (fees)

Final cleaning, linen, mid-stay cleaning, pool heating, tourist tax and pets — neatly grouped in blocks with an amount and a payment method: via the account (in the amount to transfer) or on site (cash to the property manager). The quote splits this out neatly into a cost table and a block "To pay on site".

The final cleaning follows that same choice — for every property, whether it uses fixed weekly prices or the flexible pricing model: with on site it sits under "To pay on site" and stays out of the transfer amount, with via account it is counted in the total. The contract adopts that wording automatically. Note: this choice applies to the flexible pricing model; with fixed weekly prices the final cleaning is always paid on site to the property manager.

Under EV charger you charge electricity for an electric car, per week or per stay. If you do not want to charge it by default but let the guest choose, set it up as a bookable extra under Extras.

Does a property charge something there is no field for? Under Custom cost items you name it yourself (per language), with amount, calculation method (per stay / week / night / person / adult) and payment method. Custom items behave exactly like the fixed ones: cost table in the guest emails, counted in the transfer total with "via account", and visible in the contract.

For mid-stay cleaning you can use "mandatory from … nights" to determine when the cost is applied automatically: leave it empty to charge it for every stay, or enter e.g. 14 so the mid-stay cleaning only appears on the quote and in the offer email for longer stays. Don't want a mandatory mid-stay cleaning but do want to offer it optionally? Leave the amount empty and add it as a bookable Extra.

Operating costs

Recurring costs for the reporting (electricity, water, concierge, pool, gardener, internet, …): category + amount + frequency + attribution (pro rata occupancy / in full / per booking) + a valid-from/until year.

Price calendar

For properties on the flexible pricing model (nightly or weekly prices per period — typical for apartments), the 📅 Price calendar button next to the period rows opens a year grid: every day shows its price per night (weekly-priced properties are converted ×7 on save, /7 on display), gaps show a red — (an enquiry would get € 0 there), closed days are hatched, school holidays carry a ▾ marker with the details in the tooltip, and equal prices read as coloured bands. Click a start day and an end day, then:

• Set or clear a price — per occupancy tier if you use tiers, with the weekly total computed live. By default you edit the yearly pattern (dd-mm periods that repeat every year — the safety net that keeps a price from ever expiring). Tick "only year" to store a year-specific exception instead (a trade-fair week, one odd November weekend): it overrides the pattern for those dates and expires by itself.
• Weekend rate — an optional Friday/Saturday-night price per period (nightly prices only). The engine, the offer and OpenGDS all count it per night.
• Close or reopen dates — writes the property's fixed closures, the same ones the availability, widget and iCal already honour.

Fixed-weekly-price properties (the four seasons under Prices & costs) get the calendar too: it shows the real engine prices per night read-only — including per-year season overrides — and closures can still be set and lifted; the prices themselves are changed where that model lives. Everything lands in the period rows and closures in the drawer — one save, one source of truth. A range across New Year is simply one period. The calendar writes exactly what the price engine reads, guarded by an automatic parity test. There is also a long-stay discount ladder (e.g. ≥ 7 nights −10%): it is applied automatically as the booking's discount on new enquiries (a personal returning-guest offer takes precedence) and shown on the rates block.

Extras & service providers

Bookable extras

Services the guest can add for a longer stay (mid-stay cleaning, towel change, EV charger, …), with a price, calculation method (per stay, week, night or person), from-how-many-nights and payment method. At, say, € 50 per week, a guest staying three weeks sees € 150, with "€ 50 per week" underneath.

Extras are offered already in the booking form as soon as the guest has chosen their dates — the price calculates live with the number of nights and guests. If they tick something, it is on the booking immediately. It can still be changed later via their own extras page in the offer.

Torn between a cost item and an extra? A cost item is always charged (final cleaning, linen); an extra offers the guest a choice and is only charged when they tick it. Something like an EV charger therefore belongs with the extras.

Furthermore: they are offered automatically in the offer and in a separate "Extras" email, and the guest picks them on their booking page.

Chosen extras come back in the email in one way: via account they appear with name and amount in the cost table (so "EV Charging € 50", not a vague line "Extras"), on site they appear in the block with what the guest settles on arrival.

What is already on the booking is not offered again: if you recorded the EV charger with "+ Booking", it sits in the offer's cost table and disappears from the "would you like to add something?" block. If nothing is left to choose, that block disappears entirely — as does the separate extras email.

The confirmation "we have noted your choice" only goes out after the offer has been sent. If the guest chooses at enquiry time, or you record it yourself, the extras simply appear in the offer — a confirmation beforehand would confirm something they have not yet asked for.

Service providers

Record the contact persons per property (gardener, pool, concierge/property manager, …). Optionally include them in the welcome email.

E-mails flows & texts · premium

One place for all your guest emails: view the full communication flow, adjust texts, and (premium) decide the order and content yourself.

The E-mails tab shows the standard flow across all swimlanes — which email (offer, contract, down payment, balance reminder, welcome, deposit, deposit returned, cancellation, …) goes out at which moment. Click an email to view a preview. Owners/platform can adjust the intro and outro text per property on the marked emails (the ✎ button) — just as before under Templates.

Emails that are ready at the same time go together

At one moment several emails can be due — at Confirmed, for example, the down payment, the contract and the deposit request. Those become one email: one greeting, the parts one below the other with a divider in between, one sign-off, and the contract as an attachment. That way your guest gets one clear message instead of three at once.

You can see it in the overview: the emails in question get a 🔗 and below the swimlane it says "These go together as one email". The subject is that of the part the guest has to act on — if the contract is included, the email is named after it.

Each part is ticked off separately, so nothing goes out twice. In the booking's communication history you see the individual types listed with the note sent bundled.

The emails tied to a checkbox (deposit received, pet confirmed or declined, signed contract received) join in too: if they fall in the same round, they are in the same message.

When does it go out? Not immediately. A guest email only leaves once you have not changed the booking for a few minutes, so that several actions in a row end up in one message. That also gives you a correction window: if you spot something wrong within that time, the guest has not received anything yet.

Want to see what such a combined message looks like? In the swimlane, click view preview next to the 🔗. You get the email exactly as the guest would receive it if those parts coincide, with the headings and the amounts of the selected property.

When do they go separately after all?

The 🔗 in the swimlane does not mean those emails always leave together. They are bundled when they go out at the same moment. Anything that only becomes due later simply becomes its own message. In practice:

• Together — you drag a card to Confirmed, tick off the down payment and upload the signed contract, all within a few minutes. That becomes one email.
• Separate — you only tick off the deposit the next day. The first email is long gone by then, so the deposit confirmation goes as its own message.
• Separate — the balance reminder, the deposit request and the welcome info hang on a date (so many weeks/days before arrival). Those almost never coincide with anything else and therefore usually go separately.
• Always separate — an email you have set to send separately (✂️) in the flow.

The rule of thumb: everything that is ready within the same quiet period goes together; whatever becomes due afterwards follows separately.

Must one stay separate after all? Set it to send separately in the flow editor with the 🔗/✂️ button on the card. That email then goes as its own message; the rest stays bundled.

Premium: your own flow + your own texts

With premium you click ＋ New flow and then ✎ Edit. Now you can:

• Move emails across the swimlanes and set per email when it goes out — on entering the lane or a number of days before arrival (the ⚙ button). That way you can, for example, send the contract before the down payment.
• Adjust all texts: click an email → the block editor. The starting point is literally the current email text (per language NL/EN/FR), cut into text blocks that you edit freely — including the salutation and sign-off. All values sit as inline variables in the middle of the text, so you write the surrounding text yourself and the value is always correct: {voornaam}, {aankomst}, {vertrek}, {aanbetaling}, {saldo}, {iban}, {kenmerk}, {borgbedrag}, {adres}, {beheerder}, … Panels with fixed text (e.g. the deposit/payment block and the arrival info) come in as a normal editable framed block, with the amounts as inline variables — so you edit that text freely. Truly data-driven tables (the cost table with the booking lines, the list of service providers, the payment button) remain a block token — e.g. {kostentabel} — because the lines and amounts come from the booking; you put free text around them. Order everything with ▲▼, and use Insert to paste a variable or block into your text block. Use framed to put a text block in a styled panel (with an optional frame title) — handy to make, say, the payment details (IBAN + reference) stand out separately.
• Create a completely new email (＋ Create new email): its own name, subject and blocks, linked to a swimlane.
• Contract as attachment: the email editor has the checkbox 📎 Attach contract PDF. Turn it on for your own email (or for a customised standard email) and the contract goes along as a PDF — handy if, for example, you want to send your own email before the down payment with the contract included. For the fixed contract email this happens automatically anyway.
• Drag & order: drag email cards to another swimlane or in front of another card to change the sending order.
• Mute (🔈): want to (temporarily) not send an email but keep it in the flow? Mute it — it stays visible (grey) but is skipped. Also works for the event emails (auto-reply, deposit paid, contract received).
• Live preview: click Preview and the preview appears on the right next to the editor — it refreshes automatically as you type, so you see immediately what the email looks like.

Variables you can insert

In a text block you place values (inline, with the real data filled in) or blocks (tables/panels filled per booking). Use the Insert button or the overview ⓘ Which variables can I use? in the editor.

Values (inline): {voornaam} guest first name · {pand} property name · {aankomst} / {vertrek} dates · {nachten} number of nights · {ref}/{kenmerk} booking reference · {bedrag} total amount · {aanbetaling} · {saldo} · {vervaldatum} · {borgbedrag} · {borgdatum} · {welkomdatum} · {iban} · {adres} · {checkin} check-in/-out times · {beheerder}.

Blocks (filled per booking): {kostentabel} cost lines + total · {terplaatseblok} to pay in cash on site (empty if there is nothing) · {gegevensblok} button to fill in address details · {dienstverlenersblok} service providers around the house · {stappenblok} numbered steps. The preview shows demo data for these blocks, so you can see what they look like — even if your test property does not have them (yet).

A flow is a reusable template: build it once and link it at the bottom under Linked to properties — per property, or in one click to all your premium properties at once. Properties without their own flow keep running the standard flow with the standard texts.

Agents owner / platform

Create agents and link them to properties. An owner sees their own properties; a platform administrator sees all. You can invite an agent to a property, reset passwords, and (platform) create accounts with an owner or platform role.

Support & feedback

Via 💬 Support in the left menu you ask a question, share an improvement idea or report a problem from within the app.

• Choose a type (question, improvement or problem), give a subject and a message, and send.
• Your ticket reaches the Villantis team (by email and in our team channel); you get a reply by email at your own address.
• In the list and in your profile (click your email address at the top right) you see the status of your own tickets — open or resolved.
• The platform sees all tickets and can set them to resolved or reopen them.
• Replying happens in the portal. Below every ticket is a reply field: the platform replies to the reporter, the reporter can add more themselves. Every reply appears below the ticket and is also emailed to the other party (replying to that email just works). If the reporter replies to a resolved ticket, it is reopened.

Reporting

In the left menu, under Reporting, you find the sub-items Operations, Statistics (called Platform for the platform role) and Commission.

Operations owner · agent · platform

An operating statement per property and per year — ready to send to your accountant.

• Per month: rental revenue (net rent, distributed pro rata per night) minus the operating costs, with the occupancy rate.
• Costs are attributed pro rata to occupancy by default (adjustable per cost).
• Choose property + year; a year total at the bottom. Costs with a validity window only appear in the years in which they applied.
• Agent commission automatically appears as a separate cost line (per month, pro rata to the nights) for owner and platform — it is, after all, a cost for the owner. For the agent it is income and is not shown as a cost. The line appears as soon as bookings are linked to the agent.
• Booking costs per channel: set a percentage per booking channel per property (e.g. Nice2Stay, VillaSud, Gites = 18%) under Properties → property → Booking costs per channel. Bookings with that channel get that commission as a cost line Booking costs (channel) on the operating statement (percentage × rental revenue). The channel name is case-insensitive.

Statistics owner · agent / Platform platform

The same dashboard with the health of the rental business. Owners and agents see Statistics — automatically limited to their own properties. The platform sees the same across all properties under Platform, plus the login activity.

• KPIs: properties, GBV, commission, occupancy, outstanding balance and the 12-month revenue forecast. (The number of owners & agents is platform-only.)
• Booking funnel with conversion ratios and open leads.
• Rentals per month (with peak months), leaderboard of best-performing properties, and properties that do well outside the peak season.
• Channel mix and quality (cancellation ratio, returning guests, response time).
• Filter on one property or view everything together; choose the year.
• Platform only: Active now, login frequency per user and login times per day. This login data is never visible to owners or agents.

Commission agent · owner · platform

Record a commission agreement per agent per property (percentage × net rent, with a minimum and a markup). The workflow: the agent proposes, the owner confirms (just like accepting a property). For owner-less properties the agreement applies immediately.

• Agent sees their own accrual per property — earned, still to invoice, invoiced and pipeline.
• Free (manual): the agent marks themselves which commission has already been invoiced (with an optional own invoice reference) — button Mark invoiced / Undo mark. That way you track the status without the platform producing an invoice.
• Premium per agent, by platform: automatically generate a commission invoice (PDF) (with your own invoice details + archive) and the per-booking detail view (click Details per booking for the individual lines, with marking per booking). Enabled under Agents → agent → Premium.
• Owner / platform see per agent what has accrued on the properties (read-only; the agent invoices).
• A booking counts for the agent as soon as it is assigned to the agent. On an owner-less property with exactly one commission agent that happens automatically for all bookings — no per-booking assignment needed.

The guest flow

This is how a booking unfolds for the guest, from enquiry to stay:

1. Enquiry via your website/booking widget → the guest gets an auto-reply, you get a notification.
2. Offer: you set the booking to "Offer" → the guest receives the quote with the price and a button "Fill in your details".
3. Guest details: the guest fills in address, postcode, city, country (and possibly a pet) on their own booking page.
4. Confirmation: after the down payment you set the booking to "Confirmed" → the rental contract (with the address) goes along automatically.
5. Balance, deposit, welcome: the balance reminder, deposit request and practical arrival information follow automatically at the right moments.

Below each of those emails is a link to their own booking page, where they can see the status and update things themselves.

My booking (guest page)

Below every guest email — from the confirmation of their enquiry onwards — is a link "View your booking →". It opens their own page on villantis.com: one page with everything they need to know about their stay. The link works with the reference and a secret key of that one booking; there is no login and no one sees anything of another guest. The link expires 90 days after departure — after that there is nothing left for the guest to do or see, and a forwarded email should not grant eternal access to address details. The guest then gets a polite notice that the page is closed.

What the guest sees there:

• The current status — enquiry received, proposal sent, confirmed, everything paid, cancelled.
• What is still expected of them — fill in details, down payment, balance (with the due date), security deposit, return the signed contract. Completed items get a checkmark.
• Their amounts — the same cost table as in their emails, including what they pay on site.
• Their details and their extras, exactly as on the separate pages before. Those two are only there if the corresponding checkboxes are on.
• Cancelling — see below.

Reviews — the guest writes, you decide

If Ask for a review after the stay is on (Communication tab, off by default), the guest gets one request shortly after their stay with a button to their booking page. There they give stars (1–5) and optionally a comment. The review lands in the platform: a ⭐ with the score appears on the card, the full text sits in the reservation, and you decide what to do with it — put it on your site, ask for a Google review, or leave it be.

• Overridable per booking, in both directions: property on → can be turned off per booking on the card; property off → can be turned on per booking ("Follow the property" is the default).
• The request goes out once, at the configured moment (default 7 days after departure, adjustable under "When does which email go out?") and only within 45 days after departure — if you flip the switch later, we do not retroactively email guests from months ago.
• The booking page must be on (that is where the review lands); you get a Slack alert as soon as one comes in.
• All reviews together: Reporting → subtab ⭐ Reviews — with the average, per property and per guest, newest first.

Cancelling is a request, not a button

The guest sees what a cancellation costs today according to your property's cancellation scale, and can submit a request. An explanation is mandatory — you must be able to decide on it. Nothing is cancelled automatically: you get an email and a Slack alert, and the card sits on the board with ⚠️ cancellation requested. In the reservation you then choose:

• proceed — set the status to Cancelled; the cancellation email with the settlement goes out as always;
• decline — button Decline request. The guest sees that on their page; send them a message about it yourself (the reply field in the same drawer).

Once payments can be made in the platform, this request can become a real cancellation. Until then the settlement remains manual work, and therefore your decision.

The three checkboxes (Communication tab)

• Own booking page ("My booking") (on by default). Off: no link below the emails and the page is not reachable. The buttons Fill in your details and Compose your stay keep working — they open the same page, but without status, amounts and cancelling.
• Offer extras in the guest emails (on by default). Off: no extras table in the offer and no separate extras email. The extras themselves remain — you record them yourself on a booking. In the E-mails overview that card turns grey with "off".
• Let the guest fill in their own address details (on by default). Off: no "Fill in your details" button in the offer. The contract does need an address, so fill it in yourself on the reservation — otherwise the contract keeps waiting.

The texts, the moments and the order of the emails themselves stay under E-mails.

Property site — its own page on villantis.com

On a property's Site tab a single checkbox puts its own page live at villantis.com/pand/<pand-id>. The page builds itself from what is already in the platform: name, tagline, logo and accent colour, photos, season prices (or a from-price with the flexible model), the bookable extras and the booking widget. Every time you save the property, the page is refreshed; untick the checkbox and it is taken down.

Three situations: no site of its own → turn the property site on (free); own domain name wanted → coming soon as premium (our page behind www.yourvilla.fr); already a full website of its own (like La Bastide du Papillon) → leave the property site off and use the booking widget there — the tab then shows a hint, so two pages do not accidentally end up side by side.

• Four styles — Garrigue (warm southern French), Modern (clean, lots of white), Élégance (dark, luxurious) and Azur (light, coastal). Your logo and accent colour colour the page further; each style deliberately has its own character.
• The page is in the property's first language; the widget on it follows the same language.
• You manage the intro text, the features (labels like "4 bedrooms") and up to six extra sections (heading + text — history, surroundings, location) yourself on the Site tab. Photos are uploaded on the same tab (automatically resized; the first is the header photo, order with ◀ ▶, maximum 12). Reviews go on the page with the Show on the property site button on the booking's card (section "What guests say", newest first, maximum 6); remove them with the same button. Coming soon: (premium) an own domain name.

Booking widget & links

Per property you find these integrations in the property settings (Integrations tab):

• Booking widget: an <iframe> for your own website — the visitor picks dates (with half changeover days) and sends an enquiry that is automatically linked to the right property (and agent). Below the widget is a fallback link ("Booking calendar not visible? Open the booking form →") that opens the booking as a standalone page on villantis.com — handy when a strict network or privacy setting blocks the iframe. You can also share that same link on its own as a booking link.
• Channel iCal: dates only, no guest data — this is the link you paste into Booking.com or Airbnb so your bookings block their calendar.
• Private iCal calendar: subscribe your calendar app (Proton, Apple, Google, Outlook) to the live bookings.
• Week overview for the owner: a read-only page behind a secret link — see Week overview.
• External calendars (iCal import): paste the iCal export URL of a channel (Booking.com, Airbnb, Google — up to five per property) and its reservations become shadow bookings: dates blocked in the calendar, widget and your own iCal, visible on the board and week overview with the channel as source, and never a single email — the channel handles its own guest communication and payment. Refreshes every ~30 minutes. If a reservation disappears from the feed, the shadow booking is cancelled and the dates are freed. For the other direction, paste this property's channel iCal (dates only, no guest data — never the private calendar) into the channel — two one-way feeds make the two-way sync. Mind the limits of iCal: dates only, no guest details or amounts, and channels refresh imported calendars on their own schedule (up to a few hours), so a small double-booking window remains. That window is guarded: when an imported reservation overlaps an existing booking (a direct one, or one from another channel), the card is still created but marked as a double booking in its log, and the owner receives an alert email naming both references — within one sync round (≤ 30 minutes). Back-to-back stays on a changeover day are not a conflict. Tip to keep the window minimal: after confirming a direct booking, use the channel's manual calendar refresh (Booking.com has one in the extranet).
• Rates block: an <iframe> for the rates page of the property's own website — season prices, additional costs (cleaning, linen, deposit, tourist tax) and extras, rendered live from the platform. Change a rate in the portal and every connected site shows the new price immediately; a hand-maintained price table can never drift again. The styling follows the site via parameters in the src: &accent= and &ink= (colours, %23 = #), &font= (the site's typeface) and &bg= (background — transparent by default, so it sits on the site's own background); language via &lang=nl|en|fr. The block reports its own height, so it never shows a scrollbar.

Week overview for the owner

One read-only page for the phone: who is staying when, with how many people, and what the checkmarks say (down payment, balance with its expected date, security deposit, signed contract). Pending enquiries and offers appear in their own muted style, gaps show as "free", and the current stay is highlighted.

Put it on the home screen and it behaves like an app. On iPhone: open the link in Safari → share button → Add to Home Screen. It gets the Villantis icon with the property name underneath, opens full-screen without browser bars, and shows fresh data every time it is opened. Android (Chrome) works the same via Add to home screen.

School holidays from four countries are marked automatically — the Netherlands (north/centre/south, rijksoverheid.nl), France (zones A/B/C, the ministry's open data), Belgium (the Flemish and French communities, whose calendars genuinely differ since 2022) and Germany (all 16 federal states): occupied weeks get a 🇳🇱/🇫🇷/🇧🇪/🇩🇪 chip, and a free gap that falls in a school holiday gets an amber signal — that is your most valuable unsold week. The same chips appear on the booking card and in the calendar. A stay counts as "in the holiday" from 3 nights of overlap; when only some regions match, the chip names them (e.g. herfstvakantie · midden+zuid, hiver · A+C, toussaint · fr). Germany is the exception: with 16 states the chip shows just the flag and the holiday — which Bundesländer are off is in the chip's tooltip. Short one-off breaks (the French Ascension bridge, loose German Pfingst days) are deliberately left out. The nightly quality control warns per country when the dates for the next school year still need to be loaded.

• Turning it on: property settings → Integrations tab → "Week overview via a secret link". The switch is off by default.
• No login — the link is the key. The URL contains an unguessable token; share it only with the owner. New link revokes the old one instantly (allow up to a minute for every server to pick it up).
• What it shows is configurable per property (three checkboxes under the link): the booking channel, the payment checkmarks and the school-holiday chips can each be switched off. Who is staying when is always on it. The channel chip names the source of every booking — including Direct. The school-holiday switch also drives the chips on the board and in the calendar — one preference, three places.
• Deliberately sparse: no guest email addresses, no phone numbers, no amounts. For those there is the portal. The page also tells search engines not to index it, and it is never linked from any public page — so it cannot be found, only shared.
• Own stays: on a manual booking, pick "Eigen verblijf" under "How it came in" — the week overview then shows a house chip instead of payment facts. Combined with an empty e-mail address (shadow booking) no guest mails are ever sent for it.

Smart features

• Soft-book — an enquiry/offer already holds the dates as an option, so you never sell twice.
• Shadow booking — a booking that counts in calendar/board/reporting but sends no emails. Ideal for loading an existing schedule in parallel before going live. Untick it to set it live.
• Half-day changeover days — departure and arrival days as half days, so changeover dates line up.
• "Do not rent again" — flag a guest (with a reason); you get a warning on a new enquiry, but always decide yourself.
• Custom sender domain (premium) — send guest emails from your own domain via SES DKIM verification.
• Signature on the contract — per property an uploaded image or a name in a handwriting font.