How truthful are Rail Companies' websites in reporting disruption?

[TheSel]

I ask because of this remarkable co-incidence reported on Northern's website.

Today's 1644 Hadfield to Manchester Piccadilly is cancelled "... due to a fault on a train in front of this one."

Last updated 16:02:41 26/03/2020

16:44 Hadfield to Manchester Piccadilly due 17:23 will be cancelled.
This is due to a fault on a train in front of this one.
​

Fair enough, except that the same page also advises that the 1603 Manchester Piccadilly to Hadfield is cancelled "... due to passengers causing a disturbance earlier in this train's journey."

Last updated 16:01:22 26/03/2020

16:03 Manchester Piccadilly to Hadfield due 16:41 will be cancelled.
This is due to passengers causing a disturbance earlier in this train's journey.​

As far as I know, the 1603 ex Piccadilly forms the 1644 back from Hadfield, so is the truth of the matter that passengers caused a disturbance (on an earlier working of the train that should perform this return working) because their train was delayed due to a fault on another train?

 

[ComUtoR]

Why can't both be true ?

*edit*

RTT is showing that the 1644 to Manc Pic is cancelled due to vandalism.

https://www.realtimetrains.co.uk/train/S21399/2020-03-26

1603 cancelled due to vandalism

https://www.realtimetrains.co.uk/train/S21383/2020-03-26

 

[TheSel]

No reason why they can't - but an amazing co-incidence. Especially when "the train in front of this [the 1644 ex Hadfield] one" is the 1544 ex Hadfield, which RTT suggests struggled into Man Picc just two minutes late despite it's alleged fault.

So, back to the title question - how truthful are rail companies' websites?

 

[ComUtoR]

A lot is due to being an evolving situation. A Driver may report a 'disturbance' and then go and investigate. Once that has been investigated it can be put down to another root cause (vandalism)

There is also a case where each service is treated individually. Your service can be delayed on its inbound journey (due to problem X) and then delayed on its outbound journey due to (problem Y). (where both would be true)

You need to wait for the dust to settle for a more realistic and final decision on what caused the delay.

 

[TheSel]

Fair enough - and makes sense. But in the meantime wouldn't it be more accurate for the Operator's website to say something like "a problem being investigated"?

 

[StephenHunter]

The people who set this up are going based on the limited information they have, which isn't always correct.

 

[ComUtoR]

I have learnt from experience that the delay attribution changes over time. Even after a few days. There is an almost rabid desire for TOCs to be 'open' and 'transparent' at all times. This leads to this exact situation.

If a Driver reports passengers being disruptive but then finds that they have smashed windows, graffiti'ed everywhere, opened fire extinguishers etc. What should the delay be ? Clearly it changed over time. TOCs try to obfuscate delays where possible but get accused of not being transparent or outright lying. Not many on this forum accept excuses like 'due to an operating incident' 'emergency services attending' and or 'problem currently under investigation' You could have (on various websites) 'Delay not yet attributed' and would probably be the most accurate description but I doubt that would please everyone.

Something that happened to me :

Setting up my train and I hear over the Tannoy. 'This service has been cancelled due to no Driver being available' Considering I was sitting in the train ready to go this was clearly not the case.

The TOC wasn't lying per se, just that I didn't have the whole picture and that my relief may or may not have been available.

 

[AGF]

I like it when the automated tannoy says one thing, the human announcer another and the platform screens a third reason... happened at Woking a month or two back!

 

[satters]

anyone with access to the logging systems know sometimes what staff get told can be wrong, and what the passengers get told, often bears little resemblance to the actual cause, a case of messages passing through too many hands that do not understand

 

[Brissle Girl]

The way the question is posed "how truthful" implies that TOC's are deliberately misleading passengers as to reasons for the delay. As the posts above suggest, it's often a moving and sometime complex situation, and I think a much better way to have asked the question would be to ask "how accurate". I can't see why, except in fairly unusual and probably appropriate circumstances, it would be to any advantage to deliberately mislead passengers.

 

[swt_passenger]

Fair enough - and makes sense. But in the meantime wouldn't it be more accurate for the Operator's website to say something like "a problem being investigated"?

When they say that, people will post on here a few days later that they wanted more details...

 

[AGF]

I can't see why, except in fairly unusual and probably appropriate circumstances, it would be to any advantage to deliberately mislead passengers.

From a number of years working for big companies (albeit not train operating companies) I can honestly say we were generally forced to be quite sparing with the truth, especially where the actual issue was one caused internally by an error, fault, negligence or incompetence. So sometimes companies lie to protect image or credibility, especially where said lie makes someone else look at fault. For clarity I’m not saying that’s the case here, just pointing out that companies do often lie.

 

