Chuyển đến nội dung
Blog

White label hay tự xây booking engine của riêng bạn

Ban biên tập Tekravel

Báo giá gửi tới và con số nghe vẫn kham nổi. Một lập trình viên bạn tin tưởng đã định giá một booking engine — tìm kiếm, danh sách kết quả, thanh toán, một màn hình quản trị, ba tháng — và mức tiền không hề vô lý. Bạn đã muốn có hệ thống của riêng mình suốt hai năm nay. Đây chính là lúc câu hỏi white label hay tự xây booking engine thực sự được quyết định, và nó thường được quyết định dựa trên bằng chứng sai: giá của tháng đầu tiên thay vì hình dạng của năm thứ hai.

Bản báo giá đó trung thực. Nó cũng chỉ tính phần công việc mà bạn nhìn thấy được.

Một bản dự toán thật ra đang định giá cái gì

Gần như mọi dự toán bạn nhận được đều định giá phần bề mặt: ô tìm kiếm, danh sách kết quả, trang thông tin hành khách, bước thanh toán, bảng booking trong trang quản trị. Công việc đó là thật, và một đội ngũ giỏi làm nó tử tế. Nó cũng là nửa đã thành hàng hóa phổ thông — nửa mà hai đại lý bán cùng một chặng bay không bao giờ cạnh tranh nhau bằng. Chưa có khách nào chọn một đại lý vì màn hình tình trạng chỗ của họ giãn dòng đẹp hơn.

Nửa còn lại nằm ở phía kết nối mà bạn không thấy được từ trình duyệt. Đó là nơi các năm tháng trôi đi.

Chi phí nằm ở số lượng tích hợp, không phải ở giao diện

Xin quyền truy cập từ một supplier, bạn sẽ không nhận được API key ngay trong thư trả lời. Bạn nhận một môi trường thử nghiệm, một quy trình chứng nhận, thông tin đăng nhập cấp theo từng pháp nhân, một tài liệu quy tắc, và một đầu mối trả lời theo lịch của riêng họ. Rồi bạn gặp thứ tiếng lóng riêng của supplier đó: static rate ở chỗ này và live availability ở chỗ khác, allotment kèm release period nằm cạnh free-sale, một cut-off mà hệ thống của bạn buộc phải tôn trọng, fare rule quyết định một thay đổi có bị thu phí hay không, và một danh mục ancillary không khớp với danh mục của bất kỳ ai. Giờ nhân tất cả lên theo số supplier mà khách của bạn mặc định là bạn phải có.

Một tích hợp là một dự án. Sáu tích hợp là một phòng ban, và nó không bao giờ xong, bởi không một ai trong sáu bên đó đồng ý ngừng thay đổi.

Cái bẫy y hệt nằm sau từng màn hình mà báo giá có liệt kê. Tìm kiếm trông như một tính năng cho đến khi bạn mang hai hãng bay cùng trả về một hành trình với hai mức giá và phải quyết định, ngay trong mã nguồn, khách sẽ thấy mức nào. Hoàn tiền trông như một cái nút cho đến khi fare rule nói phạt, supplier nói voucher, còn khách nói thẻ. Markup trông như một con số trong trang cài đặt cho đến ngày bạn muốn một quy tắc cho khách doanh nghiệp, một quy tắc khác cho một sub-agent ở Đà Nẵng, và quy tắc thứ ba cho khách lẻ tới quầy — trên cùng một mức giá vé.

Phép tính đó là thứ một bản báo giá tự xây bỏ ra ngoài, và nó không phải sai số làm tròn so với phần giao diện — nó chính là sản phẩm. Trên một nền tảng white label, phần việc ấy đã làm xong và đã có người trực: nội dung của supplier đi tới storefront qua supplier group chứ không qua những hợp đồng bạn ký từng cái một, và một website bật chuyến bay, khách sạn, gói tour hay vé tham quan tùy theo thứ nó thật sự bán.

Bảng so sánh sống sót được tới năm thứ hai

Hãy đọc bảng này như một người vận hành chứ không phải như một người đi mua. Câu hỏi ở mỗi dòng đều giống nhau: ai là người chịu trách nhiệm?

 Tự xâyWhite label
Thời gian tới booking thật đầu tiênMột chu kỳ phát triển, rồi chứng nhận với từng supplierNgay trong ngày, trên subdomain của nền tảng — trình hướng dẫn đăng ký cấp phát mà không hỏi thẻ
Kết nối supplierBạn tự xin, tự chứng nhận và tự duy trì, từng cái mộtCó sẵn; bạn bật cái nào bạn bán
Ngôn ngữ và tiền tệ khi ra mắtĐúng phạm vi bạn đã chốt và đã trả tiền40 ngôn ngữ, gồm cả viết từ phải sang trái; mỗi website chọn tiền tệ mặc định và danh sách nó cung cấp
Một supplier đổi APIViệc trong backlog của bạn, theo hạn của họViệc của nền tảng, sửa một lần cho mọi tenant
Xuất vé lỗi lúc 2 giờ sángBạn, hoặc lập trình viên nào bắt máyTrực của nền tảng
Đổi giao diện websiteMột lần phát hànhMột thiết lập — theme, màu, phông chữ và logo đổi từ trang quản trị, không cần triển khai lại
Một quy trình không ai bánXây được, đúng y cách bạn đang vận hànhChỉ khi nền tảng đã mô hình hóa nó
Ai sở hữu mã nguồnBạnKhông phải bạn — bạn sở hữu thương hiệu, khách hàng và điều khoản thương mại

