An on-line reservation system:
Part A: Resort availability. A 'live' database that keeps track of every villa at every
DVC resort:
Resorts: (There are currently 8, with more coming)
Villa: Mostly Studio, 1-B/R, 2-B/R, 3-B/R (at selected resorts. VB also has Inn rooms which are different from Studios)
Views: Mostly Standard view at resorts. (BWV has two categories, standard and preferred, and also has Boardwalk View). AKV has four categories for each of the villa types, such as Value, Standarad, Savanna, Concierge. VB has Inn Ocean View or Garden View.
Other: HCA rooms dues to medical reasons. First floor rooms due to medical reasons. Elevator accessible due to medical reasons.
Requests: Near pool, near elevator, near front desk/hospitality house, etc. (Smoking non-smoking is no longer applicable)
Part B: Making a reservation, initial information:
1. Check the member's account, are their dues paid in full? If not, they are not allowed to make a reservation.
2. Check the member's account. Do they have a loan? If they do, is it overdue? If it is, they are not allowed to make a reservation.
3. Check how many memberships the owner has. (This is the blue membership card. Most have only one, but many have multiple memberships)
4. Check the resorts owned and group them by membership numbers and by add-on resorts.
5. Get how many points they own under each resort and under each membership number.
6. Get the number of points they have remaining in their account.
7. Classify all the points remaining into five groups: Regular Points, Banked Points, Borrowed Points, Holding Points, Developer Points
8. Get the reservation request from the owner. EG they want a 2-B/R BWV boardwalk view check-in October 10 for 5 nights.
Make the actual reservation:
1. Is the room available. Yes, then proceed. No, then inform user. (If desired, the system could also develop a wait list with more questions such as day-by-day waitlist or full reservation waitlist, waitlist cancellation date, waitlist notification: Automatic book or call first?)
2. Present the user with all the points eligible to use for this vacation reservation. This means examining all the point possibilities against the reservation itself to see what is allowed. If the reservation is more than 7-months away, then only home resort points are allowed. Special rules apply to Developer points and to Holding points which must also be checked. If it's less than 7-months away, then all points under the same membership numbers 'might' be eligible to use for this reservation.
3. Determine the use year the vacation falls within, and then determine what points the owner has that are within that specific use year. In the case of multiple membership numbers, multiple use years are possible. It's possible the user might be presented with allowable points from two different membership numbers and several add-on's under each membership number, and with points in different use years.
4. The reservation may require 220 points. The user starts by saying use 50 points from membership number "X", Add-on number "A", and must select which of the point categories to use (Banked, Borrowed, Current, Developer, Holding) and determine if those points are eligible to be used for the particular reservation. The system must then not allow any further points be assigned using membership number "Z" since you cannot combine points from two different memberships to make a reservation. The user can then say use 50 points from Add-on contract number "B", again from only the point categories allowed.
5. Currently if someone owns OKW for example and has multiple contracts, MS takes care of using the points from the add-on contracts as required. EG a master contract of 150 points, a 30 point add-on, a 50 point add-on, and a 70 point add-on. (To the member this is the same as a 325 point contract, but internally it is 4 separate contracts, as seen on your annual dues statements) The member wants to make a 220 point reservation. MS will take the 220 points from the above contracts. In an on-line system the user would have to define the contracts. EG say use 100 points of the 150 point contract, use all 30 points from add-on #1, use all 50 points from add-on #2, and use 20 points from add-on #3. (Unfortunately that's only 200 points and the reservation requires 220. The system has to tell the user and require additional points be assigned to this reservation). In other words, the system will require numerous checks and balances. Currently a member can specify to MS which contracts to use when multiple Same-Resort add-on's exist. Normally this is not done and MS does this for you. In an on-line system you would have to do this yourself. (Or make the program even more complex by doing it automatically, or more complex yet, by offering you a choice)
6. If the reservation is less than 7-months away, then also factor in that points can be used from different Add-on contracts at different resorts. Tell the system to use 100 points from OKW contract, Add-on Number 2, use 50 points from BCV contract, Add-on # 5, and use 70 points from AKV contract, Add-on #8!
7. The system needs to check and prompt if it thinks the user is making a mistake. EG someone has both banked and regular points in a use year, and selects to use regular points for a reservation, it would be useful for the system to prompt and ask if they really want to use the banked points instead. Image the outrage if members book on line and didn't use banked points, which subsequently expired.
8. There's more yet, including getting all the other information concerning room occupants names, etc. An additional check here should be added that if someone tried to put in 6 names and is trying to reserve a studio, the system does not allow it. And how to handle other requests?
Compare all the above to a hotel reservation where you can go on line, request a room, give a credit card number, and be done. Simple. DVC reservations are NOT simple.
Even comparing to the IRS system is apples to oranges. IRS code is set for taxes for the PREVIOUS year, and not filed until the following year. Everything is static by that time. Your income for the year is done, your exemptions are done, your itemized deductions are done. In other words there are no changes to the information that will take place between the end of the year (Dec 31st) and when you actually will file (by April 15th). It's a STATIC system and thus programs can be written to incorporate all the rules for this static system. An IRS system is not an on-line system. Even when you use a canned program or an on-line (fill out the form type of program), it is not a 'live' connection to your SS account number. You complete the information and send it in. It is review AFTER that. Preliminary by computers and possibly by auditors. The IRS system is more similar to using the DVC e-mail system to request a reservation where you fill out a form and send it in. It is not a 'live' system.
H&R block can write a tax program and sell it to a million people for $29. That's $29,000,000 in sales. How much are members willing to have their dues go up to have an on-line reservation system. Marriott can afford a relatively 'cheap' on-line system for their hotel chain of I believe Thousands of hotels, and millions of customers. DVC has about 150,000 actual memberships. If 5% of them would use an on-line system, that's only 7,500 members. Do we really want DVC to spent a million dollars (or maybe much more?) for a system that only 7,500 people would use?
DVC is a live DYNAMIC system, not static. Things change all the time. Not pay your dues? That's a change. Bank points? That's a change. Buy another Add-On? That's a change. Make a reservation just 5-minutes ago? That's a change. An on-line system has to cope with ALL of this. It has to be error-proof. It has to have built in all the things a person could do wrong and catch it before letting it process through.
Could a system be developed? Certainly, the technology is there. Would it be expensive? Absolutely! Would it be cost effective? Big unknown. Most likely not, at least for a long time. The system is complex. The key is to make it simple so that people will use it. That's not easy. And if people won't use it, you spent a ton of money for no reason.
Finally, a system like that would not be a 'create it and forget it' situation. DVC is constantly changing. The system would require constant updates. Things like adding new resorts, changing banking rules, etc. All that is not free. Those of you using my preliminary DVC-Tracker program are probably aware of the loop DVC threw me when AKV was announced, with their combination of villas that became available. No longer the simple Studio, 1-B/R, 2-B/R such as at BCV, VWL, or even a 3-B/R available at BWV, OKW, SSR, but had to throw in Value, Regular, Savanna, Concierge!. It's great for members, but adds complexity to computer programs. Imagine a DVC on-line system already set up which has to be modified within a year to accommodate GCV's, and only a few years later to accommodate DVC-Hawaii. Not to mention that CRV's may be in the works.
The initial cost of a program: HIGH
The maintenance and upkeep: Unknown
Program Updates: HIGH
Cost Effective?
Just .02
Caskbill
It is just an approximation. But, it could certainly give everyone a general picture if the room they want is available or not.
It can be hard to come up with technology solution to fix social problems.
