Why is Cross-Country's delay-repay bot badly programmed?

[Nicholas43]

On 15 April I journeyed from Radley to Southampton Central, Radley depart 0804, CrossCountry due to depart Reading 0853 cancelled. CrossCountry's delay-repay bot responded as follows:

Thank you for your correspondence, which we received here on 24/04/2024.

Unfortunately, I am unable to comment on your correspondence as the service is not operated by CrossCountry Trains. Therefore, I have forwarded your correspondence to:

Great Western Railway (DR Only)
FREEPOST
Great Western Railway Customer Support
0345 700 0125
[email protected]

They will respond to you at their earliest convenience. Thank you for getting in touch.

To their credit, GWR's bot said:

Thank you for your delay repay claim which we received on Thu, 25 Apr 2024. We are sorry that you experienced a delay to your journey.

Your claim has been checked using a set process and the details of any delay verified using industry systems holding historic train running information. We have reviewed your claim and can confirm the following:

Travel Date: Mon, 15 Apr 2024
Departing: 08:04 from RADLEY to SOUTHAMPTON CENTRAL
Decision: Unsuccessful

We have checked the journey you have claimed for and our records show that this service was operated by another train operator (Crosscountry). Therefore, we are unable to process your claim.
...
To ensure that your claim is dealt with as efficiently as possible we have forwarded your claim to Crosscountry.

GWR's bot could, of course, explain better: 'the service which caused your delay', not just 'this service'.
Who supplies CrossCountry's unbelievably careless bot, and how can it be so bad?

 

[WesternLancer]

On 15 April I journeyed from Radley to Southampton Central, Radley depart 0804, Cross Country due to depart Reading 0853 cancelled. Cross country's delay-repay bot responded as follows:

To their credit, GWR's bot said:

GWR's bot could, of course, explain better: 'the service which caused your delay', not just 'this service'.
Who supplies Cross Country's unbelievably careless bot, and how can it be so bad?

Depressing. Perhaps done by the same person responsible for XC’s poor quality catering offer?

 

[30907]

Depressing. Perhaps done by the same person responsible for XC’s poor quality catering offer?

It's not just XC. A lot seem programmed to pick up any reference to another TOC.

 

[Horizon22]

It's not just XC. A lot seem programmed to pick up any reference to another TOC.

I'd gather that's what it is. But that's pretty poor functionality.

It should be easy to scan through the relevant operator code and the status of the train impacted.

 

[robbeech]

Claims being passed between TOCs is rife. I’ve never known it happen as much as it does.

