Delay repay prediction idea

[Egg Centric]

Just had a "spark" of an idea which I hereby release to RailUK Tickets (and Trainsplit) only - up to you guys what you do with it (probably nothing) and anyone else can pay me now that I have put this in public writing hehe

Given the state some of the rail network is in at present, it may be interesting to add an "expected delay repay" feature for those of us with a higher risk appetite.

To keep the maths very simple, imagine that an open return between Darlington and London was £100, whilst an advance single was £35.

Suppose that trains could be either on time, or delayed by 3 hours.

And suppose that trains were delayed 50% of the time.

In this scenario, someone with a high risk appetite - or who is doing the journey multiple times - is better off getting the open return. Why? Because they will have to shell out the £100 for the open return 1/4 of the time. The other 3/4 of the time, they pay nothing as they can claim the entire thing back on delay repay, even if only one of the trains is delayed, since the 3 hour delay on either leg is enough to "stuff" the other. The expected price of the ticket is £25.

On the other hand someone getting two advance singles has an expected price of £35. 1/2 the time they will be paying £35 as only one service will have the 3 hour delay. 1/4 of the time they will be paying £0 as both will have the 3 hour delay. And 1/4 of the time they will pay £70 as both services are on time.

I chose these examples to make the maths simple but my actual intended use case isn't really these huge delays - it's more about the concept of producing itineraries with such things as:

• minimal (but legal) connection times
• historically delayed/cancelled services
• busy services that would activate seat guarantees

And so on - so that those of us who are prepared to put up with a bit of inconvenience could save in this way. The primary market is business travellers who are usually allowed to keep delay repay and are also quite likely to be travelling first class, so the sums involved can be reasonable amounts.

 

[yorkie]

Sounds complicated but are three many routes where such huge delays are actually statistically that common?

 

[Egg Centric]

Sounds complicated but are three many routes where such huge delays are actually statistically that common?

Literally huge delays all the time - probably not. But there's undoubtedly times when on certain networks where the TOC is going through a bad patch that 15 minute or more delays are not uncommon and they can of course snowball on a long journey.

Take a look at the current Avanti/TPE issues for instance. I appreciate that technically they are not covered by delay repay but in practice, they're often treated as such.

It may not be a practical feature (from a software engineering perspective it's definitely not easy) but it would also be a very interesting one.

 

[yorkie]

The actual extent of delay may not be in the data feed, for example if a replacement bus is provided. Also how do you know if ticket acceptance is in place or not and whether passengers are advised / able to take alternative routes.

Automating this could only ever be an approximation.

And to get delay repay on both portions of a return, with one leg being delayed, requires a delay of at least 120mins!

I can't remember when I was last delayed that much and it accounts for a miniscule proportion of my journeys.

By all means give it a go, I am sceptical that this would be viable or useful, but feel free to prove me to wrong.

 

[miklcct]

Even with the current dire state, I still rarely encounter any delays which are more than 30 minutes, although I have had SWR paid out 2+ hours after submitting a claim for a lesser amount.

On a line with frequent delays, it's also hard to actually get delayed by 15 minutes because, on a line where trains run every 15 minutes, all trains being delayed by 15 minutes is equal to no trains being delayed from the passenger's perspective. Even when the National Rail app shows my local line being flooded with delays of 20+ minutes, the actual delay I suffer is only in the matter of a few minutes because it's the headway matters rather than the delay of a specific train, and if the departure board shows no train coming I would have rerouted myself anyway.

 

[Egg Centric]

The actual extent of delay may not be in the data feed, for example if a replacement bus is provided. Also how do you know if ticket acceptance is in place or not and whether passengers are advised / able to take alternative routes.

Automating this could only ever be an approximation.

And to get delay repay on both portions of a return, with one leg being delayed, requires a delay of at least 120mins!

I can't remember when I was last delayed that much and it accounts for a miniscule proportion of my journeys.

By all means give it a go, I am sceptical that this would be viable or useful, but feel free to prove me to wrong.

I'm more of an ideas guy

Still, I think you're focussing in on one part of the concept - very long delays - that was just an example of the kind of advantage that you can look to gain. It's the bullet points where things get a bit more interesting. Anticipating a TPE cancellation as part of a London-Edinburgh journey "unnecessarily" changing off LNER at York and rejoining at Newcastle could be an example to trigger LNER delay repay.