Tarun Muduganti

Long-term stays can provide a sense of security and recurring income to operators. But long-term bookings comes with the risk of leaving gaps in your calendar.
Why do we have booking restrictions on the system?
Imagine a scenario where,
.png)
Let’s assume that this unit is going to be vacant from 31st July onwards.
Lack of restriction in booking leads to a loss of revenue: In this case, if a prospect/lead is allowed to make a booking for 1st September, the operator loses out on the revenue that they could have earned in August and finding a booking exactly from 1st August to 31st August is also challenging.
This can get particularly tricky when the number of units that is being managed increases.
.png)
The assumption in this case is:
Monthly Price for the category Single = $1000
Monthly Price for the category Double = $1800
Monthly Price for the category Studio = $1500
In the above cases, an operator can suffer from loss in revenue if:
Total Revenue Loss - $4300 on average in a span of 4 months.
These losses would start to multiply when the bookings made are far into the future and when the number of units managed increase.
How can we help solve this problem?
Our system allows operators to set booking windows, allowing them to define the timeframe for valid reservations.
Now, with this in place, let’s take a look at what this translates to with the same example as above:
.png)
Let’s assume that this unit is going to be vacant from 31st July onwards.
An operator can configure a booking restriction on our system which will allow bookings up to _______ day(s) from the day prospect opens the booking website.

If the number of days chosen is bookings upto 5 days are allowed, this would mean that when the prospect opens the booking site, the prospect can only check-in 5 days from 31st July (date on which the unit becomes vacant)
Maximum loss in revenue keeping the above examples in mind:
This helps operators control the loss in revenue.
If your teams are stretched by noise, the problem is not intent. It is execution at scale. Let's fix it today.