Ride Access Pass and Disabled Access - 2026 Discussion

[Skyscraper]

I don't want to keep going back and forth on a particular point, lest we face the wrath of the mods, but I'm afraid that your incorrect in your assumption.

The system's capacity is managed by the number of RAP holders it can accommodate per day, not the total number of individuals (holders + companions). When an eligible guest pre-books a RAP slot, they consume one slot from the park's daily RAP allocation. The companions they declare are a benefit attached to that single slot; they do not consume additional RAP slots themselves. This is why each RAP holder needs to have their own reservation on their own device. The system doesn't count associated guests as RAP holders, it doesn't consider them for RAP capacity.

Declaring a group size for a RAP slot is no different from declaring a group size for a restaurant reservation. The reservation is for one table (the slot). Whether you bring 2 people or 4, you are still only occupying one table in the system's layout. The restaurant asks how many are coming so they know which table to give you, not because they are charging you for four separate reservations. The system counts the number of RAP instances, not the total number of heads.

If there are 500 RAP reservations available for Saturday:

• Scenario A: I book for myself (1 goose). The remaining count drops to 499.
• Scenario B: I book for myself + 3 companions (4 bodies). The remaining count also drops to 499.

My three companions don't consume three additional units from the daily allocation. They don't speed up the "Sold Out" status for other disabled guests. Whether I come alone or with a full group, I remove exactly one opportunity for another RAP holder to book.

Why declare the group size then? Strictly for Health & Safety and ride loading. It's a data point for the ops team on the day, not a consumption unit for the booking system in advance.

Your claim that a group of four "takes 8 slots" (or even four) is simply incorrect. They take one.

@Bowser is correct I'm afraid, Goose; a RAP user plus three guests will take four slots from the daily cap, so he is right in saying that a group of four with two RAPs would take eight slots (that's because they are two separate bookings). Each person in a RAP group is a counted individually, it's not one slot per RAP booking.

 

[GooseOnTheLoose]

This is categorically wrong and i have tested it because availability will show if i attempt to book RAP+2 but not RAP+3, but guests are allocated a slot in capacity.

Your test doesn't prove your claim.

If the system were simply counting "Total Heads" against a global cap, it wouldn't care about your specific group configuration, it would just look at the remaining total. For your test to work, presuming a hypothetical hard cap of 2,000, the counter would have to be sitting at exactly 1,997 guests at the precise moment you clicked, leaving room for three, but not four.

The odds of you winning the operational lottery, and finding the system with exactly three spaces remaining out of thousands, are incredibly slim.

The fact that you were rejected for a group of 4 (RAP+3) but accepted for a group of 3 (RAP+2) indicates that the system manages allocation buckets, not just raw headcount. Yield management.

Your test only provides an example of the RAP app's front end behaviour, and not the configuration of the booking server.

The logic for capacity management, the algorithm that decides if a slot is open, lives on the API backend, not in the client side app.

The app simply sends a payload: {"ID": X, "GroupSize": Y}. The server processes this against its inventory rules.

You can't see how the deduction is calculated. You can only see the binary result (Success / Fail).

Your "test" simply demonstrates that the server rejected a request with GroupSize: 4. It doesn't prove that the server deducted 4 credits from the master inventory. It only proves that the specific "bucket" for that group size was unavailable.

It's saying: "We have exhausted the allocation for large groups, but we still have capacity for small groups."

This is exactly how a restaurant reservation system works. If you try to book a table for 4 and get rejected, but can book a table for 2, it doesn't mean the restaurant is at "maximum capacity." It means they have run out of 4 top tables but still have 2 tops available.

Most importantly, if the "cap" were a raw count of heads as you suggest, the system would be unlawful.

If Merlin set a hard cap on heads rather than RAP holders, a situation could arise where 100% of the capacity is reached, yet only 25% of the guests are actually disabled (if every holder brought 3 companions).

This would mean the system is prioritising able bodied companions over the disabled guests it is legally required to serve. Under the Equality Act 2010, this would fail the test of a "reasonable adjustment." You can't restrict the access of a disabled person based on the volume of non-disabled guests already in the park. The system must prioritise the RAP Holder (the 25%) as the primary unit of currency. The companions are a secondary operational consideration, not an equal unit of consumption.

You're confusing Inventory Management (the availability of specific group slots) with Aggregate Capacity (the total number of humans allowed in). Your test confirms that Merlin limits the number of large groups to protect throughput, which supports my point: they're managing the "slots" and configuration, not just a raw count of heads.

 

[Dave]