[CC 72100]

When they say that, people will post on here a few days later that they wanted more details...

Absolutely, this forum is awash with desires for precise info on delays. The fact is that when a delay initially takes place, even the internal info to those who need to know can be extremely muddled and a game of chinese whispers. Little surprise then that the external result may later get revised.

 

[AM9]

Surely, the most important information is the impact on the service from that point onwards, not any concept of blame. 'Normal' passengers want to know how their journey is likely to be affected. This subject frequently comes up for discussion, by railway enthusiasts, who understandably like to see how railway things go wrong , and usually have an opinion on how the TOC and NR should rectify the situation. They are however in a small minority in the real world, and most paying passengers are more concerned about their journey's progress. For those who are interested on the final officially issued reason for a delay/cancellation, the records are available for them to chew over forever afterwards. Unless it's a race to be the first to know.

 

[Bald Rick]

The information on train companies websites about delay reasons for individual services is almost certainly automatic, and will be drawn from the TRUST reporting system. The latter is updated by people in control centres, who are using the best info they have at the time. It often changes.

 

[Bow Fell]

The people who set this up are going based on the limited information they have, which isn't always correct.

The people who set this up are sat in the Control so they will be going on all the information possible at the time.

The information on train companies websites about delay reasons for individual services is almost certainly automatic, and will be drawn from the TRUST reporting system. The latter is updated by people in control centres, who are using the best info they have at the time. It often changes.

Not strictly correct, any information fed to JourneyCheck will manually be entered in Tyrell which feeds CIS, and Journey Check.

Sometimes after an event the root cause through the delay attribution system is updated so doesn’t reflect the original reason the train is cancelled.

Another example - a train can be delayed originally by 10 minutes due to a fault, in which the reason in Tyrell will be “Due to a fault on this train” however on its journey it’s forced to terminate “due to a fault with the signalling system” so you cancel the train off in Tyrell with that reason, now with that reason but the initial reason for the delay (train fault) now disappears.

 

[Ladder23]

Ive first hand witnessed a RTT allocation saying cancelled due to a fault with a train, when it was a hissy fit driver not being happy about a change and refused to sign on.

 

[tsr]

The information on train companies websites about delay reasons for individual services is almost certainly automatic, and will be drawn from the TRUST reporting system. The latter is updated by people in control centres, who are using the best info they have at the time. It often changes.

Pretty much everything like that is done manually, though can be done in bulk for large numbers of trains (if the criteria for mass selection of train services aren’t quite right, this can be one reason for spurious info).

TRUST doesn’t always easily match up with Tyrell and CIS reasons (which in and of themselves have their differences).

The people who set this up are sat in the Control so they will be going on all the information possible at the time.

Not always. Very much depends on a number of factors. One which is often overlooked is the question of whether the TOC Control is co-located with the Network Rail Route Control for the area where the delay occurs. For many TOCs, there will be areas of their network where this isn’t the case, which causes a significant lag in transferring frontline info about a lot of situations.

Not strictly correct, any information fed to JourneyCheck will manually be entered in Tyrell which feeds CIS, and Journey Check.

Tyrell isn’t always the best tool for the job (and may be phased out soon, in some areas). A lot of the reasons found on CIS are fed from other software. Unfortunately these other applications don’t always have the most intuitive prompts for the user to check errors.

 

[infobleep]

Fair enough - and makes sense. But in the meantime wouldn't it be more accurate for the Operator's website to say something like "a problem being investigated"?

That is used at times but then you find three hours later that is still the reason listed. They may still be investigating it of course but equally they are busy people and could be focusing on what is happening now.

 

[Metal_gee_man]

My question would be on a train for Key Workers, who the hell was travelling and causing Vandalism on a train when we are in a virtual lockdown and people shouldn't be travelling... Argh... I give up with self entitled idiots who just won't listen and think they are above the rules.

 

[Tom]

Probably worth adding here that there's a new workstream at Network Rail around Passenger Information During Disruption - I had a call about it earlier this week. It's early days but there are certainly a lot of new and fresh eyes on this one. ORR are also paying very close attention.

 

[island]

Fair enough - and makes sense. But in the meantime wouldn't it be more accurate for the Operator's website to say something like "a problem being investigated"?

At that point everyone kicks off on Twitter about “nonsense reasons”.

 

[F Great Eastern]

The way the question is posed "how truthful" implies that TOC's are deliberately misleading passengers as to reasons for the delay. As the posts above suggest, it's often a moving and sometime complex situation, and I think a much better way to have asked the question would be to ask "how accurate". I can't see why, except in fairly unusual and probably appropriate circumstances, it would be to any advantage to deliberately mislead passengers.

