Skip to main content

Apology not accepted

TL;DR: After being disrespected multiple times as customer by Smartwings airlines over the years, now I can finally have my little revenge by claiming 400 euros for a delayed flight. The airline sent me an insincere and pathetic apologetic email message. Apology not accepted.

I have been a regular customer of Smartwings airlines for quite a long time already.
It was not by choice. The reason I fly with them is because it is the only airline which flies directly from Prague (where I live) to Valencia (my hometown).
Although I appreciate that they include 15 kg of check-in luggage at no extra charge, the ticket prices are quite high compared to other low-cost airlines (Wizzair and Ryanair, for example).

Also, they do not seem to care much about their customers. Several times they cancelled a flight just few days before the departure date due to "operational reasons". It would seem to me that the real reason was that they did not sale as many tickets for that flight as they expected, so it would be more profitable to just cancel the flight and screw those of us who already bought tickets.

Another example: in the past, they used to advertise direct flights between Prague and Malaga when in reality, it was a Prague --> Valencia --> Malaga flight.
Let me try to explain it because it was quite surreal.
Passengers flying to both Valencia and Malaga would get on board the same airplane in Prague.
Then the plane would land at Valencia airport, where only the passengers who purchased a PRG-VLC ticket would get out of the plane. Immediately after that, new passengers flying VLC --> PRG would get into the plane.
Then the plane would fly from Valencia to Malaga! In Malaga, the passengers who joined the flight in VLC would remain seated, while the passengers who bought a ticket from PRG to Malaga would finally get out of the plane and again new passengers heading to Prague would get into the plane...

Also, the schedules of their flights are unreliable. Delays are frequent.
One of such delays happened last Thursday March 29, 2018.
The flight QS1054 from PRG to VLC was packed because of the upcoming Easter weekend.
The departure time was scheduled at 18:35 and the arrival time was 21:20.
But after almost 4 hours of waiting, the plane took off at 22:16 and we landed at 01:00 AM (3 hours and 40 minutes delayed).





According to the EU regulation, each passenger of that flight is entitled to a 400 euros compensation:



During the flight, the captain, apologized several times and literally mentioned "extraordinary circumstances" (out of the airlines control) as the cause of the delay.
He specifically said that the bad weather in Egypt caused a chain of delays which resulted in a late departure of our flight. What a lame excuse!!! 

This what the EU regulation says about the extraordinary circumstances:



I am pretty sure that the "adverse weather conditions" should occur either at the departure airport or at the destination or somewhere in between to be counted as an "extraordinary circumstance", and as far as I know, Egypt is nowhere in the route from Prague to Valencia.

But it gets better (or more ridiculous), the next day, every single passenger of the flight got the following apology by email:



This seems so fake to me, the only reason they sent that was because they hope that maybe someone would not claim their compensation after reading it.
Money is the only apology I want, hence, apology not accepted.

Comments

Popular posts from this blog

Kafka + WebSockets + Angular: event-driven microservices all the way to the frontend

In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client

A Java dev journey to full-stack: first chapter

The Motivation I am an experienced Java developer and (surprise!) I like Java. I know it is not perfect but it works just fine for me (I enjoy type-safety and I do not consider verbosity a disadvantage, quite the opposite). I also know that some people dislike Java, which is also fine. But recently I decided to step out of my confort zone as developer, my goal isn't to be one of the "cool kids" neither trying to monetize a new skill in the job market. I have a quite practical motivation: I want to be able to build more (different) stuff. That's exactly the same reason why I learnt Android development by myself a couple of years ago. Web applications are ubiquitous, even more than native mobile apps, and thanks to cloud computing, one can easily and inexpensively release their idea/app to the World Wide Web. I already did some Web development in the past, in the bad old days of JSP and JSF, but the process was slow and painful. Nowadays the Web landscape h

Using Apache Kafka to implement event-driven microservices

When talking about microservices architecture, most people think of a network of stateless services which communicate through HTTP (one may call it RESTful or not, depending on how much of a nitpicker one is). But there is another way, which may be more suitable depending on the use case at hand. I am talking about event-driven microservices, where in addition to the classic request-response pattern, services publish messages which represent events (facts) and subscribe to topics (or queues depending on the terminology used) to receive events/messages. To fully understand and embrace this new software design paradigm is not straight-forward but it is totally worth it (at least looking into it). There are several interconnected concepts which need to be explored in order to discover the advantages of event-driven design and the evolutionary path which led to it, for example: Log (including log-structured storage engine and write-ahead log) Materialized View Event Sourcing C o