If the problem is that Merlin thinks there are too many customers with RAP passes who would be able to wait in the standard queue lines, and who probably use their ‘time outs’ not to attend to their needs but to go on short-queue rides using the standard queue, would a solution be to bar RAP users (and their party) from any ride (except maybe the ones that move you around the park such as the Skyline etc) for the duration of their time out?
This would obviously mean that everyone would have to scan their ticket to gain access to every ride.

I also think that Merlin could do a better job of educating the average theme park punter as to how RAP operates because I see a bit of animosity towards RAP users by people queuing in the standard long line that see this short, quick-moving RAP queue and assume it’s the same as fastrack but don’t know about the timeouts.

At Efteling last year, my casual observation is that there weren’t many people using their RAP equivalent (although that may be largely because their facility card queues tend to be completely separate to the main queue lines. And no fastrack!).

The issue it’s it’s almost impossible to police stopping RAP guests going into normal queues. You could maybe look to facial recognition tech but that’s both expensive and very controversial.

Just to be clear I actually have no problem with RAP users being allowed to go on any ride with a queue less than 15 minutes whilst waiting in a virtual line (life is hard enough for most people with disabilities that the odd perk in a theme park is fine), my issue is when you see people (regularly) who get in a 90 minute virtual queue for Smiler and then join a 60min physical queue for oblivion.

Your test doesn't prove your claim.

If the system were simply counting "Total Heads" against a global cap, it wouldn't care about your specific group configuration, it would just look at the remaining total. For your test to work, presuming a hypothetical hard cap of 2,000, the counter would have to be sitting at exactly 1,997 guests at the precise moment you clicked, leaving room for three, but not four.

The odds of you winning the operational lottery, and finding the system with exactly three spaces remaining out of thousands, are incredibly slim.

The fact that you were rejected for a group of 4 (RAP+3) but accepted for a group of 3 (RAP+2) indicates that the system manages allocation buckets, not just raw headcount. Yield management.

Your test only provides an example of the RAP app's front end behaviour, and not the configuration of the booking server.

The logic for capacity management, the algorithm that decides if a slot is open, lives on the API backend, not in the client side app.

The app simply sends a payload: {"ID": X, "GroupSize": Y}. The server processes this against its inventory rules.

You can't see how the deduction is calculated. You can only see the binary result (Success / Fail).

Your "test" simply demonstrates that the server rejected a request with GroupSize: 4. It doesn't prove that the server deducted 4 credits from the master inventory. It only proves that the specific "bucket" for that group size was unavailable.

It's saying: "We have exhausted the allocation for large groups, but we still have capacity for small groups."

This is exactly how a restaurant reservation system works. If you try to book a table for 4 and get rejected, but can book a table for 2, it doesn't mean the restaurant is at "maximum capacity." It means they have run out of 4 top tables but still have 2 tops available.

Most importantly, if the "cap" were a raw count of heads as you suggest, the system would be unlawful.

If Merlin set a hard cap on heads rather than RAP holders, a situation could arise where 100% of the capacity is reached, yet only 25% of the guests are actually disabled (if every holder brought 3 companions).

This would mean the system is prioritising able bodied companions over the disabled guests it is legally required to serve. Under the Equality Act 2010, this would fail the test of a "reasonable adjustment." You can't restrict the access of a disabled person based on the volume of non-disabled guests already in the park. The system must prioritise the RAP Holder (the 25%) as the primary unit of currency. The companions are a secondary operational consideration, not an equal unit of consumption.

You're confusing Inventory Management (the availability of specific group slots) with Aggregate Capacity (the total number of humans allowed in). Your test confirms that Merlin limits the number of large groups to protect throughput, which supports my point: they're managing the "slots" and configuration, not just a raw count of heads.

Whether they have a hard single number or an inventory of group sizes per day it doesn’t make much different to the argument that two people with RAP in the same group booking two lots of 4 people for just 4 people is still taking more RAP capacity and allowing two virtual queues to run simultaneously.

 

[shaun3]

The fact that you were rejected for a group of 4 (RAP+3) but accepted for a group of 3 (RAP+2) indicates that the system manages allocation buckets, not just raw headcount. Yield management.

So not at all like how you first asserted that the system deducts 1 from the RAP allocation pool no matter how many are in your party.

If there are 500 RAP reservations available for Saturday:

• Scenario A: I book for myself (1 goose). The remaining count drops to 499.
• Scenario B: I book for myself + 3 companions (4 bodies). The remaining count also drops to 499.

My three companions don't consume three additional units from the daily allocation. They don't speed up the "Sold Out" status for other disabled guests. Whether I come alone or with a full group, I remove exactly one opportunity for another RAP holder to book.

