“…it’s too easy for people to affect the ratings of others’ for purely emotional reasons.” JG

solution: pin numbers or the like.

It’s tempting to try to anticipate and solve all the problems in the software, especially because you folks have a lot of experience building web products and businesses. But here you’ve got the relatively luxuries of bricks and mortar, and dedicated, intelligent staff. Don’t fail to take advantage of those!

My intuition tells me that the bigger problems will be stuff you didn’t anticipate :)

I really love the idea of an automated, behavior-based reputation system. I’m always a bit leery of ratings systems that rely on external votes – it’s too easy for people to affect the ratings of others’ for purely emotional reasons.

Straight-forward to implement? I’m pretty sure our development team would beg to differ :) It won’t be in this first release, but this is very much how I’d like to see things work in future releases.

FYI, one of the facts I neglected to mention in the original post is that we started doing the information architecture on Spacer last June. We went through a very mature design process (there will be a post on that real soon now), and only started coding in Jan/Feb, with visual design being the last element. We’re about a week from starting to test it.

We were all a bit nervous about putting all these thoughts out there publicly, but I’m so glad we did. “Fresh eyes” are always a Good Thing.

The Phase II list is growing clearer :)

Thanks to everyone for the good thinking – keep it coming!

The issue you need to figure out is a way to recapture the lost revenue due to reservation hedgers. The best way would be to discourage through disincentive, reward for positive action, and figure out a clever but very simple way to recoup the margin directly from the hedgers

I apologize if this may seem redundant as David posted something similar.

It might be useful, for these corner cases, to include a reputation factor in the mix.

Here is an example of how this might work. If customer X calls at the beginning of each month to reserve a meeting room at 20 different times during the month and by the end of the month has cancelled all but 2, their reputation score would suffer by twenty and increase by two giving him a reputation of -19. You might use a weighted moving average, giving more value to the most recent behaviors. OK… I think I’m having some original thoughts… remember you heard it here first. :)

You could later assign rules for ranges of reputation scores if they become necessary*. You could even, if you deemed appropriate, deliver rulings on a case-by-case basis. This would give you some flexibility.
Best case-scenario, you don’t need to publish the rules under the ’stick’ method because it never arises, and thus saves adding complicated rules to the published set unnecessarily.

Another case, John Smith reserves 5 times in March and cancels all of his spots, or worse -no-shows, but John has been having 5 meetings a month and not canceling for the last six months. In this case John’s previous loyalty has earned him a discount factor for his more recent cancellations, but the more this happens, the more quickly John’s reputation fades. The calculation would likely look more like -5^(recency factor)+36^(recency factor) or something like that. Recency factor would be -days since occurrence.

This should be fairly straight-forward to integrate into a reservation system. Especially if you are building it yourself.

In the meantime, how about allowing up to two meeting room reservations per person, or party, if there are a limited supply available?

*Prepaid reservations by members with good rep scores are given a discount. In the case that person X is new to LaunchPad and cancels his 20 appointments, he might be asked to prepay those reservations in the future. This would help recoup lost revenue due to undesirable reservation hedging and canceling activity and provide a disincentive.

Donell – the line that jumped out at me was how you love dreaming up functionality when you don’t have to write the code :) That said – lots of good points here.

We do want to have a waiting list, especially for meeting rooms. It was on our original list of requirements, but has now been pushed to “phase II”.

The thing with prorating cancellations and basing allowable cancellations on the length of the original reservation is that it makes for a really complicated, hard to explain policy. We’ve worked really hard to come up with pricing and policies that can be explained in a few sentences. This stemmed from visiting some coworking sites with convoluted pricing schemes that left us wondering “so, uh, really then, how much is it?” We don’t want to give people headaches trying to figure out what they’re signing up for :)

Re: “selling off” reservations. Interesting. We haven’t looked at that possibility. I like the idea, although I think we’d be better off some how making the reservation transferable, and letting any “selling” happen outside our system. But that’s definitely a new way for us to think about things, which is awesome.

Thanks for the comments! Every time we fill someone in on this stuff, we get some new, original thinking :)

(There’s a good idea in there somewhere, I swear, it’s just a little bit underdone right now)

and pro-rate the cancellation…if they cancel 9 days out – they are charged for one day, 8 days out – charged for two days, etc.

and in terms of any customer “forgetting” to release dates they were holding – it seems more fair that they are charged and then given it back as a credit they can use at a future date.

another option – since you are building a custom tool – build in the option for people to “sell off” their room cancellations – which will be handy for someone who may complain that they are from out of town or will have no immediate future need to book another room.

and – (oh yea! i love dreaming up functionality when i dont have to write the code!) allow other users to queue up for rooms in the event of a cancellation.

and so maybe allow like a 2 hour window where if someone in the queue takes over a reservation within that time frame – the first person is not charged.

once the two hour window passes and if no one has claimed the time slot – the person is charged and given the credit. and then beyond that – if someone books the new open slot before it expires, the original person who booked the room can then be electronically notified and given the option to receive a refund, or keep the credit for future use.