I don’t have enough data to compare all the TOCs to eachother in this regard but I have had first hand experience of Cross country doing this exact thing very recently. (A 5 train journey consisting of : EMR(on time), EMR(on time), XC(a little late but not late enough to miss a connection), XC(late causing a missed connection), GWR(next connection cancelled increasing the delay to 2 hours).

There’s no way to put your journey in to most of these delay repay systems, merely the origin and destination and the time of the first departure. As my origin is EMR only at that station the XC system immediately (within minutes of submitting the claim) bounced it to EMR. Many people will not really understand what’s happening at that point so will just wait it out and will likely end up going around in circles until they give up. Whether an operator is government controlled or not the fact remains that this behaviour from them saves millions of pounds of money that rightfully belongs to the people they have already let down.
In my case, EMR have responded saying they need more information, so XC haven’t even sent enough information for them to process.

Of course, a separate contact to a human at XC saw it sorted within 2 or 3 days, so all credit to the humans there, but it’s humans that have programmed their system to pay out as little as possible.

 

[HurdyGurdy]

There’s no way to put your journey in to most of these delay repay systems, merely the origin and destination and the time of the first departure.

Instead of claiming using the website, you could claim using the postal route. XC's form allows for up to 3 legs of a journey to be specified in terms of origin, destination and departure time. It also allows you to specify on which leg the delay occurred, the length of the delay and reason (for it).

I've never had to use it. When XC's bot has bounced my perfectly valid online claim against them to another TOC, that TOC has always bounced it back to XC and it has then been referred to something other than the original bot, so has been accepted and eventually paid.

it’s humans that have programmed their system to pay out as little as possible.

I have also had bots incorrectly calculate the length of delay and award a higher value of compensation than was due. In that circumstance it's just as difficult to engage a human to look into it and correct it.

 

[robbeech]

Which begs the question why is the old manual paper process more detailed than the computerised one.
Some operators will find you a journey or selection of journeys when you enter your origin, destination and start time. You can then either click a journey or input a manual one.
That all said, they still seem to ignore everything you’ve inputted and reject so I’m not sure what to suggest here.

 

[Adam Williams]

Why are we still expecting passengers to claim Delay Repay by filling out an onerous form directly with each TOC, and having this awful, unfriendly UX where you get bounced around from TOC to TOC because nobody wants to take responsibility...when we could simply empower retailers (who in most cases already have all of the journey details and just need to know what actually happened on the day) to pay these claims directly?

 

[HurdyGurdy]

Which begs the question why is the old manual paper process more detailed than the computerised one.

The answer may lay in the fact that the form has not changed since Sept 2019, so predates the "Timetable of the Day" concept, introduced in Feb 2022.

we could simply empower retailers (who in most cases already have all of the journey details and just need to know what actually happened on the day) to pay these claims directly?

Where the ticket is booked train only, the retailer could read across and calculate the delay. Where the retailer is also the TOC responsible for the delay, some already do that calculation and pay compensation automatically. But if I have flexible tickets, the trains I intend to use on the day of travel, and indeed the day of travel itself, may well differ from those I specified to the retailer at the time of booking. Would the retailer be happy to deal with a claim for a delay where the intended journey details had to be specified separately from those supplied at the time of booking?

 

[Haywain]

we could simply empower retailers (who in most cases already have all of the journey details and just need to know what actually happened on the day) to pay these claims directly?

That would also have the potential for complexities because of not claiming from the right retailer because the tickets used have come from multiple retailers. And how would you deal with journeys involving a ticket and a staff pass, for example? What is needed is a central clearing house, rather than dividing up the work in a different way.

 

[robbeech]

Why are we still expecting passengers to claim Delay Repay by filling out an onerous form directly with each TOC, and having this awful, unfriendly UX where you get bounced around from TOC to TOC because nobody wants to take responsibility...when we could simply empower retailers (who in most cases already have all of the journey details and just need to know what actually happened on the day) to pay these claims directly?

I suspect they (rightly or wrongly) see this as more of a risk to their purse.

As an operator responsible for letting a passenger down you have a legal right to compensate them. For long distance high value journeys this may well be several hundred pounds. Knowing that there is no real world regulation and that you can very very easily get away with simply not paying out by using a variety of excuses it will result in a balance significantly higher at the end of the financial year. It’s entirely possible the amount saved by rejecting valid claims (deliberately or through incompetence which when it’s as well known as it is is still deliberately) easily pays the salary of those employed to deal with claims, likely with some spare.

If the retailer in which your ticket was purchased became responsible for attributing delay repay compensation accordingly then you’ve removed control from the operator. By paying out on all claims that are valid you WILL increase the costs to the operator. If you add in an automated delay repay system for things such as advance singles then this will increase costs to the operator even further.

The top and bottom of it is operators are manipulating systems and ignoring their faults in order to minimise payout and will do anything they can to prevent change to that lucrative game.

 

[Adam Williams]

That would also have the potential for complexities because of not claiming from the right retailer because the tickets used have come from multiple retailers. And how would you deal with journeys involving a ticket and a staff pass, for example? What is needed is a central clearing house, rather than dividing up the work in a different way.

I can't remember it in its entirety, but the proposal from the retailers was effectively a central clearing house that had an API, where retailers could electronically submit claims on behalf of customers and pay them out using the original payment method. Exactly what happens afterwards is an implementation detail, really.

I take your point that there's a minority of journeys where folks purchase multiple tickets from different retailers but I don't think the 1% case justifies making it more difficult for the 99% of straightforward cases. Just keep a manual route active for folks to use if they've done something complex.

Ideally we'd get to a point where all retailers would be able to handle planning journeys with passes (treating legs as unticketed where the passenger has a pass that fully covers segments of the journey). Unfortunately the industry data is really lacking in this area, particularly for more niche passes or where validity varies for different employees, so that's always going to be a way off sadly.

 

[HurdyGurdy]

What is needed is a central clearing house, rather than dividing up the work in a different way.

Absolutely. If that could include processing refunds due to disruption where the passenger decided not to travel alongside compensation for disruption where the passenger was delayed, that would be even better. Many passengers imagine the distinction is arbitrary and claim a refund when what they are entitled to is compensation at 100% of the ticket price.

 

[Wallsendmag]

If only there was some central body looking at this sort of thing.

 

[HurdyGurdy]

If only there was some central body looking at this sort of thing.

In your usual cryptic way I presume you are saying there is?

 

[Wallsendmag]

In your usual cryptic way I presume you are saying there is?

Pretty sure there is yes, although not my area of expertise

 

[robbeech]

Pretty sure there is yes, although not my area of expertise

But from a passenger point of view, expecting the railway to do anything that benefits the passenger is pretty stupid.

 

[Haywain]

I don't think the 1% case justifies making it more difficult for the 99% of straightforward cases.

Whilst I agree that simplicity is the desirable outcome, there still needs to be a solution that fits all including the 1%. That may be a slightly different solution, but there needs to be one.

 

[HurdyGurdy]

But from a passenger point of view, expecting the railway to do anything that benefits the passenger is pretty stupid.

In this case it would benefit the train companies who are currently multiplicating effort to each operate, maintain and publicise different systems and processes.

Unless you think the industry is so anti-passenger that they prefer a lose-lose situation to a win-win, and will choose not to even benefit the passenger accidentally?

 

[robbeech]

In this case it would benefit the train companies who are currently multiplicating effort to each operate, maintain and publicise different systems and processes.

Unless you think the industry is so anti-passenger that they prefer a lose-lose situation to a win-win, and will choose not to even benefit the passenger accidentally?

There is no effort whatsoever having an automated system that bounces a claim to another operator. The other operator’s automated system then rejects (or bounces back). Not a jot of human interaction has happen to this point.
IF a passenger makes an appeal then the operator may have to do some manual work but this is no more work than they’d have had to do anyway. There is no question that this is easy for the operator.

The industry isn’t so anti passenger they prefer to lose, they’re so anti change unless it is absolutely clear that they will win. In the case of taking away control of delay repay systems they cannot guarantee it will be an overall win.

 

[Nicholas43]

My request is much simpler. Why has CrossCountry specified (or not specified but carelessly accepted) a bot which does no checking of the legs of my intended journey, but is, apparently, programmed: if first leg was operator O, send claim to operator O.

 

[HurdyGurdy]

Why has CrossCountry specified (or not specified but carelessly accepted) a bot which does no checking of the legs of my intended journey, but is, apparently, programmed: if first leg was operator O, send claim to operator O.

Incompetence, probably. If you had a deliberate and malign intent to reject valid claims, your bot would just inform the claimant (wrongly) that they needed to claim from the other TOC. A significant percentage of valid claims would then die at that point, due to to the ignorance and apathy of claimants. Designing the bot to actually forward the claims to the other TOC means they all stay alive and the majority will bounce straight back.

Though I wouldn't entirely discount the possibility that XC did actually intend to build an efficient reject-o-bot, but failed.

 

[robbeech]

My request is much simpler. Why has CrossCountry specified (or not specified but carelessly accepted) a bot which does no checking of the legs of my intended journey, but is, apparently, programmed: if first leg was operator O, send claim to operator O.

I suspect in reality it has been created by people without an ounce of knowledge on railway ticketing and presented to the railway who is mostly without an ounce of knowledge on railway ticketing. Its flaws may or may not have been directly addressed but I suspect it’s simply not worth changing it as it’s a railway bias. Rest assured, if it was regularly accepting claims it shouldn’t then an unlimited amount of funds would be thrown at it to fix it immediately, with the entire automated process likely being switched off in the meantime (despite this almost certainly costing more to deal with).

If you had a deliberate and malign intent to reject valid claims, your bot would just inform the claimant (wrongly) that they needed to claim from the other TOC.

This wouldn’t pass muster though as the rules state that you CAN send your claim to ANY operator who’s service you caught and they will where necessary forward it to the relevant operator. Whilst they’re not into following rules, this is a pretty easy one to follow so keeps what little regulatory bodies we have out of their hair for a while.

I’d love to see the latest complete documentation on cases and what happens on rejection but I suspect this would make operators look very poor and as such any attempt to avoid letting this information see the light of day will be made.

 

[Fermiboson]

I wonder if the mechanisms behind automated delay repay bots could be subject to FOI, for the appropiate OLR operators.