Everything we have built into the platform — chronological, per feature.
The iCal import now raises the alarm when a channel sells dates you already booked.
iCal connections have an inherent blind spot: a channel refreshes your calendar on its own schedule (up to a few hours), so in that window a guest can still book dates that were just sold directly. The import now detects the collision: when an incoming reservation (new, or one whose dates shifted) overlaps an existing booking — a direct one, or a shadow booking from another channel — the card is still created (the dates are sold), but it carries a double-booking note in its log and the owner receives an alert email naming both references and the overlapping dates, within one sync round (≤ 30 minutes).
Back-to-back stays (arrival on someone else's departure day) are a changeover, not a conflict, and a channel's own feed never conflicts with itself. To keep the window as small as possible: after confirming a direct booking, refresh the connected calendar in the channel's extranet — Booking.com has a manual sync button for imported calendars.
Paste a channel's iCal link and its reservations block your dates automatically.
Properties on the flexible pricing model get a year grid next to the period rows: every day shows its price, gaps stand out in red, and setting a price is click start day → click end day → type the amount. Built for apartments where prices change often — TEFAF week up, a November weekend down, done in seconds. It is a friendlier window on the same period rows (one source of truth), and an automatic parity test guarantees the calendar and the price engine always agree.
Built for apartments, useful everywhere. Prices now have a yearly pattern (dd-mm periods that repeat — a price can never expire) plus year-specific exceptions that override it and expire by themselves: a trade-fair week at € 189 is one tick in the price calendar. Periods can carry a Friday/Saturday-night rate, and a long-stay ladder (e.g. ≥ 7 nights −10%, ≥ 28 −20%) is applied automatically as the discount on new enquiries — visible in the offer, contract and on the rates block. OpenGDS/Nice2Stay receive all of this automatically: rates are pushed per date from the same engine. Every combination is guarded by an engine-parity test suite.
You now enter the price per night and the calendar computes the week live (weekly-priced properties store ×7). An "only this year" tick stores exceptions, a weekend field sets the Fri/Sat rate, closures can be set and lifted straight from the grid, school holidays show as ▾ markers with details on hover, and the year arrows browse ahead. Properties on fixed weekly prices see their real engine prices in the grid too (read-only — the seasons stay where they are), with closures editable. Fixed: the calendar sometimes opened behind the property panel, and "clear price" left a year-specific price standing.
The link you give to Booking.com or Airbnb is now a dedicated channel iCal: it blocks your dates there but carries no guest names, emails or messages — those stay in the private calendar, which is for your own calendar app only. Both live on the Integrations tab, now on friendly villantis.com addresses; the public JSON row is gone (channels speak iCal, and the booking widget reads the data directly).
On the Integrations tab you can now add the iCal export links of your channels — Booking.com, Airbnb, Google, anything that speaks iCal (up to five per property). Their reservations become shadow bookings: dates blocked everywhere, shown on the board and the week overview with the channel as source, and never a single email — the channel does its own guest communication. Feeds refresh every ~30 minutes; a reservation that disappears from the feed is cancelled automatically, freeing the dates. Import this property's channel iCal (dates only) into the channel too and the sync works both ways.
One iframe on your rates page; the platform is the single source of truth.
Owners' own websites often carry a hand-maintained price table — and those silently drift the moment rates change in the platform. The Integrations tab now offers a rates block: one iframe snippet for the site's rates page showing the season prices, additional costs (cleaning, linen, security deposit, tourist tax) and bookable extras, rendered live from the same configuration that prices the offers. Change a rate in the portal and every connected site shows it immediately.
The block dresses itself in the site's style: a transparent background by default, and accent, ink, font and bg parameters to match colours and typeface — plus lang for NL/EN/FR. It reports its own height, so no scrollbars. The booking widget and the property site already updated live; the last hand-maintained copy of the prices is now gone too.
One emblem across the whole platform.
All pages now carry a favicon — the portal, villantis.com, the guest pages, the documentation, the week overview and the property sites. One emblem, so a Villantis tab is recognisable at a glance.
Owner feedback: holidays optional, the booking source front and centre.
Three checkboxes under the week overview link (Integrations tab) decide what the page shows per property: the booking channel, the payment checkmarks and the school-holiday chips can each be switched off. Who is staying when is always on it. And the channel chip now also names Direct — a direct booking is a source too. The school-holiday switch also drives the chips on the board and in the calendar: one preference, three places.
"How it came in" can now be changed on an existing booking (the card's edit view) — not just when adding one. Handy for marking a stay as Eigen verblijf after the fact: the card and week overview then show the house chip and drop the payment facts. Channels that came in via an import (VillaSud, Nice2Stay, …) stay selectable, so editing another field never silently erases the source.
France, Belgium and Germany join the Dutch chips — each from its official calendar.
Next to the Dutch chips, bookings and free weeks now also show the French school holidays — Toussaint, Noël, hiver, printemps and été, per zone (A/B/C). A February week might read 🇫🇷 hiver · A+C next to 🇳🇱 voorjaarsvakantie · zuid: two markets off school in the same week. The dates come from the French ministry of education's official open data; the short Ascension bridge is deliberately left out. The same 3-night rule applies, and the nightly quality control now watches each country's date coverage.
Belgium has had two genuinely different school calendars since 2022: the Flemish community and the French community can be weeks apart (autumn 2026: Flanders 2–8 November, the French community 19 October–1 November). The chips name the community — 🇧🇪 toussaint · fr, 🇧🇪 herfstvakantie · vl — so you see exactly which Belgian families are off.
German Ferien differ per Bundesland — sixteen calendars, deliberately staggered. All sixteen are in the data, but the chip stays calm: just 🇩🇪 herbstferien; hover it to see which Bundesländer are off (e.g. MV+SN for the February Winterferien). Loose single Pfingst days are left out.
Dutch school-holiday chips everywhere dates matter — plus a repaired nightly report.
Bookings and free weeks now show which Dutch school holiday they fall in — on the booking card, in the calendar and on the owner's week overview. The dates are the official national ones (rijksoverheid.nl), including the north/centre/south regions: a chip like herfstvakantie · midden+zuid tells you exactly which families are off school. Best part: a free week that falls in a school holiday gets an amber signal on the week overview — that is your most valuable unsold week. A stay counts from 3 nights of overlap, so a booking that merely touches a holiday's edge is not dressed up as a holiday booking. The nightly quality control warns when next school year's dates need loading.
The nightly check itself ran fine, but its Slack message silently failed for days: a routine deploy had reset the platform's permission list and dropped access to the table holding the Slack webhook — which also broke the Support view. Both are fixed, the permission list now lives in one place only, and an automatic test guards that every table the platform uses stays in it. Silence from the night watch will not go unnoticed like this again.
The week overview installs like an app, and new users get a guided start.
Add the owner's week overview to the phone's home screen (iPhone: Safari → share → Add to Home Screen) and it now behaves like an app: the Villantis icon with the property name underneath, full-screen without browser bars, and fresh data on every open.
The documentation now opens with a six-step walkthrough for first-time users: signing in, creating your property, what every settings tab does, previewing the emails, one test booking, and the go-live checklist — with links into the detailed sections.
One secret link — who is staying when, with how many, and what has been paid.
On the Integrations tab you switch on a read-only page at my.villantis.com/weekstaat: the current stay highlighted, upcoming bookings per month with the number of guests, a dog chip, the channel, and the payment checkmarks — including the date the balance is expected, with an amber signal when it is overdue. Enquiries and offers appear in their own muted style; free weeks show as gaps.
There is no login: the link itself is the key (an unguessable token) — share it only with the owner. New link revokes the old one on the spot. The page is deliberately sparse: no e-mail addresses, no phone numbers, no amounts — and search engines are told to stay out.
Staying in your own house? On a manual booking, choose Eigen verblijf under "How it came in". The dates are blocked like any booking, and the week overview shows a house chip instead of payment facts. Leave the e-mail address empty and it is a shadow booking — no guest mails, ever.
Guest emails wait a few minutes after your last change, so several changes bundle into one message and you keep a short correction window. That waiting was invisible — you dragged a card and wondered why nothing hit the inbox. The card now shows a badge: ✉ sends in ~4 min, with the queued emails in the tooltip. It is fed by the exact decision logic that does the sending, so the badge and the mailbox can never disagree.
An email that only becomes due because another one was just sent (fully-paid confirmation → "additional amount due" for invoiced extras) could sit until the 07:00 full round. The quick round now takes one extra look after every send, so chains go out within minutes too.
One checkbox, four styles — the page builds itself from what is already there.
A review that has come in can be put on your property's page with a single button: Show on property site on the booking's card. The "What guests say" section shows the stars, the text and the first name — newest first, six at most. Removing it works with the same button; the site refreshes immediately. In the Reviews overview you can see which ones are on the site.
On the new Site tab you put a page of your own live at villantis.com/pand/<pand-id>: name, tagline, logo, photos, seasonal prices, extras and the booking widget — built automatically from your property settings and refreshed every time you save. Checkbox off = page gone.
You choose from four styles (Garrigue, Modern, Élégance, Azur), each with its own character; your logo and accent colour make it personal. Photos, intro text, features and extra sections are managed by you on the Site tab — photos are resized automatically on upload, the first one is the header photo. Coming soon: reviews on the page and a custom domain name (premium).
Guest links with an expiry date, and a foundation that has become faster and stricter.
Shortly after the stay, the guest can receive a single request to share their experience — stars and a comment, on their own booking page. The review lands in the platform: ⭐ with the score on the card, the full text in the reservation, and a Slack notification. You decide what to do with it.
All reviews are gathered under Reporting → ⭐ Reviews, with the average. And the request also works for properties with their own (premium) e-mail flow — it is tied to the moment, not to the flow, so a flow built before this feature does not miss it.
Per property on/off on the Communication tab (off by default), and can be overridden per booking in both directions. The request goes out once, at the moment you choose (default 7 days after departure, adjustable under "When does which e-mail go out?") and only within 45 days after departure — so switching it on later does not belatedly e-mail guests from months ago.
The "View your booking" link (and the older details and extras links) kept working forever — even years later, even if the e-mail had been forwarded. Ninety days after departure there is nothing left for the guest to do or see; the page then closes with a polite message. The security-deposit return e-mail falls comfortably within that window.
The money logic (offer amounts, cancellation settlement, security-deposit and down-payment dates) is now verified by 22 separate tests before every rollout. Deploying is only possible from committed code. The processing round that runs every two minutes now only visits properties where a guest e-mail is ready, instead of scanning everything. The portal's translation dictionaries live in their own file, and the platform runs on Node.js 22.
Cancelling with the security deposit settled, a down payment with a date, and replying to support tickets in the portal.
A ticket could only be marked resolved; replying had to happen outside the portal by e-mail, and the reporter never saw in their own overview what had become of it. Under every ticket there is now a reply field: the platform answers the reporter, the reporter can add to it themselves, and every response appears under the ticket and goes by e-mail to the other party. If the reporter responds to a resolved ticket, it is open again.
Same story as with the public API earlier today: the list of portal-API routes was only created when the environment was first set up. There were 57 live and 40 in the script — everything added by hand since then (documents, flows, reporting, import) existed only in AWS. The list is now compared and completed on every rollout.
The lines were jumbled and you had to add things up yourself. Now it runs from top to bottom: first everything that has come in, with a Total received, then the cancellation charges deducted from it, and as the closing line To be refunded (or Still to pay).
An adjusted amount is no longer a separate charge but a single line: the original amount struck through with the new one next to it, and underneath in small print adjusted by us.
The cancellation settlement left the security deposit out of the picture, even though that money is sitting with us: the guest was told they would get nothing back, and had to hope the deposit would still come separately. Now everything that has come in counts — the down payment (or the full rent when paid in full) plus the received security deposit — and one amount rolls out: refund or additional payment.
What has come in is listed line by line: Down payment received € 675, Balance payment received € 1.575, Security deposit received € 750 — instead of one amount of € 3.000 that leaves the guest guessing where it came from. If only the down payment is in, that is the only line shown.
At the same time, the sum took no account of what had actually been paid: it assumed the down payment was in, even when that checkbox was off. The Already paid line now follows the checkboxes under Payments. On the reservation itself you see the same calculation before you drag the card.
If you waive (part of) the cancellation charges, the guest only saw the lower amount — not that something had been done for them, and with a second e-mail also not what had changed. The settlement now shows both lines: Cancellation charges (30 % · 180 days before arrival) € 300 and below it Adjusted by us € 0, with the sentence: "We have adjusted the cancellation charges for you: instead of the € 300 our terms prescribe, we are charging € 0." In NL/EN/FR. If you simply apply the scale, nothing about the e-mail changes.
The field to override the cancellation amount was tucked away between "number of children" and "discount". It now has its own Cancellation block in the reservation, with above it what a cancellation means today: "If you were to cancel now, the scale says 30 % (€ 300) is due" — and for a cancelled booking, what has been settled and whether the guest gets money back.
Leave it empty = the scale from the contract, 0 = waived, or enter your own amount. It now also says that timing matters: if you only set it after dragging the card, the guest already has the old settlement in their inbox. For that case there is a Resend cancellation e-mail button, so a correction actually reaches the guest.
Note: the date counts from the day the offer was sent. In a preview — where no offer has ever gone out — today counts, so the preview shows the same sentence the guest sees.
"On reservation" was the only moment without a deadline, and that made it hard to place among the others. There is now Down payment (days after the offer), default 7. That date appears in the offer — "transfer the down payment of 30 % (€ 675) before 20 August" — and if it passes without the money coming in, you see ⏳ down payment overdue on the card. The date is never later than the balance date or the day before arrival, however you set the term.
The percentage sat as fixed text in the offer e-mail, even though it is configurable per property. At La Bergerie Callas (25 %) the amount was right — € 675 of € 2.700 — but the sentence below it said 30 %. The percentage now comes from the property setting, in all three languages.
56, 14 and 7 read like a strange order until you realise they are days before arrival — so a larger number is earlier. The three now sit together on the Communication tab, with the order below in plain language: balance reminder 56 d → security-deposit request 14 d → arrival information 7 d. Put them out of order and that line turns orange and the nightly quality check reports it.
What belongs where: Communication = when we send the guest something. Contract = the deadlines the guest is held to (cancellation scale, security deposit back within … days after departure). The two tabs now point to each other.
The deadline for the security deposit was fixed at one week before arrival, while the request goes out at a configurable moment. If you set that to 5 days, the e-mail asked for a transfer before a date that had already gone by. The deadline now moves along — normally a week, and with a later request the guest keeps two days. The contract states exactly the same term, from the same calculation.
Under every e-mail a link to their own booking: the status, their details, their extras, and cancelling as a request.
From the confirmation of their enquiry onwards, every e-mail to the guest carries a link at the bottom to their own booking page. It shows at a glance where their booking stands, what is still expected of them (details, down payment, balance with due date, security deposit, signed contract) and what the stay costs — the same cost table as in their e-mails, including what they pay on site.
The link works with that booking's reference and secret key. No login, no password, and nobody sees anything of another guest.
The guest had two separate pages: one to fill in their address, one to choose extras. Those are now sections on the same page. The buttons in the e-mails point to the right section, and links you sent earlier keep working — they redirect.
If the booking page is switched off for your property, those two buttons simply keep working: the guest then sees only the section they came for, without status, amounts and cancelling.
The booking page only said "Fill in your address details". It now also says why: the rental contract is waiting for it and follows immediately afterwards for signing (or, if the booking is not confirmed yet, as soon as it is). And the note accompanying a cancellation request has become mandatory — a request without a word of explanation is impossible for you to judge.
The guest sees what a cancellation costs today according to your property's cancellation scale, and can submit a request with an explanation. Nothing is cancelled automatically: you get an e-mail and a Slack notification, and on the board the card shows ⚠️ cancellation requested.
In the reservation you either put it through (status to Cancelled → the cancellation e-mail with the settlement goes out as always) or decline it with Decline request. The guest sees that on their page; the accompanying message you send yourself, using the reply field in the same drawer. Once payments can be made in the platform, this can become a real cancellation — until then the settlement remains your decision.
The switches for what the guest can do themselves were tucked away under Prices & costs. They now have their own tab in the property settings, with a pointer to E-mails for the texts and the moments. One has been added: Own booking page ("My booking"), on or off per property — some owners do not want this feature.
The "paid in full" e-mail said "we will send the practical arrival information shortly before your stay". Shortly is vague; it now shows the date that e-mail actually leaves — "around 27 February 2027" — just like in the down-payment e-mail.
That date comes from a setting you could not see until now: Welcome info (days before arrival), default 7. Together with Security-deposit request (days before arrival) it now simply sits under Costs & conditions, next to the balance term that was already there. Set it to 8 and the e-mail and the date in the text move along.
The E-mails overview also said "shortly before arrival" for those e-mails. It now shows the actual number of days of the selected property.
In the down-payment, balance and offer e-mails, properties with fixed weekly prices showed both "To pay on site: Final cleaning € 250" and, a paragraph further on, "To pay separately: Final cleaning € 250". That second line dated from the time when fixed weekly prices had no cost table yet. One of the two renderers had already been adjusted for that, the other had not — it now has.
A contact showed "petok ›" — the bare key from the code. Every line now has a description (Pet confirmed, Rental contract sent, Signed contract received, Cancellation request, …), in all three languages. That list used to be maintained by hand; a test now derives what should be in it, so a new e-mail type does not land on your screen as a key again.
Under Payments there is now also Balance payment received, with the amount shown. Tick it and the booking moves to Paid in full; drag the card there and the checkbox is set. Remove the tick and the card goes back to Confirmed. One fact, one place — no two ledgers drifting apart. The "paid in full" e-mail is from now on tied to that same checkbox, just like the down-payment e-mail.
The amounts next to those checkboxes now come from the same calculator as the guest e-mails. The board used to recalculate the down payment itself as rent × percentage, leaving out the costs, the tourist tax and the chosen extras — so the amount on your screen could differ from what the guest saw on their invoice.
The contract only mentioned the price after discount. Now there are three lines — Rent € 2.500, Discount (10 %) -€ 250, Rent after discount € 2.250 — so the guest also sees, in the document they sign, that they got a discount and how much. No discount? Then it stays one line, exactly as before.
The cost table only showed a dash with an amount ("− € 250"). It now says Discount (10 %), with the percentage if you entered the discount that way. E-mail and booking page take that label from the same place, so they cannot drift apart — the page, for instance, still showed "Extras" where the e-mail already named the extra.
The cost table showed a line "Extras € 50" — which ones, the guest was left to guess. Now the name is there: EV Charging € 50. And an extra that is paid on site appears in the block listing what they settle on arrival; before, it only appeared in the separate confirmation e-mail, which no longer goes out before the offer.
The header of a column only counted bookings ending this year. An enquiry for next season did appear as a card in the column but was not counted — so from summer onwards you saw "€ 0" above a column full of work. Header and cards should say the same thing: count and amount now cover exactly what is open, this year and further ahead. Older years stay collapsed with their own count and total.
If you record an extra at "+ Booking" (the charging station, say) and drag the booking to Offer, the first thing the guest received was "Thank you! We have noted your choice of the following extras" — for something they never asked for — and only then their offer. That e-mail was not tied to a swimlane and therefore went out immediately, bypassing both the bundling and the quiet period.
Now no separate confirmation goes out before the offer: the extras simply appear in the offer. If the guest later adds something themselves, the confirmation does follow — neatly behind the rest and with the same quiet period.
The offer showed the charging station in the cost table and again a paragraph further on under "Would you like some extra comfort?". Whatever is already on the booking is no longer offered, and if nothing remains to choose, that entire block disappears.
At the bottom of every guest e-mail it said "Questions? Just reply to this e-mail, or write to us at …" — followed by the sender address. For properties without their own sender domain that was no-reply@villantis.com, precisely the address where writing is pointless. It now shows the property's own e-mail address (Owner e-mail, otherwise Sender e-mail). If a property has no address of its own, the footer no longer names one and only "reply to this e-mail" remains — replies always arrived fine, as they are forwarded separately.
The list of public routes (enquiry, availability, iCal, details, extras) was only created when the environment was very first set up. After that, things were added by hand and the script fell behind reality. The list is now compared and completed on every rollout.
Two switches per property — no premium required.
Under Prices & costs there are two checkboxes under What the guest sees in the e-mails:
This is deliberately not a premium feature: it does not build a custom flow, it switches a block off. In the E-mails overview the extras card turns grey with "off", so you can see why nothing is coming. And the nightly check reports it if you do have extras configured while they are offered nowhere — otherwise there is a price no guest ever gets to see.
The dog was there right away, the extras only after you had chosen a period — because their price depends on the number of nights. It therefore looked as if a property had no extras. You now see immediately that they exist, with a note that the price follows once the period is chosen.
Dog and extras recorded right away on a booking of your own — and one e-mail fewer for the guest.
When you take a booking by phone or messaging app, you often already know whether a dog is coming along and whether they want the charging station. You now tick that straight away in the dialog: the dog is there if the property allows them, and the extras appear once the period is chosen — with the price calculated for the number of weeks, nights or persons.
Because you are taking the booking yourself, it is immediately confirmed: no enquiry that you then have to approve to yourself.
Drag a booking to Confirmed and the down payment, the balance, the contract and the security-deposit request could go out as four separate e-mails within the same minute. From now on they become one e-mail: one greeting, the parts one below the other with a divider, one sign-off, and the contract as an attachment. The subject is about the part the guest needs to act on — if the contract is included, the e-mail is named after it, so it can be found again later.
Each part is still ticked off separately, so nothing goes out twice and your communication history stays readable per type (with the note sent bundled).
The line "These are bundled…" sat as a separate column next to the e-mail cards instead of below them. A swimlane is a horizontal row, so that line took away width and squeezed the cards together — making it look as if an e-mail was missing. The line now sits above the cards, across the full width.
Also fixed: in a bundled preview the same heading appeared twice above the extras, because that table already carries a title of its own.
In the preview of an e-mail you did not see the Build your stay and Fill in your details buttons. They hang off a link with the booking's reference, and the preview booking does not have one — so it did not draw the button at all. You were therefore looking at a different e-mail than the guest receives. In a preview those buttons now point to the property's website, so you see them and a click does not produce an error. In the real e-mails they always worked.
The parts ran into each other. Now each section has a heading — Your down payment, Your rental contract, Security deposit received — with a thin divider above it, so a guest sees at a glance that there are several things in it.
You can also view such a combined message before it goes out: in the swimlane, next to the 🔗, click view preview and you see the e-mail exactly as the guest would get it — with the headings and the amounts of the selected property.
If the security deposit was already in, the same e-mail first contained the payment instruction ("transfer before 2 January") and, a paragraph further on, the confirmation that we had received it. The payment instruction and the separate security-deposit note now disappear as soon as you have ticked Security deposit received, and a box that would be left empty as a result is no longer shown at all. The preview now takes this into account too — it used to show an instruction the guest had long stopped receiving.
A guest e-mail only goes out once you have not changed anything on the booking for a few minutes. Drag a card to Confirmed and tick off the security deposit half a minute later, and previously the first e-mail was already on its way and the guest got two after all. Now the system waits until things are quiet and everything goes in one message.
A bonus that comes with it: a correction window. If you notice within that time that the amount is wrong or that you dragged the wrong card, the guest has not seen anything yet. The safety-net round now runs every five minutes for this, instead of every quarter of an hour.
The e-mails tied to a checkbox — security deposit received, pet confirmed/declined, signed contract — now join the bundling too. They used to sit outside the flow and therefore still went out separately.
In the E-mails overview you see per swimlane which e-mails can go together: they get a 🔗 and below the lane it says "These are bundled if they go out at the same time". Mind the word at the same time: if you only tick off the security deposit the next day, the first e-mail is long gone and the deposit confirmation follows as its own message. Date-driven e-mails (balance, security-deposit request, welcome info) therefore usually go separately. If one has to stay separate after all — the contract, for instance — set it to send separately in the flow editor with the 🔗/✂️ button. That e-mail then goes as its own message, the rest stays bundled.
The "add extras" e-mail also went out when the guest had long since chosen — via the booking form, their own extras page, or because you recorded it when taking the booking. That e-mail then asks about something already answered, and is now skipped.
The booking form on an owner's site was lagging behind. That can no longer happen unnoticed.
Extras are saved in two places: with the extras' own button and with a full property save. The second one knew the new choice per week / per night / per person, the first did not — it rebuilt the item and left the field out. Your choice therefore came back as "per stay". Both paths now use the same handler.
A test has been added right away that reads the fields from the editor in the portal and checks that they survive saving. If someone later adds a field without updating the save logic, that blocks the rollout.
The "we have received your down payment" e-mail fired as soon as you dragged a card to Confirmed, while the Down payment received checkbox was still off. So the guest received a confirmation of receipt you had not yet given. From now on the checkbox is the signal: switch it on and the e-mail goes out immediately. Next to the checkbox you now also see the amount of the down payment, calculated as in the e-mails (rent minus discount × the property's down-payment percentage).
The two new e-mails were being sent, but did not appear in the E-mails view. Cause: the list of e-mail types existed in two places and they were only in the old, no longer used list. That copy has been removed — there is now one registry. A test has also been added that derives the e-mail types from the source code and blocks the possibility of sending an e-mail you cannot see or preview anywhere.
If a guest travels with a dog, it now appears in the reservation under Pet, with Confirm and Decline buttons and the surcharge shown. The card gets a 🐕 to confirm badge, just like requested extras (➕ 1 to confirm), so you do not have to open every reservation to see whether something is waiting for you.
Press either button and the guest is notified — after all, they asked and read "we will confirm this with you". On Confirm: "your dog is welcome", with how the surcharge is settled (on site or via the bank account). On Decline: that it will not work for this stay and that the rest of the booking is unchanged. Both e-mails go once, can be viewed in the E-mails overview, and can be switched off there as well.
"Linen € 100" said nothing about where that amount came from. It now shows how it is built up: Linen · € 25 p.p. × 4 → € 100. This also applies to pool heating, the charging station and custom charges that count per week, night or person.
When you record a booking yourself, you now pick the period in a calendar instead of two date fields. Occupied days are struck through and not clickable; a changeover day is half-shaded, because one guest leaves in the morning and the next can arrive in the afternoon. The occupancy comes from the same source as the booking widget, so fixed closures and years not yet opened up are in there too. If you pick a period that cuts straight across an existing booking, the selection starts over instead of letting you create a double booking.
In the contract the down payment was still followed by "— before ………" with empty dots, while no due date exists for the down payment at all: it is due on reservation. This line had been amended before, but the correction did not work — a missing date was not returned empty but precisely as dots, so the date variant was always chosen. Now only the amount remains.
At a property with Security deposit (€) set to 0, the Security deposit received checkbox disappears from the reservation — but the save logic still looked that checkbox up. As a result the Save button broke before anything was stored: on such a property you could no longer change the rent, guest name or status. Every field is now looked up before it is read.
Drag a booking without an amount to Offer and no offer e-mail goes out — the flow skips e-mails that need an amount. That happened silently. The reservation now shows a warning next to the amount, with what to do: fill it in and save, and the e-mail follows by itself. The nightly check already flagged this as a point of attention.
The guest pages — the booking form in the iframe, the details page and the extras page — existed in two places. The e-mails and the embed code point to the one, but publishing went to the other. As a result guests were shown the old version for weeks while the portal was long up to date. There is now only one place, and the duplicate copies have been removed.
You do not need to re-place the embed code — it already points to the right place. Refresh the page and you see the current version.
The list of pages to publish is no longer maintained by hand but derived from the directory: a new page goes along automatically. A platform rollout always publishes the pages with it, so they cannot age apart. And every page carries a build stamp that the nightly quality check reads back: if one lags behind, is missing, or a second copy turns up somewhere, it is in the morning report.
An owner with their own rental contract no longer has to fit our mould.
The Contract tab now states at the top which contract a property sends: the platform's standard contract or a customised version. You can switch between them yourself; the custom text is kept if you temporarily fall back to the standard. The property overview lists it per property, so you see at a glance which properties deviate.
The terms and conditions can be filled in per property as articles with a heading and a text, per language separately. Leave a language empty and it falls back to our standard text. This way an owner can use their own terms without anything having to be programmed for each property.
The cancellation terms were the same for all properties (30/35/40/50/75/90/100 %). They can now be set per property as steps: from so many days before arrival, this percentage applies. That same scale drives both the contract and the cancellation e-mail — so the two can no longer contradict each other. The security-deposit term ("deposit back within … days after departure") is also configurable per property.
Under Costs (extended) there is a Charging station block (per week or per stay), and below it Custom charges: name what this property charges yourself, choose per stay / week / night / person / adult and the payment method. Custom charges behave like the fixed ones: they appear in the cost table of the guest e-mails, count towards the total to transfer with "via bank account", and end up in the contract.
Below the costs, the contract always contained the sentence that bed and bath linen are included in the rent — even at properties that charge € 25 per person for it. The contract now follows the cost setting: if the property charges for it, it appears as a cost line with amount and payment method, and that sentence disappears.
The rental-period paragraph invariably stated that high-season rentals run from Sunday to Sunday, with arrival at 16:00 and departure at 10:00 — regardless of what the property said. That sentence now follows the property's changeover day and check-in/check-out times, and disappears entirely with a flexible changeover day. A factual error in a legal document, and exactly the kind of thing you only spot when you actually read the contract.
The enquiry form on your own site now asks straight away whether the guest is travelling with a dog and whether they want to add extras. The prices calculate live with the chosen dates and the number of guests, so with a charging station at € 50 per week, someone staying two weeks sees € 100. Whatever they tick lands on the booking immediately; you do not have to send them back for it later.
If pets are set to on request, it becomes a request: the guest reads that you will confirm it, you see it on the card with a Confirm or Decline button, and the surcharge only counts once you confirm. With allowed it is settled immediately. If no pet is coming along, nothing is charged. The enquiry notification in your mailbox now mentions both as well.
As soon as the pet checkbox was on a booking, the surcharge went into the amounts — even with on request, while the guest read on their details page that we would confirm it first, and even at properties where pets were set to none. Moreover, nobody was notified when a guest requested it, so that confirmation could never come. All three are now right.
Also fixed: the e-mail preview in the portal left the pet out and therefore showed a different amount than the e-mail the guest receives.
The entire Costs (extended) block — linen, pet, pool heating, mid-stay cleaning, charging station and custom charges — only worked with the flexible pricing model. At 11 properties with fixed weekly prices those costs were configured but never charged, without any notice. Both pricing models now calculate with the same engine.
In addition, for a while there were two blocks one below the other that both said "to pay on site". That is one block again, and an empty block disappears entirely.
A bookable extra always had one fixed price for the whole stay. Now you choose per extra whether the price applies per stay, per week, per night or per person. With a charging station at € 50 per week, a guest staying three weeks therefore sees € 150, with "€ 50 per week" underneath — in the offer e-mail, on the selection page and on the invoice.
This lets the guest indicate themselves whether they want to use something, instead of it always being passed on. What the guest ticks lands on the booking and, with "via bank account", counts towards the total.
With Security deposit (€) at 0, the contract merely stated that no deposit is asked — as if damage would never be recovered. It now adds that damage or breakage established after departure will be charged to the tenant at the repair or replacement cost. If a property does ask a deposit, the existing text with amount and repayment term remains.
The quality round now reports when the custom terms mention a security deposit while Security deposit (€) is 0 — the same contract then says in the cost line that no deposit is asked. And when the first step of the cancellation scale does not match the down-payment percentage, because the contract then promises "the down payment (X %)" at a different figure than what was paid down.
Your property's rental contract can now be downloaded, the final cleaning is configurable everywhere and guest e-mails no longer get stuck.
The property's Contract tab has a Rental contract block: pick a language and download the contract that guests of this property receive, as an empty template. Guest name, dates and amounts stay open; everything that comes from your settings — landlord, bank details, security deposit, final cleaning, tourist tax, down-payment percentage and balance term — appears exactly as it will be sent. That way you check at a glance whether your contract is right.
Having a different contract used is not something you can do yourself: the contract text is legally fixed in the platform. For that, ask a question via 💬 Support in the left menu — that is also noted next to the download button.
A property can have periods in which it is not rented out at all: renovation, own use, or not-yet-opened. That already worked — such a period is closed in the calendar, the booking widget, the iCal feed and at OpenGDS — but until now only we could set it. On the new Availability tab you now do it yourself: start and end date plus a short reason. For a connected property the new availability goes to the channel immediately on saving.
Your calendar subscription shows the reason, so you can see why a period is closed. Two closures with the same reason used to merge into one appointment there; that has been fixed right away.
The choice via bank account or on site was only available with the flexible pricing model; properties with fixed weekly prices were immovably set to on site. The choice now applies to every property and works through everywhere: with via bank account the final cleaning appears as a line in the cost table and counts towards the total to transfer; with on site it sits in the "to pay separately" block and stays out of the transfer. The contract follows that choice automatically. Existing properties keep their current behaviour.
Drag a card to a next status and the corresponding e-mail is queued immediately with a separate background job. If that one job got lost — during maintenance on the platform, for instance — the e-mail sat there until the daily 07:00 round. A safety-net round now runs every quarter of an hour doing exactly the same check: anything still open goes out after all, and the availability is updated. Every e-mail still goes out at most once.
The nightly quality round now reports when a live property still has no real landlord name, address, account name, IBAN or BIC. Those fields appear literally in the contract and in the payment instruction of the guest e-mails — if a placeholder value remains there, a guest receives a contract with an unusable account number.
The address a guest fills in on the details page (for the contract) is stored on the contact. If that same guest later books the same property again, their address is pre-filled on that page — they only have to confirm, and can of course still change it. That already worked behind the scenes; what is new is that you now also see and can correct the address in the contact screen, under Address. Handy for a typo in a street name that would otherwise land on the contract just like that.
The Domain field asks for a hostname (pand.nl), but anyone who pasted an address from the browser (https://www.pand.nl/) silently got yet another https:// in front of it — a broken link in the footer of every guest e-mail. The field is now cleaned up on saving, and the quality round checks every property's website URL.
A booking notification in Slack now appears with the property's name and logo as the sender, instead of one generic integration name for everything. With several properties in the same channel you see at a glance which house it is about. If a property has no logo, the default sender remains; if Slack rejects the custom sender, the notification still goes out normally.
Changeover day, fixed closures and opening up booking years were scattered across Prices & costs and Conditions, even though together they answer one question: when can this property be booked? They now sit together on their own Availability tab. Prices & costs is once again about money only.
Behind the scenes the platform wrote an availability.json per property to a separate storage location. Nobody read that file: the booking widget, a property's website and the iCal feed all fetch their availability directly. For nearly all properties that write had been failing for months without it showing up anywhere, and at the only property with such a file the copy sat in a different place than the website read — that copy had been standing still since late July.
That second publication path is now gone entirely, including the write permissions, so it cannot come back. Nothing changes in what you see: the calendar, the widget, the iCal and the sales channel already worked directly from the same source.
In the booking, the block with Down payment received and Security deposit received was still called "Deposit", even though the down payment sits in it too. That is now Payments.
The cost section on the property has been cleaned up and the mid-stay cleaning is now truly configurable.
Next to Security deposit received, the booking now also has Down payment received, with a badge on the card so you see at a glance who has already paid.
Set Security deposit (€) to 0 and it works through everywhere: no more deposit request or confirmation e-mail, the contract states that no deposit is asked, the deposit disappears from the amounts in the guest e-mails and the Security deposit received checkbox disappears from the booking.
The included option only worked with the flexible pricing model. Properties with fixed weekly prices got the tax added anyway — the setting did nothing there. The choice now applies everywhere: nothing calculated separately, no "plus the tourist tax" in the balance e-mail, and the contract states that the tax is included in the rent.
Also fixed in the contract: the down payment was followed by "— before ………" with empty dots, because no due date exists for the down payment at all. That line now simply states the amount, since it already says it is due on reservation. And a final cleaning of € 0 is no longer listed as a cost line.
The export has become a week overview. You choose the year (default the current one) and get all weeks chronologically — including the weeks with nothing booked, as an empty row with the status free. That shows you straight away where the gaps in the season are. Weeks run from changeover day to changeover day.
For a booking of more than a week, the details sit on the first week and the following weeks stay empty apart from occupied, so adding up in Excel works out. Also fixed: the export now follows the property filter — with it set to one property, other properties still ended up in the file.
Until now only bookings via a sales channel announced themselves in the Slack bookings channel. An enquiry via the booking form or a manually recorded booking stayed silent. From now on every new booking arrives there, with property, guest, dates and where it came from.
Returning guests often call, message or e-mail directly — until now those reservations only came in via the enquiry form. With the + Booking button at the top right you put such a booking straight on the board. Fill in property, name, dates and amount; the reference number and guest count are handled by the system. From there the booking follows exactly the same path as an enquiry via the form.
At the top, under Existing guest, you pick someone from your contacts; name, e-mail address and phone number are filled in and stay editable. A new guest you simply type in yourself.
No e-mail goes out unnoticed: by default the booking lands in Enquiry and nothing happens. If you pick a further status right away, the screen warns you that the flow will send the corresponding e-mail. Without an e-mail address it automatically becomes a shadow booking — dates blocked, not a single e-mail.
Properties without their own sender domain send guest e-mails from no-reply@villantis.com — that domain is verified, so the sender has to stay there. If a guest pressed Reply, that response reached nobody. From now on we set a reply-to address on every guest e-mail: the sender remains Villantis, but a reply goes to the e-mail address configured on the property (Owner e-mail, otherwise Sender e-mail). If a live property has no address at all, the quality check now reports it.
OpenGDS manages the room and rate codes itself. If a code is renamed or removed there, OpenGDS still answers our messages with "success" — while nothing happens with them. Availability and prices would then silently stop arriving, without a single error.
From now on we verify the codes before we send anything. If something is off, nothing goes out and you get a Slack notification with the code in question. As soon as you correct the code on the property, synchronisation resumes by itself — immediately when you save in the portal, and otherwise within a few minutes via the daily round.
Bookings that arrive via a channel should always sit on the board as a shadow booking: the channel handles the guest communication, so our own guest e-mails must stay off. One test booking from before that rule missed the checkbox and got a down-payment e-mail anyway. The address did not exist, so no guest was reached. The integration now always sets the checkbox, and the quality check now raises the alarm for every channel booking without shadow — that check used to look only the other way.
Of the 796 texts in the portal, 35 were missing an English and French translation. Such texts silently fell back to Dutch, so an English- or French-speaking user suddenly saw Dutch without anything appearing broken. Everything is now translated, and the quality check guards against untranslated text being added again.
The quality round now also goes through all bookings. The most important rule: a shadow booking must never have sent a guest e-mail — with channel bookings the channel handles that communication itself. It also checks for missing or reversed dates and for bookings attached to a non-existent property.
In addition, we ask OpenGDS itself 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 ever getting an error.
The contract states that the tourist tax applies "per person aged 18 and over", but calculated the amount over all guests. On a booking with children the contract therefore showed a higher amount than the quote e-mail — with 3 adults and 1 child, 7 nights at € 2,20, the difference was € 15,40. The contract now counts adults, and the quality check now compares for every property whether contract and quote state the same amount.
The season periods (which weekly price applies when) could until now only be set behind the scenes — now they simply sit on the property, under Prices & costs, as dd-mm. A period may also run across the turn of the year, for instance 20-12 → 05-01.
In addition you can set per booking year from which date it opens up, and give that year its own periods if desired (handy when the price structure shifts per season). A year that has not been opened up yet is closed everywhere: not bookable in the calendar, blocked in the iCal feed and at zero availability at OpenGDS. An enquiry sent straight to the API is refused as well.
Calculated dates (balance due date, security-deposit date, welcome e-mail) were determined via a detour through universal time. On the server that coincides, but outside that timezone a date could shift by a day. All date calculations are now timezone-independent and are tested in four timezones. A season period running across the turn of the year now also counts correctly — it used to fall back silently to the default season.
A full check round now runs across the entire platform: all e-mail types are rendered for every property in every language and checked by machine (± 1.270 checks) for duplicate cost lines, unreplaced text fields, and a correct sum of down payment, balance and total. On top of that, real tests run against the OpenGDS integration plus an audit of the property configuration. The result arrives as a structured report in Slack, complete with version number.
Per property you now indicate whether it really rents to guests. Live properties are judged strictly in the quality check; properties in preparation may still be incomplete and cause no false alarms. In the property overview you see at a glance which properties are live and which are still in preparation.
You can now indicate per property that a mandatory mid-stay cleaning only applies from a certain number of nights. Enter an amount and leave "mandatory from" empty to charge it on every stay, or put in e.g. 14 so the charge only appears automatically on the quote and in the offer e-mail for longer stays. The old free-text "condition" field (which did nothing) has been replaced by this working setting.
The final cleaning now sits with the other costs, with a choice of payment method. Choose on site and the amount appears under "To pay on site (to the property manager)" and stays out of the amount to transfer; choose via bank account and it is added as a line in the cost table towards the total. The contract automatically follows the same wording.
At properties on the flexible pricing model, the final cleaning appeared both as a line in the cost table (counted in the total to transfer) and in the block "To pay separately — on arrival, on site to the property manager". The guest was effectively presented with the charge twice. The separate text block now only mentions the security deposit; the final cleaning is placed solely according to the configured payment method. Properties with fixed weekly prices are unchanged.
All extra costs (linen, mid-stay cleaning, pool heating, pets, tourist tax) now sit in clearly grouped blocks with amount and payment method side by side. No mandatory mid-stay cleaning needed but still want to offer it optionally? That works as always via the Extras (bookable for longer stays) at the bottom of the property.
Guests can now book even on strictly locked-down networks.
The embedded booking widget is an iframe from another domain; some strictly locked-down (office) networks and privacy settings block such iframes. That is why every embed now has a visible fallback link — "Booking calendar not visible? Open the booking form →" — which opens the booking as a fully fledged, standalone page on villantis.com (first-party, so beyond the reach of iframe blockers). This way everyone can always book, and you can also share that page separately as a booking link.
A clearer calendar, a dedicated support channel and the Villantis logo in the app.
New in the left menu: 💬 Support. Ask a question, share an idea for improvement or report a problem — with subject and message. Your ticket reaches us directly (by e-mail and in our team channel) and you get a response by e-mail. In the list and in your profile you see the status of your own tickets (open / resolved); the platform sees and manages all tickets.
The portal and the website now carry the Villantis emblem — a villa with a cypress and evening sun in the familiar terracotta, sage and gold tones. You see it on the login screen, in the left menu and on villantis.com.
In the Calendar you switch at the top right between Month · Week · Day. In the Week view every property gets its own strip with the guest name in the cell plus 👤 persons and price; the Day view shows per property who is arriving, departing or staying, with persons, price, channel and period. Much clearer than the hover in the month view.
Click a booking in any view (month, week or day) to open the full booking details right away.
The Week strip runs from changeover day through the next changeover day (Saturday or Sunday — detected automatically per property), so each property shows its own rental week. The strip spans 8 days so the closing changeover day — with both this week's check-out (▲) and the next guest's check-in (▼) — always stays visible.
A profile of your own, and two-step verification to protect your account.
Click your e-mail address at the top right for your new profile: set your name and language, change your password and manage your 2FA — all in one place. Agents also find their invoice details there (sender, IBAN, prefix…). The separate language picker and the 🔒 button in the bar have moved here.
You can now secure your account with an authenticator app (TOTP): scan the QR code and confirm with a 6-digit code. For platform administrators 2FA is mandatory (set up once at first login). Owners and agents can optionally switch it on themselves via their profile. When entering your code you can tick "remember this device": the app then skips the code on this trusted computer for 14 days (even after logging out). If you do not tick it, the next login asks for a code again. In your profile, under Devices & sessions, you see a list of your remembered devices (name + last used) where you can forget each device individually, plus "Log out on all devices", which ends all sessions everywhere. Lost your authenticator? The platform can reset your 2FA via Agents → user → Reset 2FA.
Recording signed contracts, and the premium e-mail flow builder taken further.
Store documents on a booking — for instance the signed return contract the guest sends back, but also ID or extra agreements.
In the premium e-mail flow you can now drag e-mails between swimlanes and within a lane to change the sending order. And you can mute an e-mail (🔈): it stays in the flow but is not sent — handy for switching one off temporarily without throwing it away.
In the left menu, Reporting now has two sub-items: Operations (the existing overview per property/year) and Statistics. In Statistics, as an owner or agent you now see the same insight as the platform — KPIs, booking funnel, rentals per month, leaderboard, channels and quality — but limited to your own properties. The login data (currently active / login frequency / login times) stays platform-only. For the platform, the old Platform tab has moved to this spot.
Booking platforms that withhold a commission (Nice2Stay, VillaSud, Gites, …) can now be recorded per property as Booking costs per channel (%) — they automatically appear as a cost line on the operating statement for the bookings via that channel. And on the board every swimlane now shows the year total (this year) instead of the all-time total, with each collapsed year card showing that year's total.
Undeliverable addresses and spam complaints are now handled automatically: SES itself stops sending to such addresses (protecting your deliverability) and the contact gets a warning in the Contacts list (⚠️ bounce / 🚫 spam complaint) next to the e-mail address, so you know which guests you can no longer reach by e-mail.
Every agent can now track for free which commission has already been invoiced (with their own invoice reference). The automatic invoice PDF and the detail view per booking (click the card → Details per booking) are premium — switched on per agent by the platform via Agents → agent → Premium. We are laying this foundation now so that we can later connect payments via Wero.
Commission now sits as a sub-item under Reporting (the separate tab on the left is gone) — for agent, owner and platform in one place. New: on an ownerless property with exactly one commission agent, every booking automatically counts for that agent, without you having to assign each booking separately. Explicit assignment per booking always takes precedence.
On the operating statement, the commission paid to the agent now appears as a separate cost line (per month, pro rata by nights) — so the net result is correct from the owner's point of view. Visible to owner and platform; for the agent themselves it remains income, not a cost. The line follows the normal commission assignment: it appears as soon as bookings are linked to the agent.
The e-mail editor now has a checkbox "Attach contract PDF". Switch it on for your own e-mail (or for a customised standard e-mail) and the contract is sent along as a PDF attachment — exactly as with the fixed contract e-mail. That way you can, for instance, send your own e-mail before the down payment with the contract included. For the fixed contract e-mail this happens automatically.
The week rounded off with dashboards, financial insight and careful handling of guest data.
Templates and Flows have been merged into one E-mails tab. You see every guest e-mail in the context of the flow and click it for a preview; owners adjust (for free) the intro/outro per property.
{aanbetaling}, {iban}, {kenmerk}, …), so you write the text around them yourself and the value always stays correct. Tables/panels (amount table, security-deposit block, arrival info) go between your text as block tokens. You can also put a text block in a box (with a title) to make, say, the payment details stand out.{voornaam}, {aankomst}, {bedrag} and {pand} are filled in automatically. Unmodified e-mails run the standard text unchanged.In the new Flows tab, decide for yourself which guest e-mail goes out at which swimlane status, instead of the fixed standard order.
A complete overview of the health of the entire platform, visible to platform administrators only. Pick a year and, if you like, filter on one property — the whole dashboard then refreshes to that house.
See who is active right now, how often each user logs in (sessions + active days) and at which hours of the day logins happen — with an hourly histogram in local time.
An accountant-ready overview per property and per year: rental revenue minus operating costs, per month with occupancy rate and a year total.
Flag a guest you would rather not host again — set up GDPR-proof.
All guest e-mails reviewed linguistically (NL/EN/FR), based on an external review.
Put an existing schedule on the board in one go: click ⬆ Import, pick the property and upload a CSV. The portal recognises the columns from the header row, shows a preview, and creates the bookings — plus, automatically, a contact for every row with an e-mail address. Everything comes in as a shadow booking by default (no e-mails), with the status derived from the dates. No existing file? Download a ready-made CSV template in the import dialog to fill in.
This release-notes page plus a complete manual of all portal features — reachable from the portal via the 📖 and 🕑 buttons, with the docs button jumping straight to the section for your current page.
The core of the rental process substantially extended and refined.
After the offer, the guest fills in their address details via a secure link (address, postcode, city, country). The details are also stored on the contact, so a repeat booking pre-fills automatically.
The rental contract no longer rides along with the offer with an empty address. It is now sent automatically once the booking is confirmed and the guest details are complete — with the address neatly filled in. On the board, badges show whether the details are in and whether the contract has been sent.
If a property allows pets (or "on request"), the guest-details page asks whether a dog is coming along. This fills the "Dog" column in the season export.
Linen, (mid-stay) cleaning, pool heating and tourist tax now count correctly in the quote. Per cost you choose via bank account or on site (cash); the quote splits this into "to transfer" and "to pay on site".
Arrival and departure days are now shown diagonally as half days. A changeover day (guest A leaves in the morning, guest B arrives in the afternoon) is instantly visible.
The public booking widget now knows half days too: a departure date remains selectable as an arrival date for the next guest — the standard booking mechanism.
Mark a booking as "shadow": it counts in the calendar, board and reporting, but no e-mails go to the guest. Ideal for loading an existing season schedule in parallel and testing it; untick to take it live.
Bookings from earlier years collapse per lane by year. The contacts list gained a search bar, sortable columns and a "last booking" year.
Per property, an owner signature on the contract: an uploaded image or the name in an elegant script typeface.
Premium properties send guest e-mails from their own domain via SES DKIM verification, with the DKIM records clearly displayed.
An enquiry or offer already holds the dates as an option (soft-book). The iCal calendar feed now shows the property name per item and its own colour per property.
The hidden honeypot field in the booking widget has been put back, so bot enquiries are quietly intercepted again.
From a single villa site to a multi-tenant platform for multiple properties and owners.
Villantis: one calm dashboard to manage bookings, guest communication, properties, agents and commissions — for multiple properties and owners at once, fully on AWS. With the board (swimlanes), the calendar, contacts, property management and template previews.
Alongside fixed weekly prices per season, now also prices per free-form period, optionally per occupancy (number of persons), with a fee-aware quote engine.
An agent proposes a commission per property (percentage × net rent, with minimum and markup); the owner confirms. For ownerless properties the arrangement applies immediately. The commission view shows earned, still to invoice and invoiced.
Agents can create and manage their own (ownerless) properties. Owners and administrators invite agents, reset passwords and manage roles.
A self-service flow on the login page: request a reset code and set a new password.
Per property a booking-widget embed, a public availability feed and a private iCal calendar to subscribe your calendar app to.
The platform is built on the complete booking and e-mail flow first developed and proven for a single villa.
From enquiry to stay, fully status-driven: auto-reply, quote, down-payment, balance, security-deposit and welcome e-mails go out automatically at the right moment.
An automatically generated rental contract (FR binding + NL + EN), tourist tax per person (18+) per night, and a cancellation calculation following the contract scale — now available for every property.