Just admit that you don't know and that you're clearly guessing. At least the other person used logical determination.

 

[Slackjawedyokel]

Just to be clear I actually have no problem with RAP users being allowed to go on any ride with a queue less than 15 minutes whilst waiting in a virtual line (life is hard enough for most people
With disabilities that the odd perk in a theme park is fine), my issue is when you see people (regularly) who get in a 90 minute virtual queue for Smiler and then join a 60min physical queue for oblivion.

The problem though is that Merlin have a higher percentage of RAP users than they perhaps anticipated. Because of the way the RAP application system works, it is difficult to distinguish between people that have genuine need (who we all want to be able to access the rides) and those who probably are able to use the regular queues but who are able to get a RAP and effectively abuse the system because it becomes something similar to a fastpass for themselves and their friends/family.

‘Clamping down’ on RAP application abuse is always going to be very difficult and controversial- doing it properly is probably going to be quite expensive and/or involve a lot of your GP’s time and it’s always going to be difficult finding the correct cutoff point for conditions that are on spectrums and which fluctuate.

The alternative is to alter the RAP system in such a way that discourages people that don’t absolutely need it from applying. The system I proposed puts RAP users into the same boat as non-RAP users as they will be able to get the same number of rides on the main attractions per day. RAP users with genuine need get a short queue time and get to wait in a more relaxing environment than the queue line to be able to get on another ride.

If a proportion of RAP users are abusing the system (and I’ve no idea what proportion of RAP users that might be), then that’s neither fair on regular customers or those that have genuine need, who can’t get availability for parks and/or end up waiting in longer queues.

 

[Benjsh]

Find it very difficult to understand that in a family of 4 people with 1 RAP holder for example.....why there can't be a system implemented that say the Father and Daughter queue for an hour in the regular line and the Mother and Son (Son being the RAP holder) get a notification at the exit queue that it's nearly their time to ride. In 2026 this should be very easy achieved with all the tech and devices that are on the market. Restaurants have been using those incredibly low tech vibrating and beeping small boxes for 2 decades to let you know your table is ready and they work just fine. We've also got apps now that can perform such actions too of course.

This way.....those able to queue do so which creates more fairness, the RAP holder still gets to experience his/her favourite ride without fear of being in a long cattle pen queue and the main queue in theory should move a little bit quicker too. Win win for everyone and the only minor inconvenience is a RAP holder group being temporarily split up for a while. That to me is a small cost to pay for the ability for their vulnerable child / adult being able to wait somewhere calmly and of course they wouldn't be alone at any point either due to the +1 waiting with them with a coffee for example.

Not a perfect system but a million times better than the free for all they currently use.

 

[Dave]

Find it very difficult to understand that in a family of 4 people with 1 RAP holder for example.....why there can't be a system implemented that say the Father and Daughter queue for an hour in the regular line and the Mother and Son (Son being the RAP holder) get a notification at the exit queue that it's nearly their time to ride. In 2026 this should be very easy achieved with all the tech and devices that are on the market. Restaurants have been using those incredibly low tech vibrating and beeping small boxes for 2 decades to let you know your table is ready and they work just fine. We've also got apps now that can perform such actions too of course.

This way.....those able to queue do so which creates more fairness, the RAP holder still gets to experience his/her favourite ride without fear of being in a long cattle pen queue and the main queue in theory should move a little bit quicker too. Win win for everyone and the only minor inconvenience is a RAP holder group being temporarily split up for a while. That to me is a small cost to pay for the ability for their vulnerable child / adult being able to wait somewhere calmly and of course they wouldn't be alone at any point either due to the +1 waiting with them with a coffee for example.

Not a perfect system but a million times better than the free for all they current use.

The argument against this (not saying I agree with it) is that the RAP holder may need their entire party to be with them at all times for their care.

There are instances where this is true (if you have ever had to support an adult with limited mobility in the toilet then you will know it’s not a one man job). It could be an idea for some RAP holders though (maybe the neurodivergent group).

 

[Benjsh]

The argument against this (not saying I agree with it) is that the RAP holder may need their entire party to be with them at all times for their care.

There are instances where this is true (if you have ever had to support an adult with limited mobility in the toilet then you will know it’s not a one man job). It could be an idea for some RAP holders though (maybe the neurodivergent group).

It's a fair point you raise. However the number of people who that applies to each day must be pretty small compared to the overall number with a RAP surely?

 

[Bowser]

