Form for property rent prices depending on season and length

Question

Seeing the similar post about Form for inputting operating hours of a business, I am hoping you might help me with a similar issue.

We run a holiday property rental website. Properties can be rent on monthly, weekly or daily basis. However some are rented only daily or only daily & weekly or weekly and monthy. Plus there might be a separate price for long term, but this can be disregarded for now.

To make matters worse there is a low/high and peak seasons. And some owners might choose different months to change prices. In the end it looks like this:

http://d.pr/i/Ii4R+

This is pretty heavy so we simply let people enter monthly, weekly and daily price without any deviations, but they make these tables in descriptions anyway so we got to figure out something.

Plus it is a bit unclear at the moment how to store and search through these data, but first things first.

Please share your ideas.

Answer 1

I am not sure about how your system would calculate a price depending upon when I have a date range between an expensive and relatively cheaper time frame. Assuming a system it provides a consolidated rate, I would recommend a layout like this where the user just specifies the date range and gets the rate for the entire period.

^{download bmml source – Wireframes created with Balsamiq Mockups}

However if you are looking at different rates which change as you move from one time period to another ,then you could provide a layout like this :

^{download bmml source}

The advantage of the layout is that the user sees the information which is only relevant to him and is not concerned about other dates. The information is also dynamic and hence will help him make decision about what dates might work best for him.

Answer 2

The main thing on the user's mind might be the price range for the shortest possible period of rent, whether that's per day/week/month.

First determine whether the user is prepared to rent for daily and/or weekly and/or monthly periods.

Example 1:

Let's say the user is thinking of days as the shortest term - ask the user for two numbers:

• the lowest price per day (you equate that to monthly, off peak)
• the highest price per day (you equate that to daily, peak).

Then populate the grid automatically, highlighting the cells corresponding to their lowest and highest price, and you allow the user to nudge the transition points if required.

Example 2:

Now let's say the user is thinking of weekly as the shortest term - ask the user for two numbers:

• the lowest price per week (you equate that to monthly, off peak)
• the highest price per week (you equate that to weekly, peak).

Then populate the grid as before, but this time you hide or disable the daily column.

This way you help the owner start off thinking in the time periods, and price ranges they already have in mind. Then you do the hard work, but let them tweak.

You can then treat the user's definition of low/high/peak as a separate chunk of information.

This is more of an outline than a spec of course, but you get the idea.

But you could add some nice little confidence boosting features like a competitivity rating bar that lets them see whether they are pricing themselves too high or too low.

Answer 3

I liked the suggestion of basically letting the owners choose a time period that they have in mind (day/week/month) and letting them enter the highest and lowest they are willing to accept. Then all you need to do is apply some default formula which they can change (e.g. 10% discount for weekly, 10% discount off-peak season), and then show them the rates for day/week/month. This way you don't have to store a whole bunch of information, but you can calculate values for any given period that they want to see.

It also has the advantage that users will be able to access the information in the same way.