Tracsis Delay Repay System: Bugs and other UX complaints

I wanted somewhere to rant about this Delay Repay portal, because it's bloody awful and public shaming can occasionally be effective in persuading suppliers to get their act together. I have had no luck complaining to train operators about how bad the portal is.

Broken email links

"Delay Repay Claim Review - Action Required" emails include a journey history link. These include a claimrefno query string parameter - great, it saves the customer re-typing it! Except, the page itself is expecting a base64-encoded "Claim Reference Number" (example) rather than what the email template is using. It still tries to decode it and fill in the textarea nonetheless, leading to binary garbage in the input field.

Customers must waste their time backspacing the data in the field and re-entering it because Tracsis are not capable of generating a link in the format their own system accepts.



There really is no reason for it to be base64 encoded. I suspect it was done because the claim reference numbers include forward slashes, but we fixed this problem decades ago with %-encoding.

Not asking customers for details, and then gaslighting them by complaining that details are missing the next day

This one does my head in. You've spent ten minutes filling in all the details the form asks for, you submit it with the uploaded ticket PDF and then afterwards you get this email back:






All of this data is literally encoded in the barcode/stored in LSM (the Ticket on Departure Live Sales Management System). Why the **** are you wasting my time asking me to provide it? Why the **** didn't you require me to provide them when I first filled out the form...?

A cynic would suggest that this is all just a deliberate strategy to cause customer claims to be abandoned because the whole thing is SO MUCH EFFORT for no reason.

Why are you making me enter the UTN (the Unique Ticket Number)? It's literally in the payload of the barcode in the PDF I just uploaded.


Stop being so bloody lazy and outsourcing data-entry work to the paying passenger. It would be less than half a day of work to extract this from the Aztec payload.

Why is there a 6 ticket limit for Delay Repay claims?



No database index for UTN lookups?

If the customer, quite legitimately, claims for a ticket that was issued on the same day of the claim, the details won't have been written to LENNON, the sales system, yet. This is quite normal.

Why though, does the util.getsalesDataFromSales call sometimes take tens of seconds to return back a response to the user? What on earth is it doing (other than wasting my time) - is it doing a full table scan? This shouldn't take more than 500ms.

---

Is this really the best experience the industry has to offer to customers who have already been inconvenienced? Have some pride in your work.

Adam Williams said:

Broken email links

Click to expand...

Yep, this one has been the case for at least a year - it did used to work, at some point they changed either the email generation or website without changing the other

Adam Williams said:

Not asking customers for details, and then gaslighting them by complaining that details are missing the next day

Click to expand...

I fail to understand how this is still so broken. It's been this ****ed for since the first time I ever used this form, and the way at least one of the bits of messaging blames you the user for the fact they don't ask for the info is infuriating

The bug I'll add is that once my split ticket claim was rejected, and I needed to modify the evidence for ticket 2. It turns out this is impossible because once editing the claim the inputs for all the tickets have the same name and ID in the DOM so they all clash

OscarH said:

The bug I'll add is that once my split ticket claim was rejected, and I needed to modify the evidence for ticket 2. It turns out this is impossible because once editing the claim the inputs for all the tickets have the same name and ID in the DOM so they all clash

Click to expand...

Useless. Did nobody test any of it?


Station location dropdowns do no filtering whatsoever, and do not use IDMS names

Yes, my ticket is issued from Trainline to Penalty Warning /s



Why can I select a ticket vending machine sales NLC (SST=Self Service Ticketing) as the origin on my ticket?



No attempt has been made to look at which NLCs actually have fares defined in the fares data.

All of these capitalised names are because the IDMS stations reference data isn't being used. There are better, properly capitalised names that should be used in passenger-facing contexts.

Three letter CRS code not prioritised

Why is Leamington not at the top?


Fields are required, but not shown with an asterisk like every other required field

Glossary:

NLC: National Location Code (e.g. 1072)
CRS: Computerised Reservation System
CRS code: e.g. COV, LMS, PAD, EUS
IDMS: IPTIS Data Management Service
IPTIS: Integrated Public Transport Information System, Jeppesen's journey planner

== Doublepost prevention - post automatically merged: 8 Jul 2026 ==



Now it is just completely broken!

Adam Williams said:

Now it is just completely broken!

Click to expand...

Did you crash it?

== Doublepost prevention - post automatically merged: 8 Jul 2026 ==

I have a friend who simply claims from Avanti for all his delays regardless of the operator at fault. Then if it is LNWR (who I believe also use this terrible system) the claim is forwarded (hopefully) without him having to interact with their system.

blimmo said:

I had a friend who would simply claim from Avanti for all his delays regardless of the operator at fault. Then if it was LNWR (who I believe also use this terrible system) the claim would be forwarded (hopefully) without him having to interact with their system.

Click to expand...

Hahahahaha, genius.

Adam Williams said:

Station location dropdowns do no filtering whatsoever, and do not use IDMS names

Yes, my ticket is issued from Trainline to Penalty Warning /s

View attachment 207376View attachment 207378

Click to expand...

