The calendar

Where it is

The Calendar tab is the first tab on the dashboard and the one MAYA opens on. Everyone on the property can see it, whatever their role.

The controls

Across the top you have Prev and Next, which step one month at a time, and two dropdowns, Month and Year. The years on offer run from the first month that has any booking or any published price to the last one. A property with no bookings or prices yet sees only the year on screen. Prev and Next still move across years.

You can open any month, past or future. What changes far ahead is not the calendar but the prices: your rules run on tonight and the next 395 nights, so nights beyond that show no current price (see "When a night has no current price" below).

On the right, once the month has loaded, a small line reads "Updated 3:05:12 PM · live". The time is your browser's clock, to the second, not the property's. Before the month loads it reads "Loading…". If any part of the month can't be read (its bookings, prices, room types or rooms out of service), the days give way to "Couldn't load this month." with a Try again button, and that line stays empty. A month is never shown with a part missing.

The grid

The month is laid out seven days wide with Sunday in the first column. There is no row of weekday names above the grid. Count from the left with Sunday first, or click a day: the heading of the day detail names the weekday. The colour key sits in a narrow column to the left of the grid, or in one short line above it on a narrower screen (see "What the colours mean" below).

While the month loads, or while you switch property, a grey placeholder of the same shape stands in for the grid.

One day, line by line

Every day is a button. From top to bottom it shows, unless your property has changed it in Settings:

Your property can pick a different big number and up to two different small lines in Settings: occupancy, rooms booked, room revenue, ADR, RevPAR, or the price for a room type you pick. A small line for ADR, RevPAR or a price has that word in front, such as "ADR $182". Rest the mouse on any number and its name shows. Everyone on the property sees the same choice.

On a phone the days are narrow, so each shows its big number and colour bar only. A day too narrow for the whole number shows it shorter: "12/20" for rooms booked, and whole thousands from 10,000, such as "$11k". Tap the day for the rest.

Two details behind those numbers matter when you check them against your property system.

Only room types ticked as rooms, and any still tagged "needs your answer", are counted in the percentage and in "12/20 rooms". A meeting room or a court that you have unticked under Counts as a room is left out of both. Rooms you have entered as out of service come off the sellable count for those nights. The Harbour Inn has 20 rooms across Standard, Deluxe and Suite. With 2 Standard rooms out of service and 11 rooms booked, the card reads "11/18 rooms" and 61%. A room type with every room out of service that night is left out of both, its bookings too, as your rules leave it out. Its own line in the day detail still shows its bookings and revenue, and its revenue still counts in the day's.

The revenue figure sums every room type, including ones that do not count as rooms. Each booked night is valued at the booking's rate as your system reported it on MAYA's latest read, so a booking whose rate you change in your system counts at the new rate once MAYA reads it. If your system reported no rate on that read, the rate MAYA first read for the booking counts.

What that rate includes depends on your system. MAYA never adds tax, never takes off a booking site's commission, and never converts currency. It adds up the nightly rates your system reports:

So the figure will not match a revenue report in your system that adds taxes, fees or extras, or takes off commission. A $0 comp or house-use booking adds nothing and lowers the ADR. Occupancy looks wrong covers the occupancy side.

A booking with no amount at all counts as 0. That happens only when your system has never reported an amount for the booking. The booking still counts as booked, but it adds nothing to the night's revenue or to that room type's Revenue in the day detail, and it lowers that room type's ADR the way a comp booking at 0 does.

What the colours mean

On the left of the calendar a small key names the three colours: "Strong night" (green), "Typical night" (amber) and "Weak night" (red). The ? under it says the colour compares each night's revenue per room with the property's own nights, and that upcoming nights are compared with other upcoming nights. On a narrower screen, such as a phone, the key is one line above the days that reads just "Strong", "Typical" and "Weak".

Your property can reverse the colours in Settings. Then green marks a weak night and red a strong one, and the key says so: "Weak night, keep working on it" beside green, "Typical night" beside amber and "Strong night, leave it" beside red. On a narrower screen it reads just "Weak", "Typical" and "Strong", in the same colours. Amber is a typical night either way, and nights are judged the same way in both. Every property starts with the colours below.

Here is how the colour is set:

• For each night, MAYA adds up the room revenue of the room types ticked as rooms, and any still tagged "needs your answer", the same way the day card counts its revenue: each booking's rate as your system last reported it, or the rate MAYA first read for it when your system reported none on its latest read. A booked room with neither adds nothing.
• It divides that total by the rooms you could sell that night: the rooms in room types ticked as rooms (and any still tagged "needs your answer"), less any rooms out of service. That is the night's revenue per room, its RevPAR.
• Nights before today are compared only with other past nights. Today and later are compared only with other upcoming nights. Revenue for a future night keeps growing as bookings land, so mixing the two would paint every future night red.
• Each group is cut into thirds. A night in the bottom third is red, the middle third is amber, and the top third is green. With reversed colours, the bottom third is green and the top third red.
• A group needs at least 10 nights to be cut into thirds. With fewer, MAYA uses both groups together, and if that is still under 10 nights every night on that side is amber.
• Nights inside a closed period you confirmed on the review are left out when the thirds are worked out, but they still get a colour.

So a night's colour ranks exactly the RevPAR the day shows when your property picks RevPAR in Settings. The revenue figure on the day card can be higher than the total behind the colour, because the card's figure also counts room types that are not rooms, such as a meeting room.

The colour is not occupancy. A night can be 90% full and still red if those rooms sold cheaply against your other nights, and a half-full night with strong rates can be green.

Click a day: the day detail

Clicking a day opens a panel under the grid. The clicked day gets a blue ring.

The heading is the full date, for example "Friday, November 13, 2026". Under it, one summary line:

"12/20 rooms · 60% sellable occupancy · revenue on the books $2,180.00"

For a night before today at your property, the last part reads "revenue $2,180.00" instead of "revenue on the books". It switches at your property's midnight. The amount here is the same figure as on the day card, shown in full.

For a night from today on that a Booked so far vs usual rule that is on covers, a line under it says where the night stands, with a "?" beside it: "12 booked, usually 7 by now". It is the reading that rule was judged on, one line per set of room types such rules measure, named when they are only some: "Standard and Deluxe: 9 booked, usually 5.5 by now". When rules on ahead and behind measure the same room types, both of their numbers show: "12 booked, usually 6.5 to 7 by now". With too few similar nights: "12 booked. Not enough similar nights to compare with yet." It is read again whenever the calendar refreshes. Read Booked so far vs usual.

Then one card per active room type, including types that do not count as rooms. Each card shows:

On a property with room groups (on ThinkReservations, its Room Group column), the cards sit under each group's name, in group order, with a line for the group: "Garden 6/8 rooms · 75% · $1,240.00". That is rooms booked over rooms you can sell in the group's room types that count as rooms, its sellable occupancy, and the revenue of all its room types, counted as the summary line counts it. As on the day card, a room type with every room out of service that night is left out of the rooms, its bookings too, and its revenue still counts. Within a group the cards run in name order, numbers in order, so Garden 2 comes before Garden 10. Room types in no group come last under "Other", with no line of their own. The summary line above is still the whole property, each room counted once. A property without room groups shows one set of cards, as described above.

Amounts on the calendar carry your property's currency sign: $ for US dollars, € for euros, £ for pounds, and the three-letter code in front of the amount for any other currency, such as "CAD 150.00". That is the grid, the summary line, the room type cards, their badges and the price box. It is the same sign the change log's sentences use. The Harbour Inn is in US dollars, so the examples here show $.

The Manual and Changed-in badges

When a manual price is open on a room type for that night, a small amber badge sits beside the room type's name:

• "Manual · $180.00" for a price someone typed in MAYA. Hover it and you see "Set" followed by the date and time it was typed.
• "Changed in Cloudbeds · $180.00" (or "Changed in Think Reservations · ...") for a rate you changed in your property system on a night MAYA had already sent to, while your property keeps such changes as its price (as it starts, in Settings). Hover it and you see "Seen" followed by the date and time MAYA read it. With MAYA's price wins on, no new change gets this badge.

The badge and the manual price help name your system from your connection, which MAYA reads when the dashboard opens. With no connection on file, or for a moment while the dashboard opens, they say "your PMS" instead.

What going live would send

While your property simulates on Cloudbeds or ThinkReservations, with a connection MAYA reads, the calendar shows what going live would change, from tonight on. It starts once MAYA has read your rates for the first time, a few minutes after you connect: until then the day card shows "Current price" as usual and says nothing about a missing rate, since it is MAYA that hasn't read yet. Nothing of this shows once you are live, on Mews, or on the demo property.

The dot. A small amber dot in the top right corner of a day marks a night where MAYA's price for at least one room type differs from what Cloudbeds holds now and would be sent when you go live. Rest the mouse on the day and it says "MAYA's price differs from Cloudbeds and would be sent when you go live". The dot marks the same nights the go-live confirm counts (Going live).