It's a fair point you raise. However the number of people who that applies to each day must be pretty small compared to the overall number with a RAP surely?

What if the group is 1 adult and 2 children?

What if it’s 2 adults and 1 child? The adult basically spends the day alone queuing?

What if you’re a group of 2?

Your proposal only really works for groups of 4 that can be comfortably split into 2 for long periods of their visit so it’s a very limited solution.

 

[imanautie]

So not at all like how you first asserted that the system deducts 1 from the RAP allocation pool no matter how many are in your party.

Just admit that you don't know and that you're clearly guessing. At least the other person used logical determination.

Do you remember the old pre-book package where you booked 1 ticket for each guest on your rap on accesso passport for each park?
That's literally what the app does behind the scenes, each guest on your rap is 1 slot. 400 1 person rap bookings is the same capacity depleted as 100 4 person rap bookings.
It actually even shows you the accesso order number in a few parts of the app.

 

[GooseOnTheLoose]

two people with RAP in the same group booking two lots of 4 people for just 4 people is still taking more RAP capacity

There is a distinct nuance here which is being missed.

The terms state: "Please note that the system only allows one pre-book per person, so a family cannot have multiple pre-books for the same guest.". In this context, "guest" implies a non-RAP holding companion. I entirely agree that listing "Companion A" on two separate bookings for the same day is prohibited, I have never argued otherwise.

However, a RAP holder is not merely a "guest"; they are a primary entitlement holder. If RAP User A lists RAP User B as their companion (because RAP User B is present in the group), and RAP User B also holds their own booking (as they are required to do to exercise their own entitlement), the system does not flag this as a "multiple prebook for the same guest". It sees two valid RAP holders exercising their rights.

If the system allows this, and the T&Cs do not explicitly forbid a RAP holder from also acting as a companion to another (which would be a logistical nightmare to enforce for families with multiple disabled children, for example), then it's not "cheating". It is, again, a design flaw.

taking more RAP capacity

I have never argued that companions do not take up park capacity. My argument is that companions shouldn't impact the availability of RAP slots for other disabled users.

If the presence of three able-bodied companions on User A's RAP booking prevents another RAP user from making a booking at all, then the system is fundamentally prioritising the access of User A's able-bodied friends over your statutory right to a reasonable adjustment. That would be unlawful discrimination.

Therefore, the "capacity" being consumed by these large groups is the capacity of the buckets for large groups, not the binary ability for a RAP user to book a slot. If 4 people "take up 8 slots" via the double-booking method, they are exhausting the "Group of 4" inventory. They're not preventing a solo RAP user from booking a "Group of 1" slot (unless the system is built unlawfully).

and allowing two virtual queues to run simultaneously.

If a group contains two RAP holders, they possess two individual, legal entitlements to a reasonable adjustment. If they choose to use those entitlements concurrently to manage the day for their group, that's their right. The fact that they are friends or family does not dissolve their individual rights into a single collective unit. The argument was that this is "cheating", but it's using the system as it was intended and designed.

However, there are instances where this practice shifts from what could be described as "clever and permitted use of entitlements" to a potential breach of policy, though not for the reasons previously discussed. It's not about capacity; it's about safety.

If a RAP user has a Red band classification (requiring them to be accompanied by a carer due to complex evacuation needs), the RAP system acts as more than just a virtual queue; it's a safety log. Scanning registers that a guest with specific evacuation requirements is on the ride.

If a Red band RAP user enters a ride merely as a "companion" (+1) on someone else's booking, and does not scan their own card, the system does not record their presence. In the event of an evacuation, the ride operators might not be alerted via the system that a guest with complex needs is on the train.

Whilst a diligent ride host should be checking at the batching point, regardless of who scanned what, bypassing the digital check in for a Red band user could technically be argued as a breach of Health & Safety policy.

But let’s be clear: that is a safety procedure discussion, not a "stealing capacity" discussion.

So not at all like how you first asserted that the system deducts 1 from the RAP allocation pool no matter how many are in your party.

Just admit that you don't know and that you're clearly guessing. At least the other person used logical determination.

We're all, by definition, reverse engineering a black box system from the outside. However, my assertion remains consistent. One RAP Holder consumes one inventory slot. Yield management systems (like the one Merlin uses) operate on inventory buckets, not a simple linear tally of heads. The fact that a booking for 3 is accepted while a booking for 4 is rejected doesn't prove a raw headcount cap; it proves that the allocation for "Large Groups" is exhausted while "Small Groups" remains open. That is standard software architecture, not a guess. Suggesting that a logical deduction based on how reservation APIs function is less valid than "logical determination" based on a single user interface error message is a strange hill to die on.

