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

  1. it's very interesting, Thanks for sharing a piece of valuable information to us & Knowledgeable also, keep on sharing like this.
    Best Aviation Academy in Chennai

    ReplyDelete

Post a Comment

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

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

Kafka + Cadence + WebSockets + Angular: managing event-driven microservices state with Uber Cadence

In the the previous post of the Event-driven microservices with Kafka series (see here ), I showed how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. In that proof of concept application which processes money transfers, one Kafka topic is used to receive incoming transfer messages and a second topic is used to store the account balances state and broadcast changes (i.e., to push notifications from the backend to the frontend). The first topic (called " transfers ") and the second topic (called " account-balances ") are connected through Kafka Streams. Uber Cadence In this post we are bringing Uber Cadence  into the mix to manage the state of the application (i.e., to keep the balance of the accounts updated), thus, Cadence replaces Kafka Streams. Cadence is an orchestration/workflow engine which unlike most of the other workflow engines out there (e.g., Zeebe, Camunda and m