Hai dòng trong đó nghiêng về phía tự xây. Chúng không phải giải khuyến khích. Nếu thứ bạn bán đủ đặc thù, hai dòng ấy thắng tất cả những dòng phía trên.

Cái giá phải trả nếu chọn sai

Kiểu thất bại của một engine tự xây không phải là dự án đổ vỡ. Đổ vỡ thì nhìn thấy được, đau nhưng sống sót được. Phiên bản đắt đỏ là một hệ thống chạy được — rồi từ từ ngừng chạy.

Lập trình viên viết ra nó chuyển việc, và người kế nhiệm báo giá mọi thay đổi nhỏ như một rủi ro vì không ai còn sống từng đọc hết mã nguồn. Một supplier khai tử endpoint theo lịch riêng của họ và booking bắt đầu lỗi theo cách khách hàng nhận ra trước cả hệ thống giám sát của bạn. Một fare rule mã hóa đúng ở năm đầu không bao giờ được xem lại, và cái ADM đi kèm sau đó tính vào số IATA của bạn, không phải của nhà thầu. Thông tin thanh toán hết hạn. Chứng chỉ hết hạn. Một framework tụt lại hai phiên bản biến thành một cuộc bàn chuyện bảo mật mà bạn chưa hề dành ra một tuần nào cho nó.

Không thứ nào trong đó đến dưới dạng hóa đơn, và vì thế nó không bao giờ xuất hiện trong phép so sánh người ta thật sự làm. Nó đến dưới dạng sự chú tâm. Một chủ đại lý dành cả thứ Ba để gỡ một PNR hỏng thì thứ Ba đó không bán được gì, và những đại lý im ắng sau khi tự xây hiếm khi im ắng vì phần mềm hỏng — họ im ắng vì người từng mang khách về nay thành người đi bảo trì.

Khi nào tự xây thật sự là lựa chọn đúng

Có những lúc đúng thật, và các trường hợp đủ cụ thể để bạn tự đối chiếu.

  • Phần mềm chính là điểm khác biệt. Nếu bạn bán công nghệ cho các doanh nghiệp du lịch khác thay vì bán chuyến đi, bạn không thể thuê ngoài đúng thứ mình đang thu tiền.
  • Bạn đã có kỹ sư, và đã dự trù người thứ hai. Không phải người xây nó — mà người bảo trì tiếp nhận sau khi người đầu tiên rời đi. Một dự án tự xây không có kế hoạch kế nhiệm chỉ là đi thuê với thêm vài bước.
  • Bạn vận hành một quy trình không ai mô hình hóa. Một đơn vị làm tour hành hương tự giữ phòng, nối PNR đoàn với các mốc xử lý visa, không làm việc mà một engine chung chung sẽ vừa vặn.

Còn một hướng không thuộc bên nào: mua phần storefront, chỉ tự xây phần thật sự là của bạn. Nền tảng mở API chuyến bay và khách sạn đúng cho việc đó, dù quyền truy cập bắt đầu bằng một cuộc trao đổi chứ không phải một key tự lấy. Hãy định giá phương án lai trước khi cam kết xây toàn bộ, vì phần bạn thật sự muốn kiểm soát thường là một quy trình, không phải cả một cỗ máy.

Và nếu mô hình của bạn chạy trên sub-agent, hãy định giá cả phần đó cho đúng. Hạn mức tín dụng và hóa đơn settlement ở đây là khái niệm hạng nhất chứ không phải một bảng tính ai đó đối soát ngày Chủ nhật; trong một dự án tự xây, chúng là dự án thứ hai không ai đưa vào báo giá đầu tiên.

Một câu hỏi, hỏi cả hai bên

Trước khi ký bất cứ thứ gì, đặt cùng một câu hỏi cho lập trình viên và cho nền tảng: tháng Ba tới một supplier đổi quy trình chứng nhận — ai làm phần việc đó, theo hạn của ai, và tôi biết bằng cách nào? Hai câu trả lời sẽ không giống nhau, và khoảng cách giữa chúng mới là thứ bạn đang thật sự chọn.

So một storefront đang chạy với một bản báo giá là phép thử trung thực hơn so hai tài liệu với nhau, nên nếu bạn muốn thấy thứ gì được cấp phát trước khi cam kết, hãy mở thử một website trong trình hướng dẫn — nó không hỏi thẻ, và subdomain nó cấp vẫn là của bạn vĩnh viễn, kể cả sau khi bạn gắn tên miền riêng.

Ban biên tập Tekravel

Bộ phận công nghệ du lịch

Bộ phận công nghệ du lịch của Tekravel viết cho người trong ngành: chủ đại lý, đại lý gom vé và những lập trình viên tích hợp cho họ. Mỗi bài viết đều được đối chiếu với chính nền tảng mà nó mô tả trước khi đăng.