That's a feature! I always set my nTrain season ticket's from/to stations as From: "NNETWORK ONE DAY" To: "WEST MIDS DAYRGR" - why should I have to set a to/from station on a zonal ticket? (WMR use the same website system)

When I've submitted Subject Access Requests around failed claims, or claims going round in circles and passed between multiple operators - it turns out that a company called iBlocks mostly underpins all of these systems, a part of Tracsis. However, another Tracsis company - Travel Compensation Services or something like that were involved in a much earlier SAR - but it looks like they've started to wind down that business and gradually trying to move train operators over to the iBlocks system - which is slightly better than the previous one at Transport for Wales, although it's still poor overall. It did make me wonder though - are the systems bad because the train operators are asking for bad/poor features or rules (perhaps with good intentions) which Tracsis is just implementing blindly as a software company, probably without any real deep industry SMEs, or are the systems just the best that is available on the market and TOCs have no choice? If you take Transport for Wales, they went from one Tracsis system to another Tracsis system - so the TOC cannot think that they are particularly bad.

I imagine having industry claims in essentially one place is good for data matching and fraud analysis - but no idea how this system looks underneath. Separate databases? One big database with filters depending on the TOC, specially negotiated sharing agreements etc...

tutacre said:

it turns out that a company called iBlocks mostly underpins all of these systems, a part of Tracsis. However, another Tracsis company - Travel Compensation Services or something like that were involved in a much earlier SAR

Click to expand...

I wouldn't read much into this - Tracsis went through a restructuring a little while ago and just merged some of its group companies together. Much of the software services now sits in iBlocks.

This looks extremely familiar, I'm assuming LNR uses the same system. It used to repeatedly pop up the same message about season ticket holders.

I was wondering if the system did any of the automated decision making on when to pay out, or if this happened elsewhere in the TOC. I've generally found that if I try to claim for anything other than a straightforward delay or cancellation, it gets rejected and I have to appeal. e.g. if the train I was intending to catch had my stop removed at short notice, or was short-formed and too full to board.

moogal said:

I've generally found that if I try to claim for anything other than a straightforward delay or cancellation, it gets rejected and I have to appeal

Click to expand...

