This week I had one of those train days that should be simple.

It started early, before sunrise. I parked at the station car park, bought my ticket in the railway app while walking, and hurried to the platform. Everything felt smooth, modern, and exactly what multimodal travel is supposed to be.

Fast forward to late in the evening. I returned by train, walked back to the car park, and went to the payment terminal.

That is when the sinking realisation hit: if you want the discounted parking rate, you have to validate your parking ticket at the station desk.

Except the desk was closed.

I did the right thing: park, train, return. The discount still failed, because the desk was closed.

So there I was, with a valid train ticket, the right behaviour, and still paying full price. Technically, the system works. In the real customer journey, it does not.

The intended journey (as designed)

Here’s how the experience is meant to go:

• You park at the station parking.
• You buy a train ticket.
• You take the train to your destination.
• You return by train to the same station.
• You walk back to the parking and pick up your car.
• You go to the parking payment terminal.
• You scan your train ticket at the payment terminal.
• You get the discounted parking rate.

That flow makes sense. It rewards the desired behaviour, and it should increase adoption. More adoption means the measure actually creates impact, and that is where success lives.

On paper, the journey is simple: reward the right behaviour.

The small detail that breaks the whole thing

The discount mechanism depends on one technical assumption: the payment terminal has a barcode reader.

Tickets bought at the desk or vending machine have a barcode printed on them. Great.

But if you are a digital user like me, you buy your ticket in the railway app. The app delivers your ticket as a QR code.

And here is the crux: the payment terminal cannot read that QR code.

The terminal reads barcodes. The app gives a QR code. That one mismatch breaks the whole incentive.

So you arrive with a valid ticket, a clear incentive, and the right intention, and you still cannot claim the discount. The solution works, but only for a specific type of user journey.

“There is a solution” (and why it still feels wrong)

A long time ago, back when Twitter was still Twitter, I raised this with NMBS support. Their reply was friendly, and they offered a workaround:

Use your parking ticket and go to the station desk area to have it scanned there. Then you can access the lower parking tariff.

Technically: solved.

From a user point of view: awkward.

Because the workaround forces you into a detour that does not fit the digital journey at all:

• I can buy my train ticket from home or while I am on the way.
• But now I have to explicitly foresee time to walk to the desk area before going to the tracks.
• In Ghent station, the scanner is quite easily accessible, albeit only during the office hours of the station desk.
• In Kortrijk, it is worse: the scanner is behind the glass, so you have to queue and ask the cashier to validate your parking ticket.

And the late evening reality makes it even sharper: the workaround is not available when you actually need it.

None of this feels like support for travellers. It feels like the traveller has to support the system.

None of this supports the traveller. It asks the traveller to support the system.

The hidden adoption killer: people do not even know the workaround exists

There is another layer to the story that matters even more for impact: most occasional train travellers I talk to do not even know this validation option exists.

They park once, see the full parking price, and conclude: “train station parking is just expensive.”

And once that belief settles in, it becomes a perfect excuse to stick to the car next time. Not because they hate trains, but because the experience confirms their expectation that multimodal travel comes with hassle and extra costs.

This is also where trust takes a hit. When some travellers get the discount because they know the trick, while others pay full price because they do not, the incentive starts to feel inconsistent and unfair. And when trust drops, adoption drops with it.

If a discount needs insider knowledge, it is not a discount, it is a puzzle.

What actually went wrong

Nothing is “broken” in the strict technical sense. The problem is that two systems are not aligned with how users behave today:

• The parking system expects a barcode.
• The railway app delivers a QR code.
• The discount logic exists, but the journey does not connect.
• The fallback process exists, but it is not visible, not intuitive, and sometimes not available.

Same goal, different assumptions.

Nothing is broken. The systems are simply not connected to the way people travel today.

This is exactly why innovation teams should validate value and usability before optimising the solution. If the experience does not fit the reality of the user, you can still deliver a technically correct result and miss the intended impact.

That is also why the Foundation section on defining value before defining solutions is so relevant here: it helps you check whether your solution helps you achieve the value you envisage, instead of only being technically correct.

The point is not technical correctness. The point is achieving the value you envisage.

Let’s innovate this observation

There are multiple ways to fix this, and they differ in cost, speed, and user impact.

Option 1: install QR readers at all terminals
Straightforward. Also logistically heavy and likely expensive, because it requires hardware upgrades across many locations.

Option 2: update the app to display a barcode for parking discounts
If the user has a valid ticket, the app could show a barcode version specifically for the parking terminal.

To be fair, this might not have been practical in the early days of smartphones. Screen resolution, brightness, and reliability were not always good enough for scanning in real world conditions.

But the world has moved on. Today, even cheaper smartphones have sufficiently sharp screens to make barcode display and scanning a realistic, scalable option.

Both options solve the scanning mismatch. But they still focus on “making the scan work”.

Fixing the reader is fine. Fixing the journey is better.

What to fix first if you want impact fast

Every extra step is a conversion drop. The moment the journey feels like effort, the behaviour change disappears.

So if you want impact quickly, I would prioritise it like this:

• Quick win: make the discount redeemable through the app journey, without a desk detour.
• Next: link the parking entitlement to the ticket purchase automatically, so there is nothing to “validate”.
• Then: remove scanning entirely by connecting the systems through identity and number plate.

Every extra step is a conversion drop.

The bigger opportunity: connect the journey and reduce friction

This is where number plate registration becomes powerful. The railway company already offers dedicated accounts today. Adding a licence plate field to such an account is not the hard part.

The real value is the connection: linking identity, ticket purchase, and parking entitlement so the user does not have to think about formats, scanners, desk hours, or queues.

And once you are thinking in journeys, you can go further:

• What if I could pay my parking in the same app where I buy my train ticket?
• Even better: what if I could buy ticket plus discounted parking in one flow?
• And what if buying a ticket also reserves parking capacity, giving you confidence there will be a space available?

Imagine the journey where you do nothing special. You park, travel, return, and leave. The system recognises you, applies the discount, and you never have to think about formats or validation steps. That is when incentives stop being a policy idea and start feeling like a service.

The best journey is the one where you do nothing special.

When it works naturally, adoption rises. When adoption rises, you get the intended results, and the whole incentive finally starts delivering real success, with smoother travel and more consistent multimodal behaviour.

Why this matters beyond train stations

This pattern shows up in innovation efforts everywhere, even when the tech is solid.

A team might deliver something that performs perfectly in tests, but the moment it meets real world constraints, the workflow becomes clunky, slow, or simply unrealistic. People do not reject the solution, they reject the friction.

Many teams invest in a tool or process that looks great in a demo and checks every functional requirement, yet people quietly avoid it because it adds steps, interrupts routines, or makes daily work harder than before.

And in complex settings, solutions often get delivered exactly as specified, but the real journey crosses departments, approvals, and exceptions. If the experience is not stitched together across that chain, adoption stays low and people revert to workarounds.

People do not reject solutions. They reject friction.

In all three cases, the lesson is the same: technical correctness is only the starting point. The real results, and the growth that follows, come from reducing friction and designing for how people actually move through the journey.

If you are curious how this could look in your specific context, you are welcome to get in touch via the contact page for a conversation.