To prove the theory that "Guests = Slots," you would need to conduct A/B testing with multiple verified RAP accounts simultaneously. You would need to attempt:

• Booking 4 separate RAP Holder slots (4 x RAP+0)
• vs. Booking 1 RAP Holder slot with 3 guests (1 x RAP+3)
• vs. Booking 1 RAP Holder slot with 2 guests (1 x RAP+2) + Booking another separate 1 RAP Holder slot (1 x RAP+0)
• vs. Booking 2 separate RAP Holder slots with 1 guest each (2 x RAP+1)

You can't do this alone because you don't have access to four separate, valid Nimbus accounts. Changing the dropdown number on a single account does not test the inventory consumption; it only tests the configuration limits for that specific user session.

Do you remember the old pre-book package where you booked 1 ticket for each guest on your rap on accesso passport for each park?
That's literally what the app does behind the scenes, each guest on your rap is 1 slot. 400 1 person rap bookings is the same capacity depleted as 100 4 person rap bookings.
It actually even shows you the accesso order number in a few parts of the app.

Relying on the memory of legacy systems to explain current digital architecture is a dangerous game. The system you recall was designed for total park capacity, not RAP capacity. Crucially, it was also fundamentally flawed.

As some will remember with fond irritation, the old Accesso reservation system for MAP holders didn't link the reservation to your pass in realtime; it generated a brand new, unique ticket barcode. This created a bizarre "Phantom Guest" scenario.

If a MAP holder made a reservation (generating Ticket A) but then scanned their physical Pass (Ticket B) at the turnstile, the system did not reconcile the two. It recorded one person entering via the Pass, while the Reservation remained "booked but un-scanned". One human being had effectively consumed two units of park capacity planning.

If, as you suggest, the new RAP app is merely a "reskinned" frontend for that same legacy rudimentary Accesso backend (treating every single human in a group as an identical, unlinked unit of "capacity") then the system is structurally incapable of prioritising disability access over companion access and would be unlawful.

The presence of an Accesso order number doesn't prove that the system is running the rudimentary "1 ticket = 1 head" logic of the past.

We know the systems have evolved because the "Phantom Guest" scenario I described previously has been eradicated. The new MAP Prebook portal, launched alongside the RAP system, now links reservations directly to the pass barcode. The system is no longer generating dumb, standalone tickets; it is managing entitlements on existing profiles.

The crucial point which dismantles the "it's just a capacity counter" argument though is that a RAP reservation is not a ticket.

You can't walk up to the turnstiles at Alton Towers, scan a RAP reservation barcode, and gain entry. It won't work. A RAP reservation is useless without a separate, valid admission ticket or Annual Pass reservation. This distinction is critical.

If the RAP booking system were simply counting heads for capacity in the way you suggest (like the old admission system), it would be issuing admission rights. It isn't. It is issuing a service entitlement.

