Purpose / Use case
Scenarios add an additional layer in our booking engine that allows you to use venues more flexible. A scenario describes an event, a regular service, a campaign or an offer. Different scenario types define the way the scenario is to be used. Multiple scenarios can be in parallel, such as “A la carte” and “Buffet” as an option and they can last across midnight. Scenario replaces parts of the former capacity plans settings.
💡The capacity plans defines the available capacity and resources (tables & table unions). The scenario defines the business rules to apply to that capacity such as duration or limits.
In scenarios, capacities and limits are defined in number of seats. They can be assigned to a venue in similar way as capacity plans. It is possible to pre-reserve a certain amount of capacity to a scenario ( such as 50 seats for inhouse breakfast guests).
Description
- Define scenario types and audiences (API is a new separate audience)
- Set up events and reserve capacity for them
- Parallel & overlapping services
- Simplified capacity calculation (using seats instead of percentage)
- Marketing & Distribution channels - promote scenarios using custom links and target URLs that can be fetched on API.
- Capacity allocation - allocate a certain amount of your capacity to a scenario
- Package your services and offers (usually requires some API services provided by customer)
- Available via REST API
How-to configure
Scenario names and walk-in settings
-
Define name (internal) and display name (shown to guest)
-
Choose installation
-
Check if this scenario should be used for walk-ins (opening a table on POS will then use this scenario to assign walk-ins to. If multiple scenarios have this checked, the system chooses the first one at that specific time)

Guest limits & capacity
-
In Capacity plans you define the overall general limits (seats), which usually is the available seats on that venue. You can adjust those limits per channel:

- Resource handling:
- Matching & autoplace: The system checks for matching tables and assign new bookings to tables. Guest from different bookings will not be placed on same table.
- Matching only: The system checks for matching tables. Guest from different bookings will not be placed on same table. Bookings need to be assigned manually to tables in booking app.
- Simple /None: The system only checks for available seats and does not check for corresponding tables. Guest from different bookings can be assigned to same table. Often used for concerts and events that do not require a fixed table setup.
- Resource handling:
-
In Scenario, the guest limits are defined in amount of seats for this specific scenario only

- if checked “use limit of capacity plan” this scenario can make use of all capacity available in capacity plan.
- if not checked, you can define a different, lower limit. Limit set to “0” will close the scenario for booking, while empty fields will use capacity plan limits.
👉 Example: You have 2 scenarios, a la cart dinner and buffet. You want to have max 50 guests on buffet in a given period of time. Then you will set the Guest limit for “Buffet” to 50.
- Arrival limits define the amount of guests that can arrive at the same time (seats). By default it uses the specified limits for the venue set in the capacity plan, but you can set a different limit for each scenario.
- Allocate capacity is by default turned off. More details to reserve capacity for a scenario you find here below: Capacity allocation
Duration & Audiences
By default the booking app channel is active. If you wan to make the scenario available for other channels, turn on for each available channel.

- Cleaning gap: If set, this will not allow end-to-end bookings and add the specified minutes between bookings. this will reduce the amount of available timeslots. Leave empty, if you do not want to apply any cleaning gap.
- Default duration: This defines the standard seating time for a booking in this scenario and can be set for each channel.
- Minimum duration: This defines the shortest seating time allowed for this scenario. It applies only to booking app, as online guests can not choose duration.
- Maximum duration: This defines the longest seating time allowed for this scenario. It applies only to booking app, as online guests can not choose duration.
- Resolution: Defines the intervals of timeslots available for online booking, e.g. set to 15min it will allow 17.00, 17.15, 17.30….
- Min time upon arrival: Defines the time before a booking starts where guest still are allowed to book. Set to 120min it will allow guest to only book more than 2hrs before the booking starts. Leave empty if no limit should apply.
Marketing

- Scenario description is output in API response and shown in online channels. Keep it short and concise for guests to understand.
- Scenario type defines the usage of the scenario and were . The response is output in API response to be used in marketing engines and defines where the information is used.
- Service: Normal repeating services such as Breakfast, Lunch or Dinner
- Campaign, Offer, Event: Those will be shown in promotion banner in online booking
- Package: Used by API consumers that integrate other services to offer a combined booking experience.
- Inhouse: Usually used for hotels offering services such as breakfast for staying guests. Those will not be shown in online booking.
- URL to scenario Allows to define a target url. API consumers can use this URL to re-direct guests to correct booking flow from a call-to-action button in a newsletter of campaign.
Notifications
All confirmations and reminders are created in Munu Cloud Portal. They can be individual per scenario and make use of email, SMS or both.

Message types: Choose if you want to send confirmation, reminder or both on the selected capacity plan
Channel: Choose if you want to send email, SMS, or both on the selected capacity plan
Reply from guest: Choose if the guest can reply to the email. (SMS it not possible)
Confirmations:
SMS: Fill inn this field with the text you want. Some information be be added dynamically by using tags (see list of available tags below) .

Email: Confirmations and reminders Change/edit the subject of email or the text as you want.
ℹ️ Use the following fields:
#FULL_NAME#
#GUEST_COUNT#
#BOOKED_DATE#
#BOOKED_TIME_FROM#
#BOOKED_TIME_TO#
#STORE_NAME#
#STORE_ADDRESS#
#STORE_CITY#
#STORE_PHONE#
Reminder: Send reminder, X hours prior to arrival.
Waitlist (only SMS supported)
-
Define message for new waitlist confirmation example:
Hei #FULL_NAME#! Du er nå på ventelist. Dato: #BOOKED_DATE# TID: #BOOKED_TIME_FROM# Antall: #GUEST_COUNT# personer. Gi oss beskjed dersom du ikke er interessert lenger.
-
Define SMS confirmation when waitlist is accepted example:
Hei #FULL_NAME#! Du er ikke lenger på venteliste, vi bekrefter din booking. Dato: #BOOKED_DATE# TID: #BOOKED_TIME_FROM# Antall: #GUEST_COUNT# personer. Gi oss beskjed dersom du ikke kan møte opp.
Assign to venue (opening hours)
- Default scenario: A default scenario needs to be set for each venue. The system will use this as fallback, if nothing else is defined. This can be e.g. to add a booking outside defined opening hours for a special occasion.

-
Set availability of a scenario:
- Choose the venue you want to edit in Venue navigation.
- Add rows for available times and assign a scenario to a venue for those time. See example below. If the active period spans over multiple days or weeks, you can decide which weekdays the scenario should be active in “Active weekdays”.

Capacity allocation
It is possible to allocate a certain amount of capacity to a scenario. All other scenarios will then not be able to use this capacity, until the allocation expires.
- You need to define the amount of seats you want to allocate to this scenario. The amount need to be less then the guest limit set on scenario. Values exceeding the guest limit will be ignored.
- In addition you can define the amount of simultaneous arrivals assigned to this scenario only if you want to make sure it is available. If no arrivals allocated, the general arrival limits of the venue are used. This can lead to no available arrivals for this scenario, if used up by others.
- If the allocated capacity is not used, you can define a time when it should expire. The capacity will then be available for other scenarios. Note: This is not a fixed time, its set relative to current date and time.
⚠️Fields left empty means it makes use of set guest limit and arrival limit.