Of course, the customer friendly thing to do would be to either do that check during the claim submission flow (no reason why that couldn't be done), or require human review at the TOC's side - rather than make the customer jump through hoops to go back into the claim three times to get it paid out.

tutacre said:

When I've submitted Subject Access Requests around failed claims, or claims going round in circles and passed between multiple operators - it turns out that a company called iBlocks mostly underpins all of these systems, a part of Tracsis. However, another Tracsis company - Travel Compensation Services or something like that were involved in a much earlier SAR - but it looks like they've started to wind down that business and gradually trying to move train operators over to the iBlocks system - which is slightly better than the previous one at Transport for Wales, although it's still poor overall. It did make me wonder though - are the systems bad because the train operators are asking for bad/poor features or rules (perhaps with good intentions) which Tracsis is just implementing blindly as a software company, probably without any real deep industry SMEs, or are the systems just the best that is available on the market and TOCs have no choice? If you take Transport for Wales, they went from one Tracsis system to another Tracsis system - so the TOC cannot think that they are particularly bad.

I imagine having industry claims in essentially one place is good for data matching and fraud analysis - but no idea how this system looks underneath. Separate databases? One big database with filters depending on the TOC, specially negotiated sharing agreements etc...

Click to expand...

I understand that Tracsis provide quite a wide range of services - it may be that if some of them are very useful then it’s easiest (and cheapest?) to buy in bulk, taking some of the less good products along with the good ones? After all, companies can be easily seduced by an offer of a ‘do-it-all’ package, even if the reality turns out to be a bit patchier than they hoped.

moogal said:

This looks extremely familiar, I'm assuming LNR uses the same system

Click to expand...

They do indeed, all the ex-Abellio use it as well as Chiltern, possibly some others too

Tracsis used to scrape the BR Fares API (without paying) to validate prices on claims but they didn't notice that their API call was just getting error responses for 2 1/2 years, after I moved the API away to run on a separate server in mid-2023. I would speculate that they sold their service to TOCs on the basis that they validated that the prices in claims matched up with the fares database, but that may not have actually been happening for several years. When I was dealing with them I got the impression their developers are mostly in India now with only product management staff in the UK.

My experience is that the form field labels, which they insist on including inside the fields instead of alongside them, block you from focussing the field to start typing.

So if I click into the field to type, I have to click (or tap) inside the field but not in the obvious place (on the left, where the words Email Address are) otherwise I'm actually clicking the label and typing will do nothing.

Paul Kelly said:

Tracsis used to scrape the BR Fares API (without paying) to validate prices on claims but they didn't notice that their API call was just getting error responses for 2 1/2 years, after I moved the API away to run on a separate server in mid-2023. I would speculate that they sold their service to TOCs on the basis that they validated that the prices in claims matched up with the fares database, but that may not have actually been happening for several years. When I was dealing with them I got the impression their developers are mostly in India now with only product management staff in the UK.

Click to expand...

I hope you managed to get a back-payment for the unlicensed use of your data

Unfortunately not; they went silent on me a few months ago. They had been scraping the data since at least 2019.

lyesbkz said:

My experience is that the form field labels, which they insist on including inside the fields instead of alongside them, block you from focussing the field to start typing.

Click to expand...

So the root cause of this is that they haven't bothered associating the <label> elements with the input field that they are supposed to accompany. If they did <label class="form-label" for="emailadd">Email Address</label> instead (a 14 character fix for that one!) then it would all just work. Currently when you click the label the browser has no idea which input it's supposed to focus. Almost all of their fields are broken in this way, which will also adversely affect the experience for visually impaired users who make use of a screen reader, as it won't be able to read out a description for the fields.

Do let me know where to send the consultancy invoice, Tracsis...

Paul Kelly said:

When I was dealing with them I got the impression their developers are mostly in India now with only product management staff in the UK.

Click to expand...

Explains a lot, to be honest. I imagine it would've been off-shored for cost reasons as well, which probably tells you a bit about the quality of work.

It is very poor they've been scraping the API in this way for so long. I am sure train operators would've had no idea they were making use of unlicensed data; I think you've shown remarkable restraint in not calling them out for it publicly sooner.

lyesbkz said:

My experience is that the form field labels, which they insist on including inside the fields instead of alongside them, block you from focussing the field to start typing.

Click to expand...

Oh I forgot this, it does my head in every time

I'm thankful that my local TOCs haven't used the Tracsis form so it's not something I have to suffer often (especially given the frequency of delays on GTR)

Relatively minor but it appears Chiltern may have ceded management of Solihull

Maybe West Mids can take it over..?

Adam Williams said:

Maybe West Mids can take it over..?

Click to expand...

Don’t be silly, that would make too much sense

blimmo said:

I have a friend who simply claims from Avanti for all his delays regardless of the operator at fault. Then if it is LNWR (who I believe also use this terrible system) the claim is forwarded (hopefully) without him having to interact with their system.

Click to expand...

I can understand why they'd do that, but it seems a shame that, effectively, a company is penalised for having a better delay repay system.

Today, since it's seemingly "lost" my EMR Delay Repay account, Tracsis asked me to pick my address from a dropdown (which isn't appearing) or enter it manually (which isn't an option on the form?).



I'm pretty sure this is just my very poor internet connection, but it's still a very poor UX.

But don't worry, when I actually press register after waiting 2 mins for the dropdown to appear, it then redirects me back to the register form, wiping all my inputs, with &status=Unauthorized Access in the URL. Thanks Tracsis!



== Doublepost prevention - post automatically merged: 9 Jul 2026 ==

Another one. You can select "Other" ticket type but the only format option is "Please select"...



I guess I'll put my Seatfrog as a Single.

Complaint this evening: you can't appeal an "Already appealed" claim.



All well and good, except the train was short-formed and physically couldn't be boarded (explained in the first appeal already). Presumably someone has just looked at the running times in Darwin and clicked the big reject button.

You'd think asking about overcrowding would make sense in the initial claim details to avoid this pointless back-and-forth.

Someone appears to have made a spoof promotional video for Tracsis, which they have actually published at the bottom of their homepage:


A selection of amusing ironic claims from the video is provided below:

"our vision is to lead the future of sustainable, intelligent transport"

Click to expand...

"our technology... delivered by people who understand what's at stake

Click to expand...

"we don't just build best practice, we build trust"

Click to expand...

Clearly, whoever came up with this wording is an absolute expert in deadpan humour; I can't believe they actually published it, as if it was true, when it is word-for-word the absolute opposite of the reality.

yorkie said:

Someone appears to have made a spoof promotional video for Tracsis, which they have actually published at the bottom of their homepage:

Tracsis - Making Transport Work

Tracsis is a global leader in transport technology, helping to create safer, more reliable, and more efficient journeys.

tracsis.com

A selection of amusing ironic claims from the video is provided below:



Clearly, whoever came up with this wording is an absolute expert in deadpan humour; I can't believe they actually published it, as if it was true, when it is word-for-word the absolute opposite of the reality.

Click to expand...

Could it be something AI has spat out? Surprised that they need something so fake - you would think they would really lean into their actual staff and services - surely no real world customer was ever actually meant to see that?

I'm currently attempting to navigate LNR's frankly byzantine website for claiming delay repay after a complete disasterclass from them last weekend.

After a week, I can quite safely say that LNR's delay repay is borderline non-functional.


Leads to

Leads to

So, how in god's name do you claim delay repay if you have a normal ticket, e.g. an Off Peak Single? Is it a case of having to fill it out by paper?

You'd almost get the feeling that LNR makes it as difficult as possible to navigate their system, to dissuade people getting their rightful compensation...

In my experience, having a delay repay account with LNR works only for season tickets. For other tickets it's not "borderline non-functional" but fully non-functional.

You need to claim without logging in to your account. Even then, the interface does qualify for your description of borderline non-functional.

The idea of registering a DR account for one TOC and claiming everything there is fine, otherwise you'd need an account / password etc... with every TOC that ever caused you to be late.

But the handover process never hands over enough detail to the responsible TOC to actually raise a claim and results in a request for information which is basically starting again as an empty claim.