The line above the calendar. Beside Next, after the same amber dot, one line counts the nights from tonight through the next 90: "Going live would change 37 nights in the next 90 days" ("1 night", or "Going live wouldn't change any of the next 90 nights"). Show only these dims every day without a dot, and Show all nights brings them back. The choice is not kept when you leave the page or switch property. Its ? says: "A night counts when MAYA's price for at least one room type differs from Cloudbeds' rate and MAYA would send it when you go live. Your rules, your floors and ceilings, and prices you typed all count. The dot on a day marks the same nights." On a phone the line wraps onto a line of its own. On ThinkReservations with no rate type in use (a tie, or a rate type you picked that is gone), going live would send nothing, so there are no dots and the line reads instead "No rate type is in use in Think Reservations, so going live sends nothing until one is picked on the PMS tab." Read Seeing and picking the rate type.

The day card. On each room type's card, under its room group, the "Current price" line gives way to what MAYA would send, in one of three forms:

• "Cloudbeds $179.00 → MAYA would send $230.46" where MAYA's price differs;
• "Cloudbeds $179.00 · MAYA would send the same" where it doesn't;
• "No rate in Cloudbeds → MAYA would send $200.00" for a price you typed on a night Cloudbeds has no rate for.

The first number is what Cloudbeds holds now: the rate MAYA read, or, where you went live before, the last price MAYA sent, or a rate you changed there that MAYA kept as your price.

Under the line, one chip for each change on MAYA's price, in the order they apply: "Weekend surge +10%", with "×2" when a rule's raises stacked. Click a rule's chip ("See when this rule acted") to open its fire log (The fire log). Then a plain chip when a limit held the price, "Your floor" or "Your ceiling", and "Your price" for a price you typed, or "Changed in Cloudbeds" for a rate you changed there that MAYA kept.

Where MAYA wouldn't send the night, "Current price" stays, and one amber line under it says why:

When a night has no current price

A dash after "Current price" means MAYA has not published a price for that room type on that night. There are four ordinary reasons:

• The night is beyond the window. Your rules run on tonight and the next 395 nights (396 nights, about 13 months). A night further out has no price until it enters the window. A manual price you saved further ahead shows with its badge, and is priced once its night enters the window.
• The night is closed in your system, or has no rate to start from. On Cloudbeds and ThinkReservations, a night whose rate in your system is 0, with no manual price typed in MAYA, is left unpriced on purpose. So is a night your system has no rate for at all, for example one further ahead than you have loaded rates: the card reads "No rate in Cloudbeds for this night yet" under the dash, and the "?" beside it says what to do. A night whose rate was removed in your system after MAYA sent to it reads "Rate removed in Cloudbeds, so MAYA isn't pricing this night" instead, while your property keeps changes made there (A rate removed in your system). Load a rate there and the next hourly read picks it up, or type a price in MAYA. A booking's rate is never a starting point. On Mews, MAYA does not read rates, so a night is priced only once you type a price for it.
• The night has passed and had no price. A night that has passed is not priced again. The card keeps the last price the night had before it passed, or a dash if it had none.
• No run has happened yet. A newly connected property shows dashes until its first pricing run.

The price your rules start from (the base price) is not printed on the day card. Why this price? under a room type's price shows it ("$150.00 → $165.00"), and the change log names it in every change: "from $150.00 to $165.00".

How fresh the calendar is

The calendar updates on its own, within a few seconds of a change to a booking, a published price, a manual price or an out of service block. While the history import is running it refreshes less often, so the page stays calm.

Behind that, while you are on the Calendar tab, MAYA re-reads the month every 5 minutes, and again whenever you come back to the browser tab. While the browser tab is hidden it reads nothing, and the first read when you come back is fresh. After you save or clear a manual price the calendar refreshes at once. A month you opened a moment ago can show from memory when you step back to it. An update never replaces a price you are typing in a day's price box (Setting a price yourself).

The "· live" marker shows whenever the month has loaded.

The days on screen are always the month and property picked at the top. A reading that comes back after you have moved to another month or property is set aside, and a month that can't be read says so rather than leaving the month before in its place.

Time zones

Your rules run in your property's own time zone: "tonight" is today's date there, and that is where the 396-night window starts. The "Updated 3:05:12 PM" time is your browser's clock.

What the calendar does not show