Khi trung gian trở thành rào cản
Một hành khách gần đây đã đặt chuyến bay của IndiGo thông qua nền tảng AirAsia MOVE. Khi kế hoạch thay đổi, anh ấy yêu cầu hủy chuyến đi. Hãng hàng không đã đồng ý. Đáng lẽ câu chuyện phải kết thúc ở đó. Thay vào đó, chính nền tảng này lại từ chối xử lý việc hủy chuyến, khiến hành khách bị kẹt giữa khoảng trống của hai công ty. Anh ấy đã công khai sự thất vọng của mình và gọi hệ thống là vô dụng và ngớ ngẩn. Sự giận dữ của anh ấy tuy gay gắt, nhưng nó đã chỉ ra một vấn đề ảnh hưởng đến hàng triệu hành khách vốn đang dựa vào các nền tảng tổng hợp (aggregators) để đơn giản hóa cuộc sống của họ.
Sự cố này chỉ là một sự kiện nhỏ trong bộ máy khổng lồ của ngành du lịch trực tuyến, nhưng nó mang theo một lời cảnh báo đanh thép. Chúng ta tải các ứng dụng này để tránh việc phải xoay xở giữa các trang web của hãng hàng không, cổng thanh toán và các mã xác nhận. Chúng ta mong đợi trung gian sẽ giúp mọi việc trôi chảy hơn, chứ không phải là kẻ gây cản trở. Khi một nền tảng không thể thực hiện việc hủy chuyến mà hãng hàng không đã phê duyệt, nó đã thất bại trong nhiệm vụ thực sự duy nhất của mình: truyền tải thông tin một cách trung thực từ người dùng đến nhà cung cấp dịch vụ và ngược lại.
Điều gì đã xảy ra
Chi tiết của vụ việc rất đơn giản, và đó chính là điều khiến nó trở nên đáng lo ngại. Hành khách không tranh chấp về một khoản phí ẩn hay đấu tranh với một lỗ hổng chính sách. Anh ấy đã thực hiện một thao tác tiêu chuẩn — hủy chuyến bay — và gặp phải một lỗi lẽ ra không nên tồn tại. IndiGo đã chấp nhận việc hủy chuyến. AirAsia MOVE thì không. Kết quả là một tình huống đôi bên cùng thiệt (lose-lose). Hành khách mất thời gian và sự an tâm. Nền tảng mất đi uy tín.
Loại thất bại này thường xảy ra sâu trong hệ thống hạ tầng mà hành khách không bao giờ nhìn thấy. Các đại lý du lịch trực tuyến và siêu ứng dụng (superapps) không lưu trữ kho chỗ của hãng hàng không trên máy chủ riêng của họ. Họ kết nối với các hãng hàng không thông qua các giao diện lập trình ứng dụng, hay API, để truyền dữ liệu qua lại. Khi bạn nhấn “cancel”, yêu cầu của bạn sẽ đi từ điện thoại đến hệ thống backend của nền tảng tổng hợp, sau đó chuyển đến hệ thống đặt chỗ của hãng hàng không. Hãng hàng không cập nhật trạng thái đặt chỗ và gửi xác nhận. Nền tảng tổng hợp có nhiệm vụ phải phản ánh thay đổi đó ngay lập tức và xử lý việc hoàn tiền hoặc tín dụng du lịch cho bạn.
Ở đâu đó trong chuỗi này, AirAsia MOVE đã bị tắc nghẽn. Có lẽ API đã không lấy được (poll) trạng thái cập nhật từ hệ thống của IndiGo. Có lẽ logic nội bộ của ứng dụng chứa một quy tắc được lập trình cứng (hardcoded) làm ghi đè lên phản hồi của hãng hàng không. Có lẽ các nhân viên chăm sóc khách hàng có thể thấy sự sai lệch trên màn hình của họ nhưng lại thiếu quyền hạn để cưỡng chế thực hiện việc hủy chuyến. Chúng ta không biết chính xác lỗi nằm ở đâu, nhưng chúng ta biết kết quả: một con người đã bị mắc kẹt trong một vòng lặp phần mềm, không thể hoàn tác một giao dịch mà mọi bên đều đã đồng ý là nên hoàn tác.
Tại sao niềm tin bị xói mòn nhanh hơn việc sửa lỗi mã nguồn
Hành khách có thể chấp nhận các giao diện vụng về. Họ có thể chấp nhận thời gian tải chậm. Nhưng họ sẽ không chấp nhận sự bất lực khi tiền bạc và các kế hoạch đang bị đe dọa. Việc hủy chuyến không phải là một yêu cầu tùy hứng. Nó thường xảy ra sau một cuộc khủng hoảng — một vấn đề y tế, một tình huống khẩn cấp trong gia đình, hoặc một xung đột công việc đột xuất. Người dùng vốn đã đang căng thẳng. Vai trò của ứng dụng là giảm bớt sự căng thẳng đó bằng cách xử lý các sự phức tạp ở phía backend. Khi nó lại tạo thêm một trở ngại mới, cái giá về mặt cảm xúc là cực kỳ lớn.
Đây là lý do tại sao sự bùng nổ công khai của hành khách lại quan trọng. Anh ấy không phàn nàn về việc thiếu điểm thưởng hay một thông báo đẩy bị chậm. Anh ấy mô tả nền tảng là vô dụng vì vào thời điểm anh ấy cần nó nhất, nó lại chủ động ngăn chặn một yêu cầu hợp lệ. Niềm tin vào các dịch vụ kỹ thuật số được xây dựng trên niềm tin rằng hệ thống sẽ tôn trọng ý định của bạn ngay cả khi hoàn cảnh thay đổi. Một lần phá vỡ lời hứa đó gây ra nhiều thiệt hại hơn là mười lần đặt chỗ suôn sẻ có thể bù đắp.
Vấn đề này cũng phơi bày một điểm mù chiến lược trong cách xây dựng nhiều nền tảng du lịch. Các đội ngũ kỹ thuật thường đổ nguồn lực vào phần front end: tìm kiếm nhanh, lịch trình đẹp mắt, thanh toán một chạm, các ưu đãi cá nhân hóa. Đó là những tính năng thúc đẩy lượt tải xuống. Các hoạt động sau khi đặt chỗ — thay đổi, hủy bỏ, hoàn tiền — lại bị coi là những thứ tính sau. Chúng nhận được các API cũ hơn, ít được giám sát hơn và có ít phương án dự phòng hơn. Nhưng đó chính xác là nơi người dùng khám phá ra liệu một ứng dụng là một công cụ thực thụ hay chỉ là một cuốn sách quảng cáo bóng bẩy.
Những gì các nền tảng du lịch cần phải làm đúng
Có những bài học rõ ràng ở đây cho bất kỳ công ty nào đóng vai trò trung gian giữa khách hàng và các hãng hàng không.
Hãy làm cho việc hủy đặt chỗ cũng đơn giản như việc đặt chỗ. Nếu người dùng có thể đặt chỗ chỉ với ba lần chạm, họ cũng phải có thể hoàn tác mà không cần phải đi qua một mê cung của chatbot, các menu ẩn và các biểu mẫu không được hỗ trợ. Quy trình hủy bỏ cần phải minh bạch, trung thực về các khoản phí và không chứa các mô hình thao túng tâm lý (dark patterns) nhằm gây cảm giác tội lỗi hoặc làm người dùng bối rối để họ giữ lại một yêu cầu đặt chỗ mà họ không thể sử dụng.
Xây dựng các cơ chế can thiệp thủ công thực sự hiệu quả. Tự động hóa rất tuyệt vời cho đến khi nó gặp lỗi. Khi xảy ra xung đột phản hồi API hoặc lỗi đồng bộ hóa, các nhân viên chăm sóc khách hàng phải có thẩm quyền và giao diện để can thiệp. Quá nhiều nền tảng được thiết kế như những pháo đài tự động hóa hoàn toàn mà không có lối vào cho sự can thiệp của con người. Kết quả là các nhân viên chỉ biết đọc theo kịch bản, xin lỗi không ngừng và gửi các yêu cầu hỗ trợ vào những "hố đen" không hồi đáp. Một cơ chế can thiệp hữu ích có nghĩa là nhân viên có thể thấy được sự chấp thuận của hãng hàng không, đối chiếu với yêu cầu đặt chỗ đang bị kẹt và thực hiện lệnh hủy trong thời gian thực.
Giữ cho phần mềm luôn đồng bộ với thực tế của hãng hàng không. Các nền tảng du lịch cần thoát khỏi việc cập nhật theo lô (batch updates) và các chu kỳ thăm dò (polling cycles) chậm chạp. Nếu một hãng hàng không đánh dấu vé là có thể hủy, có thể hoàn tiền hoặc đã đổi lịch, bên trung gian (aggregator) phải biết được trong vòng vài phút chứ không phải vài giờ. Điều đó đòi hỏi kiến trúc webhook mạnh mẽ, logic thử lại (retry logic) cho các lần kết nối (handshakes) thất bại và các tác vụ đối soát (reconciliation jobs) để gắn cờ các sai lệch trước khi người dùng phát hiện ra chúng. Nền tảng không bao giờ được là bên cuối cùng biết được tình trạng sản phẩm của chính mình.
Những gì hành khách có thể làm ngay lúc này
Cho đến khi ngành công nghiệp này khắc phục được những lỗ hổng này, hành khách cần phải tự bảo vệ mình. Nếu bạn đặt chỗ qua bất kỳ ứng dụng bên thứ ba nào, kể cả những ứng dụng lớn như AirAsia MOVE, hãy lưu lại bằng chứng. Hãy chụp màn hình mã xác nhận, chính sách hủy và bất kỳ thông tin liên lạc nào từ hãng hàng không. Hãy nắm rõ chính sách riêng của hãng hàng không trước khi mua; một số hãng cho phép thay đổi trực tiếp qua trang web của họ ngay cả đối với vé được bán bởi các đối tác. Nếu ứng dụng gặp lỗi, hãy liên hệ trực tiếp với hãng hàng không. Khi các bài đăng công khai nhận được sự chú ý, các công ty có xu hướng xử lý nhanh hơn so với qua các kênh hỗ trợ riêng tư. Và nếu một khoản tiền lớn đang bị kẹt, đừng ngần ngại khiếu nại thông qua các diễn đàn bảo vệ người tiêu dùng hoặc cơ chế hoàn tiền (chargeback).
Bài học thực sự
Trải nghiệm khách hàng không phải là một lớp sơn bóng bẩy mà bạn áp dụng sau khi mã nguồn đã được viết xong. Đó là việc mã nguồn hoạt động chính xác khi mọi thứ trở nên rắc rối. Một nền tảng đặt chỗ không thể hủy chuyến bay cũng giống như một chiếc xe không có số lùi. Nó có thể tiến về phía trước một cách tuyệt vời, nhưng sớm muộn gì bạn cũng sẽ cần phải lùi ra khỏi một vị trí.
Hành khách không đòi hỏi phép màu. Họ yêu cầu những công cụ thực hiện các lệnh cơ bản mà không thao túng tâm lý họ. Việc AirAsia MOVE không thực hiện việc hủy bỏ mà IndiGo đã chấp nhận là một lời nhắc nhở rằng sự tiện lợi chỉ có thật khi toàn bộ quy trình hoạt động trơn tru. Cho đến khi các nền tảng du lịch đầu tư mạnh mẽ vào độ tin cậy sau mua hàng tương đương với việc đầu tư vào phễu thu hút khách hàng, người dùng sẽ vẫn luôn cảnh giác. Và họ nên làm như vậy.