Search

[Schorse]

@RedFoxy
I was about to write the exact same idea now.

[RedFoxy]

ok but there are only few way to solve troubles and the way of the "no responsibility" isn't the one trouble less, it can be if you have a lot of money :|

[Futeko]

If I understand properly, the idea behind the change in the booking system was to reduce the strain on the Estrel Staff (and sadly it had the opposite effect).

Instead, to even out the stress on the system and to reduce frustration for all parties involved, how about adopting a system similar to how big planes are boarded?
The way it happens, is that seating opens up by row ranges - e.g. passengers with seat rows 70-99, then 50-99, then 30-99, etc. - as a way to control the boarding flow.

Applied to hotel booking, the basic idea would be:
1) Registration opens on day X
2) On day X+7, hotel booking opens for registrars with ID 1-400
3) On day X+14, hotel booking opens for registrars with ID 1-800
4) On day X+21, hotel booking opens for registrars with ID 1-1200
etc.

That way:
1) The registration system itself acts as a "queuing system" by re-using your registration ID as your hotel booking ticket number;
2) The stress is evened-out in a way that is known in advance both for registrars and the Estrel Staff;
3) It requires pre-planning (do we open up for 400 registrars at a time, or more, or less? Do we leave 7 days between openings, or more, or less?), but once that is done, it requires minimal efforts to maintain once running - just cross-checking the registration ID with (1) the planning (is booking open for that ID range?) and (2) the registration details (to avoid people saying "I have ID 244, book me a room" whereas they actually have ID 2440).

[Cairyn]

Instead, to even out the stress on the system and to reduce frustration for all parties involved, how about adopting a system similar to how big planes are boarded?
The way it happens, is that seating opens up by row ranges - e.g. passengers with seat rows 70-99, then 50-99, then 30-99, etc. - as a way to control the boarding flow.

Except that there are sufficient seats for all passengers, while there are not as many rooms as attendees.

Your system would just ensure that the first batches of numbers all get a room, and the last won't get anything.

[Futeko]

Except that there are sufficient seats for all passengers, while there are not as many rooms as attendees.
Your system would just ensure that the first batches of numbers all get a room, and the last won't get anything.

The problem you're describing is that there are aren't enough rooms for all the attendees who would like a room.
This is already happening today - it's not a new problem the proposed idea will introduce.
This is a problem no booking system will solve, and it is not the problem the new EF23 system nor the proposed idea are trying to solve.

Essentially, we have to accept that the "not enough rooms" problem is out of our hands. We need to wait for the Estrel to build additional rooms, and that will take time.
We will face that problem every year, we faced it this year as well albeit in a much more frustrating way (as evidenced by all the comments in this thread and the others).

What we can do, is make that process the least frustrating possible - and that can only happen with a clear, transparent, known-in-advance process.
This is what the proposed idea is trying to achieve.

As mentioned in this thread, people are (1) frustrated about not getting a room, and (2) frustrated about having spent 6 hours of their lives struggling with server errors to come back empty handed.
We cannot do anything for (1). We can however act on (2). This is what this suggestion is about.

[Hai λ]

Discussing possible other workflows for the Estrel booking here is really moot. The EF is not the Estrel, and as I've pointed out before, there is no work force available to take that back into EF hands as it was years ago.

Behind the scenes, people from all involved parties are now scurrying to analyze what happened today and strengthen the systems for next year, but that is all that can realistically be done regarding this hotel at the moment.

[zuzu]

Discussing possible other workflows for the Estrel booking here is really moot. The EF is not the Estrel, and as I've pointed out before, there is no work force available to take that back into EF hands as it was years ago.

Behind the scenes, people from all involved parties are now scurrying to analyze what happened today and strengthen the systems for next year, but that is all that can realistically be done regarding this hotel at the moment.

And please do free up the duplicated reservations somehow.... So make it available to the others waiting gor rooms....

[sneeuwvos]

If I understand properly, the idea behind the change in the booking system was to reduce the strain on the Estrel Staff (and sadly it had the opposite effect).

Instead, to even out the stress on the system and to reduce frustration for all parties involved, how about adopting a system similar to how big planes are boarded?
The way it happens, is that seating opens up by row ranges - e.g. passengers with seat rows 70-99, then 50-99, then 30-99, etc. - as a way to control the boarding flow.