These days, companies are more obsessed about PR than they were in the past and therefore they will try and push the blame to everyone but themselves when there are ongoing problems for a decent length of time. Some companies are very open whereas others are more interested in upholding their reputation and protecting their brand rather than giving an accurate message so therefore try and apply spin.

That's why some people will use the transparent journeycheck reason of more trains than usual needing repairs at the same time whereas others who cannot service several diagrams due to a shortage would just simply say it is due to a train fault (the second one is less negative) but use this same line on each diagram that it is reported on. You then have track to train interface issues where operators would rather use 'a fault with the signalling system' rather than 'signalling problems' because the former pushes it more to Network Rail in the eyes of the public even if the problem is the interaction between the train and the track.

Also there has always been the temptation to see if a delay which is caused by something else, if there can be any way for it to be attributed to something outside their control. For example, I've been on several trains which were a fair bit late (+15 mins) due to a fault on the train, the train then gets stuck behind a freight train as it's missed it's path, which delays it further, the delay attribution then gets changed to delayed by a freight train, when the actual root cause was the train fault.

In short, some operators apply spin as much as possible in order to try and deflect blame from themselves. If they can use vague delay attribution reasons instead of specific ones that make them look bad, they'll do so and if they can find something else to blame they'll also do so.

 

[DarloRich]

So, back to the title question - how truthful are rail companies' websites?

It isnt a conspiracy! The information going out, generated by a changing situation, is only as good as the changing information going in? The message often changes as more information comes in. Posters here seem to expect instant identification and rectification timescales.

 

[TheSel]

Probably worth adding here that there's a new workstream at Network Rail around Passenger Information During Disruption - I had a call about it earlier this week. It's early days but there are certainly a lot of new and fresh eyes on this one. ORR are also paying very close attention.

Thank the Lord there isn't a regional one around Passenger Information Serving Southerners!

 

[Bigfoot]

My question would be on a train for Key Workers, who the hell was travelling and causing Vandalism on a train when we are in a virtual lockdown and people shouldn't be travelling... Argh... I give up with self entitled idiots who just won't listen and think they are above the rules.

There is no virus man, it's all about control and the governments, like 5G waves controlling our minds from these new Led street lights, I have put tinfoil on my head to save me, do it soon. Just get out there and spread the word dude...

 

[Horizon22]

Probably worth adding here that there's a new workstream at Network Rail around Passenger Information During Disruption - I had a call about it earlier this week. It's early days but there are certainly a lot of new and fresh eyes on this one. ORR are also paying very close attention.

PIDD has been around for years so what exactly is "new" about it?

As someone who has dealt with delay information & announcements, you go based on the information you have at your disposal which - as others have said - can change. There is now an inordinate amount of delay reasons in the system; which I think is good for the most part but can cause issues. Sometimes the exact incident might not fit into one category nearly / fits into multiple, or different CIS operators code the delay differently. I've certainly had to correct some nonsense from time to time that has been sent down from a novice CIS operative.

Also the more severe and widespread the disruption, the more your CIS teams will become inundated. In this circumstance, it's more likely the delay information will just be carried across from the original incident (if indeed the information is there at all).

 

[Bedpan]

And sometimes we all just innocently misinterpret whatever we are told. For instance, re post 3, the 1544 ex Hadfield would only have been the "train in front" of the 1644 as far as Flowery Field, after which a train from Rose Hill would have been the train in front. (although I haven't been scouring RTT to see if anything else into Piccadilly had been delayed). Or I suppose that a faulty train in a platform at Piccadilly that the 1644 was due to use could loosely be referred to to as a "train in front".

And on to the previous post, I took it that the workstream that Tom was referring to was a project to make improvements to PIDD, which I thought (and forgive me if I am wrong) was a Code of Practice.

 

[SuperNova]

At that point everyone kicks off on Twitter about “nonsense reasons”.

This! When a service is delayed, passengers now demand to know why. Some delays are complicated and don't fit the automatic replies that are created, thus leading to confusing and the accusations about lying - which is a nonsense.

 

[Horizon22]

And on to the previous post, I took it that the workstream that Tom was referring to was a project to make improvements to PIDD, which I thought (and forgive me if I am wrong) was a Code of Practice.

Fair enough then. It could probably use some work but the standard unsolvable problem of PIDD is communication and staffing. You can't run at excess control capacity all the time, and during major incidents you suddenly need 3-4x the amount of people answering phones, delivering the service, updating information systems etc. There is the ability to train contingency office staff, but what if the problem happens at 8pm on a Thursday.