Since every companion in a RAP group also requires their own separate admission ticket (which accounts for the park's physical capacity), the RAP booking system is not measuring "how many people can fit in the park". It is measuring "how many people can the RAP infrastructure support".

Logic dictates that the primary unit of measurement in this specific system must be the RAP Holder (the entitlement owner), not the crowd they bring with them. The companions are attributes of the Holder's reservation, not independent reservations themselves.

If the system were treating a group of 4 (1 Holder + 3 Companions) as "4 RAP Slots", it would be duplicating the work of the admission system. It makes far more architectural sense that it counts "1 RAP Allocation" with a metadata tag of "Group Size: 4" for operational loading purposes.

 

[Benjsh]

What if the group is 1 adult and 2 children?

What if it’s 2 adults and 1 child? The adult basically spends the day alone queuing?

What if you’re a group of 2?

Your proposal only really works for groups of 4 that can be comfortably split into 2 for long periods of their visit so it’s a very limited solution.

All fair points again however I don't really see the major issue with an adult queuing alone. Loads of people do it and I have countless times myself. Any decent parent would do it for their child as well. I would for my son in a heartbeat if he wasn't able to queue while he waited with my wife. It wouldnt bother me. Some would enjoy the peace.

A group of 2 also isn't a massive burden on the current system. When you start adding multiple other guests it does get out of hand

Scenario 1 is the only caveat as leaving children alone is a big no no of course. Not sure you can do a great deal in that event.


I think all these valid arguments just go to show what a pain in the backside this all is for Merlin. There's just no pleasing everyone is there? That's the whole point. Guests with or without disabilities are entitled to have an equally good day out. How do you make a system that is fair for all on a busy peak day? It's practically impossible.

 

[Benzin]

Find it very difficult to understand that in a family of 4 people with 1 RAP holder for example.....why there can't be a system implemented that say the Father and Daughter queue for an hour in the regular line and the Mother and Son (Son being the RAP holder) get a notification at the exit queue that it's nearly their time to ride. In 2026 this should be very easy achieved with all the tech and devices that are on the market. Restaurants have been using those incredibly low tech vibrating and beeping small boxes for 2 decades to let you know your table is ready and they work just fine. We've also got apps now that can perform such actions too of course.

This way.....those able to queue do so which creates more fairness, the RAP holder still gets to experience his/her favourite ride without fear of being in a long cattle pen queue and the main queue in theory should move a little bit quicker too. Win win for everyone and the only minor inconvenience is a RAP holder group being temporarily split up for a while. That to me is a small cost to pay for the ability for their vulnerable child / adult being able to wait somewhere calmly and of course they wouldn't be alone at any point either due to the +1 waiting with them with a coffee for example.

Not a perfect system but a million times better than the free for all they current use.

Yeah as mentioned this only works for your particular example. As I'm the designated carer for Mrs I can't go be in a queue for an hour and leave her unattended (I mean I can, but that's not the point).

Not only kids who are using RAP after all.

 

[imanautie]

There is a distinct nuance here which is being missed.

The terms state: "Please note that the system only allows one pre-book per person, so a family cannot have multiple pre-books for the same guest.". In this context, "guest" implies a non-RAP holding companion. I entirely agree that listing "Companion A" on two separate bookings for the same day is prohibited, I have never argued otherwise.

However, a RAP holder is not merely a "guest"; they are a primary entitlement holder. If RAP User A lists RAP User B as their companion (because RAP User B is present in the group), and RAP User B also holds their own booking (as they are required to do to exercise their own entitlement), the system does not flag this as a "multiple prebook for the same guest". It sees two valid RAP holders exercising their rights.

If the system allows this, and the T&Cs do not explicitly forbid a RAP holder from also acting as a companion to another (which would be a logistical nightmare to enforce for families with multiple disabled children, for example), then it's not "cheating". It is, again, a design flaw.

I have never argued that companions do not take up park capacity. My argument is that companions shouldn't impact the availability of RAP slots for other disabled users.

If the presence of three able-bodied companions on User A's RAP booking prevents another RAP user from making a booking at all, then the system is fundamentally prioritising the access of User A's able-bodied friends over your statutory right to a reasonable adjustment. That would be unlawful discrimination.

Therefore, the "capacity" being consumed by these large groups is the capacity of the buckets for large groups, not the binary ability for a RAP user to book a slot. If 4 people "take up 8 slots" via the double-booking method, they are exhausting the "Group of 4" inventory. They're not preventing a solo RAP user from booking a "Group of 1" slot (unless the system is built unlawfully).

If a group contains two RAP holders, they possess two individual, legal entitlements to a reasonable adjustment. If they choose to use those entitlements concurrently to manage the day for their group, that's their right. The fact that they are friends or family does not dissolve their individual rights into a single collective unit. The argument was that this is "cheating", but it's using the system as it was intended and designed.

However, there are instances where this practice shifts from what could be described as "clever and permitted use of entitlements" to a potential breach of policy, though not for the reasons previously discussed. It's not about capacity; it's about safety.

If a RAP user has a Red band classification (requiring them to be accompanied by a carer due to complex evacuation needs), the RAP system acts as more than just a virtual queue; it's a safety log. Scanning registers that a guest with specific evacuation requirements is on the ride.

If a Red band RAP user enters a ride merely as a "companion" (+1) on someone else's booking, and does not scan their own card, the system does not record their presence. In the event of an evacuation, the ride operators might not be alerted via the system that a guest with complex needs is on the train.

Whilst a diligent ride host should be checking at the batching point, regardless of who scanned what, bypassing the digital check in for a Red band user could technically be argued as a breach of Health & Safety policy.

But let’s be clear: that is a safety procedure discussion, not a "stealing capacity" discussion.

We're all, by definition, reverse engineering a black box system from the outside. However, my assertion remains consistent. One RAP Holder consumes one inventory slot. Yield management systems (like the one Merlin uses) operate on inventory buckets, not a simple linear tally of heads. The fact that a booking for 3 is accepted while a booking for 4 is rejected doesn't prove a raw headcount cap; it proves that the allocation for "Large Groups" is exhausted while "Small Groups" remains open. That is standard software architecture, not a guess. Suggesting that a logical deduction based on how reservation APIs function is less valid than "logical determination" based on a single user interface error message is a strange hill to die on.

To prove the theory that "Guests = Slots," you would need to conduct A/B testing with multiple verified RAP accounts simultaneously. You would need to attempt:

• Booking 4 separate RAP Holder slots (4 x RAP+0)
• vs. Booking 1 RAP Holder slot with 3 guests (1 x RAP+3)
• vs. Booking 1 RAP Holder slot with 2 guests (1 x RAP+2) + Booking another separate 1 RAP Holder slot (1 x RAP+0)
• vs. Booking 2 separate RAP Holder slots with 1 guest each (2 x RAP+1)

You can't do this alone because you don't have access to four separate, valid Nimbus accounts. Changing the dropdown number on a single account does not test the inventory consumption; it only tests the configuration limits for that specific user session.

Relying on the memory of legacy systems to explain current digital architecture is a dangerous game. The system you recall was designed for total park capacity, not RAP capacity. Crucially, it was also fundamentally flawed.

As some will remember with fond irritation, the old Accesso reservation system for MAP holders didn't link the reservation to your pass in realtime; it generated a brand new, unique ticket barcode. This created a bizarre "Phantom Guest" scenario.

If a MAP holder made a reservation (generating Ticket A) but then scanned their physical Pass (Ticket B) at the turnstile, the system did not reconcile the two. It recorded one person entering via the Pass, while the Reservation remained "booked but un-scanned". One human being had effectively consumed two units of park capacity planning.

If, as you suggest, the new RAP app is merely a "reskinned" frontend for that same legacy rudimentary Accesso backend (treating every single human in a group as an identical, unlinked unit of "capacity") then the system is structurally incapable of prioritising disability access over companion access and would be unlawful.

The presence of an Accesso order number doesn't prove that the system is running the rudimentary "1 ticket = 1 head" logic of the past.

We know the systems have evolved because the "Phantom Guest" scenario I described previously has been eradicated. The new MAP Prebook portal, launched alongside the RAP system, now links reservations directly to the pass barcode. The system is no longer generating dumb, standalone tickets; it is managing entitlements on existing profiles.

The crucial point which dismantles the "it's just a capacity counter" argument though is that a RAP reservation is not a ticket.

You can't walk up to the turnstiles at Alton Towers, scan a RAP reservation barcode, and gain entry. It won't work. A RAP reservation is useless without a separate, valid admission ticket or Annual Pass reservation. This distinction is critical.

If the RAP booking system were simply counting heads for capacity in the way you suggest (like the old admission system), it would be issuing admission rights. It isn't. It is issuing a service entitlement.

Since every companion in a RAP group also requires their own separate admission ticket (which accounts for the park's physical capacity), the RAP booking system is not measuring "how many people can fit in the park". It is measuring "how many people can the RAP infrastructure support".

Logic dictates that the primary unit of measurement in this specific system must be the RAP Holder (the entitlement owner), not the crowd they bring with them. The companions are attributes of the Holder's reservation, not independent reservations themselves.

If the system were treating a group of 4 (1 Holder + 3 Companions) as "4 RAP Slots", it would be duplicating the work of the admission system. It makes far more architectural sense that it counts "1 RAP Allocation" with a metadata tag of "Group Size: 4" for operational loading purposes.

Even the map pre-book portal uses this method, leaving accesso to track capacity and presenting an optimised front end, it does it's job well.
The rap app is much more then just a front end on it however, as the queue tracking and booking into a ride queue is custom built.

Edit: I've reverse engineered the app, Its 1 guest 1 slot. Merlin even acknowledge this when you ask.

 

[Benjsh]

Yeah as mentioned this only works for your particular example. As I'm the designated carer for Mrs I can't go be in a queue for an hour and leave her unattended (I mean I can, but that's not the point).

Not only kids who are using RAP after all.

Fair enough.

And this is the reason the pass was originally created and why its obviously needed. Nobody can really argue against that. Somebody who needs a FT carer should obviously qualify. That's not even a debate.

The neurodiverse argument isnt as strong though and I dont think when Ride access passes were first introduced parks could envisage just how much cases would spike in society. Its basically caught them out.

They are never going to please everyone.

 

[fearnwood]

What I am not at all clear on now that Merlin have back peddled is exactly what we've gone back to...? My son has a Merlin issued RAP card (which is still dated for another 12 months) as we declined to pay Nimbus £20 for their card. But as of yesterday the serial number on this card was still not being recognised by the Merlin RAP booking app. Are Merlin still only going to accept the Nimbus card for 2026 and just lowered the restriction on the category of card for the time being, or have should the app start accepting my sons card number soon? I also assume that they are still releasing the booking slots in phases as previously communicated or they have abandoned that too for the minute?

Honestly this whole debacle is a shambles!

 

[GooseOnTheLoose]

Just one final thing on the moral panic surrounding "double counting" companions...

A group of three visits the park.

• Guest A (Red Band - requires carer for evacuation)
• Guest B (Red Band - requires carer for evacuation)
• Guest C (The Carer)

Under the park's safety rules, both Guest A and Guest B must be accompanied by a carer aged 14+. Guest C is capable of assisting one person at a time (sitting between them or next to one), or perhaps the ride configuration allows one carer for two people (depending on the specific ride's evacuation procedure).

If "Double Counting is Cheating":

• Guest A books a RAP slot and lists Guest C as their companion. The system registers Guest A is safe to ride.
• Guest B books a RAP slot. They cannot list Guest C, because Guest C is "already counted". So Guest B books a solo slot.

When they arrive at the ride:

• Guest A scans in. The app shows "1 User + 1 Companion". The ride host sees they have a carer. Fine.
• Guest B scans in. The app shows "1 User + 0 Companions".

The ride host now sees a Red Band user attempting to board "alone" according to the system. Even if Guest C is standing right there, the digital audit trail says Guest B is riding unaccompanied, which is a breach of safety protocols. To ride, Guest B must have a companion digitally attached to their reservation to validate their eligibility to board.

If a ride host manually overrides the system to allow a Red Band user to board without a registered companion, they create a false audit trail. In the event of a catastrophic failure or evacuation, the digital log, which is the first thing investigators will pull, will show that the operator knowingly dispatched a train containing an unaccompanied guest with complex evacuation need, which becomes a liability.

Therefore, Guest C must be added to both bookings. They must be "double counted".

If the system (and the moral guardians on this forum) forbids Guest C from being attached to both bookings, then Guest B is operationally barred from riding, despite having a valid carer present.

Continuing with the scenario where Guest C is only attached to Guest A's booking to avoid "cheating the stats".

It's 2pm. Guest A is tired, overwhelmed, or simply doesn't like spinning and decides to sit out Toxicator. They go to get a coffee.
Guest B still wants to ride. Guest C (the Carer) is willing to ride with them.

They approach the turnstile. Guest B scans their app.

• System says: "Guest B - Red Band - 0 Companions."
• System says: "Access Denied. Safety Rule Violation."

Guest A is not there to scan their pass (which "holds" the carer). Guest B cannot borrow Guest A's pass, as that would be fraudulent use of another person's entitlement.

Because they followed the "moral" rule of not double-listing the carer, Guest B is now mechanically prevented from riding, despite having a qualified carer standing next to them. They are digitally shackled to Guest A's movements.

The only way for Guest B to have the autonomy to ride without Guest A is if Guest C is registered on both accounts.

If we insist that "double counting" is inherently dishonest, we are inadvertently arguing for a system which makes it impossible for two high needs disabled people to visit the park with a shared carer. The system requires overlapping bookings to function safely for complex needs.

 

[Skyscraper]

What I am not at all clear on now that Merlin have back peddled is exactly what we've gone back to...? My son has a Merlin issued RAP card (which is still dated for another 12 months) as we declined to pay Nimbus £20 for their card. But as of yesterday the serial number on this card was still not being recognised by the Merlin RAP booking app. Are Merlin still only going to accept the Nimbus card for 2026 and just lowered the restriction on the category of card for the time being, or have should the app start accepting my sons card number soon? I also assume that they are still releasing the booking slots in phases as previously communicated or they have abandoned that too for the minute?

Honestly this whole debacle is a shambles!

The old photo cards are no longer valid, you'll need to reapply I'm afraid. The free Merlin-only option is still available, you get given a code to login to the app.

Merlin - application form

App for Access Card - accesscard.org.uk

app.accesscard.online

I'm in the same position as you, with my card still being in date for another year.

 

[Benjsh]

This topic is getting like a GCSE Maths paper.....

" If Train A was travelling at 70Mph and Train B was travelling at 60mph etc"


This is the a real minefield now but I genuinely believe they'd stumbled onto something a little better with the announced changes. However they were always going to U-turn due to the way society is in 2026. Didn't expect it pre half term but I knew they'd cave in.

 

[AltonLover123]

How do you make a system that is fair for all on a busy peak day? It's practically impossible.

You can’t, which is why we are in this mess in the first place.