Applied to hotel booking, the basic idea would be:
1) Registration opens on day X
2) On day X+7, hotel booking opens for registrars with ID 1-400
3) On day X+14, hotel booking opens for registrars with ID 1-800
4) On day X+21, hotel booking opens for registrars with ID 1-1200
etc.

That way:
1) The registration system itself acts as a "queuing system" by re-using your registration ID as your hotel booking ticket number;
2) The stress is evened-out in a way that is known in advance both for registrars and the Estrel Staff;
3) It requires pre-planning (do we open up for 400 registrars at a time, or more, or less? Do we leave 7 days between openings, or more, or less?), but once that is done, it requires minimal efforts to maintain once running - just cross-checking the registration ID with (1) the planning (is booking open for that ID range?) and (2) the registration details (to avoid people saying "I have ID 244, book me a room" whereas they actually have ID 2440).

You are right, but I still think it isn't very friendly to open a booking system at an unexpected time. So you have to quote date+time tables for each EF number frame. Like 0-100 at [date] and [time]. As you see that might become a hassle. Neither its fair if you live in the US and you have to do a registration at 4:00AM....

The hotel will sell out anyway, with or without crappy system.

[Vector]

With the previous booking system (on the SAME server/website) workload was spread along the night and the day after so as soon as you got the link (when EF staff manually processed your REG) you could log into booking system and get your room without any problem.

Now, it's 2000-3000 persons booking at the same time, so if you don't have a good internet and a lot of chance (or you use a secret link) you have basically very very few chances to get your room, even if you regged to EF (and tried to book the room) during the first minutes.

[Diavoletto76]

Hello and good evening.
First of all, excuse me for my bad english,I'm not used to write a lot in English so, forgive my several grammatical errors.
I don't want to say anything or even want make controversy.
I was one of the lucky ones to be able to take a room for me and 2 other furries.
With the problem that occurred today some people managed, thanks to a link that has circulated "secretly" as long as needed just to get the room without any problems.
I know for sure, however, that there are people that with this trick took more than one room.

[Hai λ]

Regarding a "secret" link: From what I saw, there were a few different links in circulation, and all of them worked better or worse every now and then, accessing the same hopelessly overloaded back-end.

[RedFoxy]

Btw we can have all ideas that we can, but, the real trouble was from ihotelier, the booking engine system that understimate, or it's too small to support a load like yesterday, than the wy faster to fix it is to use a more stronge booking engine or to tell at ihotelier to use more resource for us when we need to book.

I noticed that ihotelier and other ihotelier's hotel wasn't slow or with our load, when I noticed that I tried something, like to create a new link using only Estrel hotel id, it worked and it was really fast, than I tried to add the Eurofurence discount code and it goes, still fast, than the trouble was maded by ihotelier that separate EF booking engine to different servers/resource and doesn't add more resouce when they seen that there are not enought.

My ideas (coupon code) or other ideas like different time to book based on registration id are good ideas but using a good and strong booking engine can solve our booking troubles without giving more responsability to EF staff, but there is only a trouble about that, a strong booking engine is more expansive.

[Sam T. Housecat]

I suggested this alternative solution in another thread:

Divide con guests in batches. Not random batches, but batches according to reasonable criteria:

- Batch 1: people with conditions and disabilities, for example: wheelchair, bad eye sight, need for special rooms, etc.
- Batch 2: fursuiters! Generally only 25% of all furs is a fursuiter. However, they have to carry quite a load around, which is unpractical if you have to move through a city for a number of kilometers.
- Batch 3: regular guests. For people who are physically and mentally fit and have not much to carry, moving half an hour to and from the con site by public transportation is doable.

These are just some criteria that come to my mind. I suggest we have an open discussion about it so the guests can have their say and they eventually can support a reasonable final solution.

This doesn't require much reprogramming. Having three con booking codes instead of one won't be hard to achieve.

[Suicune]

I hope the special conditions/fursuiter/regular separation comes with the Estrel Tower. (If the main con part stays on the side of the hotel where it is now.)

[MartinRJ]

I suggested this alternative solution in another thread:

Divide con guests in batches. Not random batches, but batches according to reasonable criteria:

There is no way how someone can "prove" that they are fursuiters. It would be too easy to cheat, which would create a tremendous amount of drama.
While it looks like a good idea at first sight, it's not feasible in practice.