At a resort, accommodation is the simplest part. The problem is the restaurant, the spa, the pool bar and the excursions: every charge ends up on a slip that someone has to link to the right room before check-out. When that is done on paper, disputes arise at departure, and at month end nobody knows what each outlet sold. Zarina CRM keeps an open folio for every stay, where all charges are posted, groups are handled as groups, and availability goes out to booking channels on its own. It is installed on the property’s own server, with a lifetime licence.
The difference from a small hotel is not in these steps, but in how many charges add up between step three and step five.
It comes in from the website, a booking channel, by phone or as part of a group. In every case it lands in the same calendar.
The room is assigned by type and by building or zone, with the day-by-day availability view in front of the front desk.
Arrival is recorded, guest details go into the guest register and the stay’s folio is opened.
Restaurant, spa, bar, excursions, minibar — each charge is posted to the room folio, with the date and the point of sale.
The folio is closed with everything consumed. No more hunting for slips and no more arguments at departure.
It comes from the folio, to the guest or a company, with payment recorded and any balance tracked.
It is the module that makes the difference between a resort and a ten-room guesthouse: at one of them, accommodation is a quarter of the bill.
Accommodation, breakfast, restaurant, spa, bar, excursions, minibar. Each line goes onto the stay’s folio with the date and the outlet it came from.
Part to the guest, part to a company, part to an agency. It is decided at departure, not at booking, and does not require redoing documents.
At month end you see how much the restaurant, spa and bar brought in, based on real folio lines, not estimates.
Groups are why guesthouse software gives way at a resort. Here they have their own module.
At a resort, the rate is not a number. It is a grid by season, room type, length of stay and channel.
Define the periods once, with their rates, and the calendar applies them on its own. No more changing prices by hand at every season change.
Breakfast, half board, full board or packages with services included, each with its own price and contents.
The calendar shows what is free by day and type, with confirmed bookings, pending ones and group blocks shown separately.
A resort sells on several channels at the same time. If availability does not go out on its own, overbooking is a matter of time.
The resort profile sits on top of the complete Hotel edition; it is not a separate, smaller application.
The day’s arrivals, departures and occupied rooms on a single screen, with actions taken from there.
The status of every room, assignment to room attendants and confirmation when the room is ready to sell.
Rooms and apartments with their types, capacities, amenities and photos.
An accommodation property’s local obligations, handled from the data the application already holds.
Occupancy, average rate and revenue by period and channel, on real stay data.
Front desk, housekeeping, restaurant and administration each see what they need, not everything.
The part other vendors leave until after the signature.
These are not hypotheses: they are the reasons large properties come to us.
The guest had drinks at the pool, the slip stayed at the bar, and at check-out nobody found it. It happens several times a week, and nobody knows what it adds up to in a month.
The charge goes onto the room folio at the moment of sale, not at departure.
The room was sold at the front desk and on a channel at the same time, because availability was updated by hand, once a day.
Availability goes out from the same source that consumes it.
The coach operator sent the rooming list the day before, and the 40 bookings were re-entered from scratch, with mistakes.
The group block is already in place; only the names are filled in.
You pay once for the licence. There is no per-room cost, no per-user cost and no monthly fee to keep using the application.
We enter unit types, capacities, buildings or zones and the seasonal rate grid, before the first working day.
We connect the channels you already sell on and check together that availability goes out and comes back correctly.
Separate sessions for the front desk, housekeeping and outlets, because each uses a different part of the application.
Resorts and complexes with several outlets, where the departure bill contains much more than accommodation.
Properties that work with groups, coaches and events, and sell on several channels at the same time.
Properties with a few rooms, where the group module and stay folio would go unused. There the guesthouse profile or the apartments profile fits better.
An accommodation property holds identity data for every guest. The question deserves a short answer.
At a resort, the room booking is only the beginning: restaurant, spa and activity charges add up on the same bill.
Stripe
Rooms are sold through Booking.com, Airbnb and Expedia with a shared calendar, while group bookings and events are managed separately from individual ones. The deposit and final bill are collected through Stripe, communication with the guest before and after the stay is by email or WhatsApp, and invoices are issued with VAT and the applicable per-night fees. The full list is on the connectors and API page.
It is the same Hotel edition. The profile changes the terminology, menu and default settings, and the pages differ in emphasis: at a resort, what matters is the stay folio with many outlets, groups and seasonal rates. We do not sell you a different program and do not pretend otherwise.
Yes, that is the purpose of the stay folio. Each line goes in with date, quantity, price and point of sale, and at check-out the folio is closed with everything consumed.
No. If the restaurant needs its own POS, it stays separate. The application keeps charges on the room folio; connecting to the POS is discussed as an integration and is not in the standard package.
As a group: an umbrella booking with the period, the number of rooms per type and the negotiated terms. Rooms are blocked immediately, and the rooming list is filled in when it arrives, without redoing the booking.
Booking.com, Airbnb and Expedia, plus import and export through iCal calendars for smaller channels. If you sell on a channel not listed here, ask us before the contract.
Yes. The edition includes its own booking engine for your website, with online payment. Bookings from there land in the same calendar.
Yes. The folio can be split at departure: the agency’s share on one invoice, the guest’s on another, with deposits deducted correctly.
The compliance module covers the guest registration card, the guest register and per-night fees such as Tourism Dirham and municipality fee, generated from data already entered. Direct submission to authority systems is not included.
Not in the standard package. Spa charges are posted to the room folio, but booking treatments per therapist and room is not part of the profile; it can be developed separately.
Ask for demo access to the resort profile. You receive an email link that opens exactly this version, with sample data, without installing anything.
The Hotel edition is configured by property type. If you do not run a resort, go straight to your own version.
The complete edition: bookings, front desk, rates, channels and compliance, for a classic hotel.
A small property run by the owner, with fewer outlets and no groups.
Several apartments in different locations, with cleaning and key handover for each.
If you lease long term, not by the night: contracts, rents and due dates.
The 7 Zarina CRM editions and what each contains, on a single page.
The other industries where Zarina CRM has its own edition, outside hospitality.
Lifetime licence, unlimited users, no per-room cost. Ask for a demo of the resort profile and see the application on sample data before any price discussion.