Straight answers
The questions that actually decide this
These are the ones that come up in the third conversation, when someone is seriously considering moving a working property onto new software. Most sites save them for a call. Each one here gets the mechanism, in writing, in advance.
You are a new company. What happens to my property's data if you disappear?
You can export all of it at any time, from inside your own account: CSV for guests, reservations and the detailed transaction ledger, plus a full JSON backup of the entire property. The monthly archive keeps a complete accounting package for every closed period, so the months you have already filed on are sitting in your own files rather than only in ours. Data is resident in Canada and backed up daily. None of that depends on us still being here, which is exactly why it is worth stating out loud.
Are we too big for this?
There is no room count that answers that, so the useful test is a different one. The design assumes one desk with one or two people behind it, and a property where the person closing the day is also the person who checked guests in. A larger operation with a revenue team and a night audit desk will find decisions here that were made for someone smaller, the most visible being that there is no night audit at all. The question worth asking is whether everything your staff do on a given morning could sensibly fit on one screen. If it could, the shape of this system is on your side. If it could not, some of it will feel like a constraint, and it is better to find that out in a demo than in month three.
We are mid-season. Switching now sounds like a disaster.
Guests and reservations import from CSV, so the arrivals you have already sold are a data problem rather than a retyping problem. The books are the part that deserves thought. The cleanest switch is at a period boundary, so that one system owns each month completely and nobody has to explain a split month to an accountant later. Mid-season is possible, and the real work in it is the weeks already on the board, not the software.
My accountant will have opinions about this.
They should, and there is a page written for them rather than for you, in the register they actually use. It covers immutable postings, corrections by manager-authorized reversal, tax stored per component, period close and redating, and the four standard exports plus the monthly archive they will receive. Most of the objection underneath this question is really one question: can the books be reconstructed and defended later. That is what the page answers first.
How do I know the numbers are right?
Every charge is re-derived on the server from the stay and your saved tax configuration, then compared against what was submitted. Base plus tax must equal the amount, the components must sum to the tax total, and one bad line rejects the whole batch instead of posting quietly. Any screen that quotes you a number computes it with the same function that applies it, so a confirmation and the charge it turns into cannot disagree. Before any accounting report is read or exported, a completeness sweep compares every reservation, activity and sale against what the ledger holds, and anything it cannot safely resolve is flagged in plain language rather than healed silently. You do not have to take that on faith either. The walkthrough runs on real data, and the arithmetic is visible in it while you watch.
Can I take payments in it?
Two ways, and the card details go to Stripe in both of them rather than to us. Cardinal Payments runs the card and posts the payment straight onto the folio and into the ledger; a hosted payment link does the same thing with the guest paying on their own device. Because nothing card-shaped is stored on our side, there is nothing here to bring into PCI scope. The third path is the one you may already have: a payment taken on your own terminal, in cash, by cheque or by Interac e-transfer is recorded the same way, on the same folio, and carries no percentage from us. Cards run through Cardinal Payments carry a 0.5% platform fee on top of Stripe's own rate, which is the only percentage in the price and it is written on the pricing page.
Do you connect to Booking.com and Expedia?
There is a working connection today, and it is the one this market actually runs on. Each room publishes an iCal feed that Airbnb, VRBO and Booking.com subscribe to, and they stop selling the dates in it. That is how a closure reaches a channel without anyone retyping it. The feed carries the dates a room is unavailable. It sits behind an unguessable token in the URL, and rotating that token invalidates every copy you have handed out. What iCal cannot express is partial availability, because it is one feed per room, so it says booked or free rather than three of six left. The part that is not finished is the certified two-way connection to each individual channel, and that one is blocked on a partner contract rather than on code, which every channel runs on its own schedule rather than ours. Until then Cardinal also reads each channel's own feed every hour and closes the nights it has sold, the guest's details are entered like any other reservation, and the commission model already distinguishes a channel that invoices you monthly from one that charges the guest, keeps its cut and remits you the net. If one specific channel is the thing that decides this for you, name it at the bottom of this page and we will tell you where it actually stands.
Is it actually bilingual?
The half that is finished is the half your guests see. The booking page is fully French, and a francophone guest gets it without touching anything, because the page reads their own browser rather than whatever the last person at the desk selected. You can also put a French link on a French page of your own site. On the operator side, the reservation board for rooms and activities, the Control Deck, Housekeeping and the navigation are French today; the folio, the booking wizards, the settings and the manager reports are being translated now. The two sides follow deliberately opposite rules. Your guests are offered French only once a whole surface is French, so nobody is ever handed a booking page that is half translated. Your staff get the toggle now, and a screen that has not been reached yet shows in English rather than French being withheld from all of it until the last one lands. And the language is stored against the staff member rather than the browser, so on a shared desk nobody inherits the language the last shift chose. If you operate in French every day, ask to see exactly where the staff screens have got to during a demo rather than taking a marketing page's word for it, including this one.
Does it work on a phone?
It is built for the desk, because the desk is where this work happens. It is usable on a phone and the mobile experience is actively improving. The part that is genuinely built mobile-first is the guest booking page, which is the screen your guests actually hold.
We are in the United States. Can we use this?
Everything except the tax and the compliance layer would serve you today, and those two are not a setting. The engine computes GST, QST, PST, HST and the accommodation tax from the province a property is in, rounded per component so the breakdown foots to the cent for an auditor. US sales tax is a different shape rather than a different number: state, county and city layers, thousands of jurisdictions, and home rule states that set their own rules on top. Building that badly would put a US operator's filings at risk, which is the one thing this system exists to keep safe. It is on the roadmap and we are not going to put a date on this page that we cannot hold you to. If you are running a property in the States and this is otherwise the system you want, book a walkthrough and name your state in the message. You will get a straight answer about where it stands.
My staff will make mistakes. What happens then?
Most of the expensive ones are not available to make. A payment taken twice by a double click posts once, because a tender carries one identity and the retry resolves to the same event rather than to a second credit. A room that is closed cannot be booked. An activity with no sessions configured cannot be sold at all. A session cannot be booked past the day the guest leaves. The money mistakes that do happen are corrected in the open rather than tidied away: the ledger refuses an edit or a delete at the database level, so a wrong posting is fixed by a reversal that carries who authorized it, in what role, and why. What that buys you on a Tuesday is that nobody has to spot the error for the books to survive it, and a new person behind the desk cannot quietly cost you a month.
What if I need something you have not built?
Ask, and you will get a straight answer about where it stands rather than a roadmap slide that puts a deliberate omission and an unbuilt feature in the same column. Some absences here are decisions: there is no night audit because the ledger is always current, and that one is written up in full. Where something is genuinely coming, we will tell you when, and you are entitled to hold us to the date.
Every answer here names its mechanism, so the demo confirms the page rather than correcting it.
On that OTA answer
Name the channel and we will tell you where it stands
Two emails: where that connection actually is today, and the day it goes live. The second one arrives when the certification does, which is the only date worth sending you.
Keep going
Where each of these is answered at length
Four answers on this page are qualified rather than clean: OTA connections, the French interface, the phone, and the United States. They are qualified because the answer is. If any of the four is the deciding factor for your property, raise it first in a demo and we will show you the current state directly.
See it running
Watch a day run before you talk to anyone.
Six real screens from a working property, in the order the day happens. Open it now and go at your own pace.