Quản lý 3-5 khách sạn mini cùng lúc: một tài khoản, không cần chạy qua từng nơi

Hai kỳ trước của loạt bài DiOwner đi theo chiều sâu của một cơ sở: kỳ đầu là cách đọc doanh thu, công suất, ADR và RevPAR ngay trên điện thoại, kỳ sau là cách kiểm soát thất thoát doanh thu bằng số liệu minh bạch. Kỳ này đổi chiều: không đi sâu hơn vào một khách sạn, mà đi rộng ra nhiều khách sạn. Đây là tình huống của một lớp chủ cơ sở ngày càng đông ở Việt Nam — người mở cơ sở thứ hai vì cơ sở thứ nhất chạy được, rồi cơ sở thứ ba, thứ tư, và đến một lúc phát hiện việc khó nhất không còn là vận hành từng nơi.

Việc khó nhất là nhìn cả ba nơi cùng một lúc, bằng cùng một thước đo. Bài này viết cho chủ sở hữu ba đến năm cơ sở nhỏ — khách sạn mini, nhà nghỉ, homestay, căn hộ dịch vụ — thường tự quản, không có bộ phận phân tích, và phần lớn thời gian ở trên đường giữa các cơ sở. Nói trước một điều để tránh hiểu nhầm xuyên suốt bài: vấn đề nằm ở chỗ số liệu về trễ và không cùng chuẩn, không nằm ở người quản lý từng nơi. Ba bảng tính do ba người làm cẩn thận vẫn không cộng lại được thành một bức tranh, và lý do hoàn toàn mang tính kỹ thuật.

Phần 1: Chủ vài cơ sở nhỏ hiện đang phải làm gì để biết tình hình

Hãy mô tả đúng hiện trạng trước khi bàn giải pháp. Với một người có ba đến năm cơ sở, quy trình nắm tình hình thường là tổ hợp của bốn việc dưới đây, làm song song và lặp lại mỗi tuần.

Bốn việc lặp lại

• Gọi hoặc nhắn hỏi từng nơi. Tối nay còn bao nhiêu phòng trống, hôm nay thu được bao nhiêu, có sự cố gì không. Câu trả lời đến rải rác trong ngày, mỗi nơi một kiểu diễn đạt, và không lưu lại thành dữ liệu để tuần sau đối chiếu.
• Chờ báo cáo cuối tháng. Thứ nhận được là một bảng tổng kết, thường vào giữa tháng sau. Nó đủ để biết tháng vừa rồi thế nào, nhưng đã quá muộn để làm gì với tháng vừa rồi.
• Mỗi nơi một mẫu bảng tính. Cơ sở này ghi doanh thu theo ngày dương lịch, cơ sở kia ghi theo ca trực; nơi này tách tiền phòng với dịch vụ, nơi kia gộp; nơi này trừ phòng bảo trì khỏi tổng phòng, nơi kia không trừ. Mỗi bảng đều hợp lý trong nội bộ của nó.
• Tự cộng lại bằng tay. Bước cuối cùng thường do chính người chủ làm, vào buổi tối, trên một bảng tính thứ tư — và đây là bước sinh ra nhiều sai số nhất, vì nó cộng những con số không cùng định nghĩa.

Ba hệ quả của cách làm này

• Số về trễ nên chỉ dùng để ghi nhận, không dùng để điều hành. Biết cơ sở B đang tụt sau khi tháng đã đóng thì thông tin ấy chỉ còn giá trị lịch sử.
• Không so sánh được giữa các cơ sở. Khi hai nơi tính công suất theo hai cách, con số 78% và 74% không nói lên điều gì về việc nơi nào đang chạy tốt hơn.
• Người quản lý ở cơ sở mất thời gian làm báo cáo thay vì bán phòng. Mỗi lần chủ hỏi là một lần phải dừng việc, mở sổ, cộng lại — và phần công sức đó không tạo ra đồng doanh thu nào.

Phần 2: Vì sao ba bảng tính đều đúng vẫn không cộng được thành một bức tranh

Đây là phần cốt lõi và cũng là phần dễ bị bỏ qua nhất, vì nó không giống một vấn đề — mỗi bảng tính riêng lẻ đều sạch sẽ và người làm ra nó đều giải thích được từng dòng. Sai lệch chỉ xuất hiện ở thời điểm cộng chúng lại.

Năm chỗ lệch chuẩn thường gặp nhất

• 1. Mốc cắt ngày khác nhau. Ngày làm việc của một cơ sở lưu trú kết thúc ở phiên chốt sổ đêm chứ không phải lúc 24 giờ. Nếu cơ sở A chốt lúc 2 giờ sáng còn cơ sở B cộng theo ngày dương lịch, thì mọi khoản phát sinh sau nửa đêm rơi vào hai ngày khác nhau ở hai nơi. Cuối tháng phần lệch không tự triệt tiêu, vì nó nằm ở ranh giới đầu và cuối kỳ.
• 2. Mẫu số của công suất khác nhau. Phòng đang sửa chữa dài hạn có nên nằm trong tổng phòng bán được hay không là một lựa chọn, và hai nơi có thể chọn khác nhau. Quy ước nên dùng thống nhất: trừ phòng ngừng khai thác dài hạn, giữ nguyên phòng tạm thời chưa bán được — chọn cách nào cũng được, miễn cả danh mục chọn giống nhau và không đổi giữa chừng.
• 3. Cách gọi tên khoản doanh thu khác nhau. Nơi này để "dịch vụ" gồm cả nước uống trong phòng, nơi kia tách riêng; nơi này đưa tiền thu hộ xe đưa đón vào doanh thu, nơi kia để ngoài. Cộng lại thì tổng vừa thừa vừa thiếu, và không ai chỉ ra được chỗ nào.
• 4. Cách xử lý tiền nhận trước khác nhau. Cọc giữ phòng cho tháng sau được ghi vào tháng nhận tiền ở một nơi và ghi vào tháng khách ở tại nơi khác. Đây là chỗ khiến doanh thu mùa cao điểm của cả danh mục bị thổi lên rồi hụt xuống một cách khó hiểu.
• 5. Nguồn khách ghi sau thay vì ghi ngay. Khi nguồn đặt phòng được điền vào lúc làm báo cáo chứ không phải lúc nhận đặt, tỷ trọng kênh bán trở thành con số ước lượng — và ước lượng của ba người là ba kết quả.

Năm chỗ này có một điểm chung đáng chú ý: không chỗ nào sửa được bằng cách làm báo cáo cẩn thận hơn. Chúng là hệ quả của việc mỗi cơ sở tự định nghĩa lấy thước đo của mình. Muốn hết lệch thì phải đổi chỗ đặt định nghĩa — đưa nó ra khỏi từng bảng tính và đặt vào một nơi dùng chung. Đó là nội dung phần tiếp theo. Cách nhìn tương tự ở chặng từ hóa đơn sang sổ sách đã được trình bày trong bài kế toán khách sạn nhỏ theo Thông tư 99.

Phần 3: Một danh mục thì phải có một hệ danh mục dùng chung

"Danh mục" ở đây hiểu theo nghĩa đơn giản nhất: tập hợp các cơ sở thuộc cùng một người chủ hoặc một nhóm chủ. Để một danh mục có thể được nhìn như một chỉnh thể, năm thứ dưới đây phải giống nhau ở mọi cơ sở. Đây là điều kiện tiên quyết, làm trước khi nói tới bất kỳ phần mềm hay bảng điều khiển nào.

Năm thứ phải dùng chung

• Mốc ngày kế toán theo phiên chốt sổ đêm. Một mốc giờ duy nhất, ghi thành quy định nội bộ, áp cho mọi cơ sở và mọi báo cáo. Đổi mốc giữa chừng làm mọi so sánh cùng kỳ mất ý nghĩa.
• Danh mục hạng phòng. Mỗi cơ sở có phòng khác nhau là bình thường, nhưng cách phân nhóm thì nên chung: phòng đơn, phòng đôi, phòng gia đình, phòng giường tầng. Có nhóm chung mới so được giá bình quân giữa các nơi.
• Danh mục khoản mục doanh thu. Mỗi loại doanh thu một mã, dùng chung toàn danh mục, và bỏ hẳn ô "khác". Tách rõ ba nhóm: doanh thu của chính cơ sở, chi phí bán qua kênh trung gian, tiền thu hộ cho bên thứ ba.
• Danh mục nguồn khách. Đặt trực tiếp, đặt qua kênh trực tuyến, khách quen quay lại, khách vãng lai — cùng một bộ mã, ghi ngay tại thời điểm nhận đặt chứ không điền sau.
• Công thức tính chỉ số. Công suất, giá phòng bình quân, doanh thu trên mỗi phòng sẵn có — mỗi chỉ số một công thức, viết ra giấy một lần, dùng cho cả danh mục. Đây là thứ rẻ nhất để thống nhất và tốn kém nhất nếu không thống nhất.

Điều đáng mừng là năm thứ này không đòi hỏi đầu tư gì. Chúng là một buổi làm việc nội bộ và một trang quy định. Cái cần đầu tư nằm ở chỗ khác: làm sao để sau khi đã thống nhất, các định nghĩa ấy được thi hành tự động thay vì phụ thuộc vào việc ai đó nhớ. Đây chính là việc mà một phần mềm quản lý khách sạn cloud AI dùng chung cho cả danh mục làm được còn ba bảng tính rời thì không: danh mục dùng chung nằm ở một chỗ, mọi cơ sở lấy từ đó, và không ai phải nhớ gì cả.

Phần 4: Vì sao chủ cần một ứng dụng chỉ đọc riêng, không phải một tài khoản hệ vận hành

Đây là điểm mà chúng tôi cho là khác biệt thật sự, và cũng là điểm ít được nói tới nhất trên thị trường. Gần như mọi giải pháp được chào ra thị trường đều là hệ thống quản lý vận hành đầy đủ — dựng cho lễ tân, buồng phòng, thu ngân, kế toán. Cách giải quyết mặc định cho nhu cầu của người chủ là cấp cho họ một tài khoản trong chính hệ thống ấy, thường là tài khoản quản trị. Cách đó có bốn vấn đề thực tế.

Bốn vấn đề của việc cấp tài khoản hệ vận hành cho chủ

• Người chủ phải học nghiệp vụ mới đọc được số. Màn hình của hệ vận hành được thiết kế cho người làm nghiệp vụ tám tiếng mỗi ngày: sơ đồ phòng, hàng chờ nhận phòng, hóa đơn đang mở. Người chủ chỉ cần biết năm con số, nhưng phải đi qua ba lớp menu mới tới.
• Nỗi sợ bấm nhầm là có thật. Một tài khoản có quyền ghi thì về nguyên tắc có thể sửa dữ liệu đang chạy. Nhiều người chủ vì thế không dám mở hệ thống, hoặc mở rồi chỉ dám nhìn — và cuối cùng quay lại gọi điện hỏi.
• Hệ vận hành không được dựng cho màn hình điện thoại. Nó là công cụ làm việc trên máy tính ở quầy. Trong khi đó, thời điểm người chủ cần số nhất lại là lúc đang ở trên đường, trước một cuộc gặp, hoặc buổi tối ở nhà.
• Phân quyền theo phạm vi sở hữu không phải việc của hệ vận hành. Khi một danh mục có người góp vốn vào một vài cơ sở chứ không phải tất cả, thứ cần là "người này thấy đúng ba cơ sở này" — một khái niệm thuộc về quyền sở hữu, không thuộc về vai trò nghiệp vụ.

Ứng dụng chỉ đọc giải bài toán đó thế nào

• Chỉ đọc theo thiết kế, không phải theo cấu hình. DiOwner không có màn hình nào để sửa dữ liệu vận hành. Đây là điều kiện để người chủ mở ứng dụng mà không phải cân nhắc gì, và cũng là điều kiện để đội vận hành yên tâm rằng số liệu của họ không bị thay đổi từ bên ngoài.
• Chỉ hiển thị thứ người chủ cần quyết định. Doanh thu và cơ cấu nguồn, công suất, giá phòng bình quân, doanh thu trên mỗi phòng sẵn có, công nợ — của từng cơ sở và của cả danh mục, trên một màn hình.
• Dựng cho điện thoại ngay từ đầu, vì đó là thiết bị người chủ luôn mang theo giữa các lần đi lại.
• Phân quyền theo cơ sở. Mỗi người đồng sở hữu chỉ thấy đúng những cơ sở mình có phần — minh bạch với đối tác mà không phải mở toàn bộ hệ thống cho họ.
• Số đọc thẳng từ hệ thống đang chạy, không qua bước tổng hợp. Không có bảng trung gian nào giữa dữ liệu gốc và màn hình, nên không có chỗ cho sai lệch do nhập lại.

Chi tiết về từng màn hình và từng chỉ số có trên trang sản phẩm DiOwner dành cho DiCloud. Điểm cần nhớ ở đây chỉ là sự phân vai: hệ vận hành phục vụ người làm nghiệp vụ, ứng dụng chỉ đọc phục vụ người ra quyết định đầu tư — hai đối tượng khác nhau, hai thiết kế khác nhau, cùng một nguồn dữ liệu.

Phần 5: Sáu câu hỏi nên trả lời được trong ba phút mỗi sáng

Một danh mục ba đến năm cơ sở nhỏ không cần bảng điều khiển phức tạp. Nó cần đúng sáu câu trả lời, mỗi sáng, không phải gọi ai. Dưới đây là bộ câu hỏi chúng tôi đề nghị, xếp theo thứ tự nên nhìn.

Bộ sáu câu hỏi

• 1. Tối nay mỗi cơ sở còn bao nhiêu phòng trống? Đây là câu duy nhất có thể hành động ngay trong ngày — mở giá, đẩy kênh bán, gọi khách quen.
• 2. Hôm qua cả danh mục thu được bao nhiêu, và phần nào đến từ đâu? Nhìn cơ cấu nguồn quan trọng hơn nhìn tổng số, vì tổng số chỉ nói kết quả còn cơ cấu nói nguyên nhân.
• 3. Giá phòng bình quân của từng cơ sở đang là bao nhiêu so với tuần trước? Giá tụt trong khi công suất không tăng là tín hiệu cần xem lại chính sách bán.
• 4. Cơ sở nào đang chệch nhiều nhất so với chính nó cùng kỳ năm ngoái? So một cơ sở với chính nó luôn công bằng hơn so nó với cơ sở khác — nhất là khi các cơ sở khác quy mô và khác vị trí.
• 5. Công nợ đang treo bao nhiêu và có khoản nào quá hạn không? Với cơ sở nhỏ, một khoản công nợ bị quên có thể bằng cả tuần lợi nhuận.
• 6. Tiền nhận trước đang giữ là bao nhiêu? Đây là tiền đã vào tài khoản nhưng chưa phải của mình. Không tách ra thì rất dễ nhầm dòng tiền dồi dào với kinh doanh tốt.

Nếu sáu câu này phải hỏi người khác mới có câu trả lời, thì dù mỗi lần hỏi chỉ mất vài phút, cái mất lớn hơn nằm ở chỗ: người chủ chỉ hỏi khi thấy có gì đó bất thường, mà bất thường thì thường chỉ lộ ra khi đã muộn.

Phần 6: So sánh giữa các cơ sở sao cho công bằng

Khi đã nhìn được cả danh mục trên một màn hình, phản xạ tự nhiên là xếp hạng. Đây là lúc dễ rút ra kết luận sai nhất, vì các cơ sở nhỏ trong cùng một danh mục thường rất khác nhau: khác số phòng, khác vị trí, khác tệp khách, khác thời điểm khai trương.

Bốn quy tắc so sánh

• Đừng so doanh thu tuyệt đối. Cơ sở 30 phòng đương nhiên thu nhiều hơn cơ sở 12 phòng. Con số đó không nói gì về chất lượng vận hành.
• So bằng chỉ số theo đầu phòng. Doanh thu trên mỗi phòng sẵn có là thước đo gộp cả giá lẫn công suất vào một số, nên nó so được giữa hai cơ sở khác quy mô. Cách tính và ý nghĩa đã trình bày kỹ trong bài đầu của loạt DiOwner.
• Hợp nhất thì cộng phòng rồi mới chia. Công suất của cả danh mục phải tính bằng tổng đêm phòng đã bán chia tổng đêm phòng có thể bán, không phải lấy trung bình cộng các phần trăm. Trung bình phần trăm cho cơ sở 12 phòng và cơ sở 30 phòng cùng trọng số — và ra một con số không tồn tại trên thực tế.
• So với cùng kỳ trước khi so với nhau. Xu hướng của từng cơ sở theo thời gian là thông tin đáng tin hơn thứ hạng giữa các cơ sở tại một thời điểm.

Phần 7: Dự báo cho nhiều cơ sở — dựa trên phòng đã đặt, không phải phỏng đoán

Với một cơ sở, chủ còn có thể cảm nhận được tháng tới đông hay vắng. Với ba đến năm cơ sở ở các địa bàn khác nhau thì cảm nhận không còn dùng được, vì mỗi nơi có nhịp riêng.

Cách dự báo hoạt động và giới hạn của nó

• Căn cứ là số phòng đã đặt trước. Dự báo trên DiOwner được tính theo lượng đặt phòng đã có trong hệ thống cho các ngày sắp tới, với tầm nhìn 30, 60 và 90 ngày, kèm tùy chọn khoảng ngày tự do. Đây là dự báo thống kê trên số liệu thật, không phải mô hình trí tuệ nhân tạo — chúng tôi nói rõ điều này vì gọi đúng tên thì người dùng biết tin nó tới đâu.
• Giá trị lớn nhất là ở chỗ so sánh giữa các cơ sở. Khi một cơ sở có lượng đặt trước cho tháng sau thấp hơn hẳn các cơ sở còn lại, đó là tín hiệu để can thiệp sớm — trong khi chờ tới cuối tháng thì không còn gì để can thiệp.
• Giới hạn phải biết: dự báo dựa trên phòng đã đặt sẽ luôn thấp hơn thực tế ở những thị trường mà khách đặt sát ngày. Nó cho biết sàn chắc chắn, không cho biết đỉnh.

Điều DiOwner chưa hiển thị, nói rõ để khỏi kỳ vọng nhầm

• Lợi nhuận gộp trên mỗi phòng sẵn có (GOPPAR) — Sắp ra mắt. Chỉ số này đòi hỏi tập hợp đủ chi phí vận hành theo cùng một chuẩn ở mọi cơ sở, nên nó nằm ở lộ trình chứ chưa nằm trong bộ chỉ số đang chạy. Những gì đang chạy là lớp doanh thu và công nợ.
• Vì vậy, đừng đọc thứ hạng doanh thu như thứ hạng lợi nhuận. Một cơ sở đứng đầu về doanh thu trên mỗi phòng vẫn có thể đứng cuối về lợi nhuận nếu chi phí thuê mặt bằng cao hơn hẳn.

Phần 8: Bảng tổng hợp — vướng ở đâu khi có nhiều cơ sở và xử thế nào

Phần 9: Lộ trình năm bước cho chủ 3-5 cơ sở

Thứ tự dưới đây có chủ ý: ba bước đầu là việc nội bộ, không tốn tiền và làm được ngay trong tuần này; hai bước sau mới liên quan tới công cụ.

Ba bước nội bộ

• Bước 1 — Chốt một mốc ngày kế toán duy nhất theo phiên chốt sổ đêm, thông báo cho người trực ở mọi cơ sở, ghi thành một dòng trong quy định nội bộ.
• Bước 2 — Dựng một hệ danh mục dùng chung: nhóm hạng phòng, khoản mục doanh thu, nguồn khách. Một buổi làm việc với người phụ trách các cơ sở là đủ, và nên làm cùng nhau để mỗi nơi hiểu vì sao phải đổi.
• Bước 3 — Viết ra công thức của ba chỉ số sẽ dùng để so sánh, kèm quy ước về phòng ngừng khai thác. Dán bản này ở nơi ai cũng đọc được; nó chấm dứt phần lớn tranh luận về sau.

Hai bước về công cụ

• Bước 4 — Đưa các cơ sở về cùng một nền tảng vận hành. Không nhất thiết làm cùng lúc; làm lần lượt cũng được, miễn hệ danh mục ở bước 2 đã sẵn sàng để cơ sở mới chuyển vào là dùng ngay. Cách chuyển dữ liệu an toàn đã được trình bày trong bài chuyển dữ liệu từ bảng tính sang phần mềm quản lý.
• Bước 5 — Mở lớp đọc riêng cho người chủ và người góp vốn, phân quyền đúng phạm vi sở hữu. Bước này chỉ có nghĩa sau bốn bước trên; mở bảng điều khiển trên dữ liệu chưa chuẩn hóa chỉ làm cho những con số sai được nhìn thấy nhanh hơn.

Kết luận

Người có ba đến năm cơ sở nhỏ không thiếu số liệu — họ thừa số liệu và thiếu một thước đo chung. Ba việc quyết định, theo đúng thứ tự: một mốc ngày kế toán duy nhất cho cả danh mục; một hệ danh mục dùng chung để mọi cơ sở gọi cùng một thứ bằng cùng một tên; và một lớp đọc riêng cho người chủ, tách khỏi màn hình của người làm nghiệp vụ. Hai việc đầu là quy ước nội bộ, làm được trong tuần này và không tốn gì. Việc thứ ba là chỗ mà một công cụ đúng thiết kế tạo ra khác biệt thật.

Trên nền ấy, một phần mềm quản lý khách sạn online AI DiCloud đóng vai hệ vận hành dùng chung cho các cơ sở nhỏ, còn DiOwner là lớp chỉ đọc cho người chủ — cùng một nguồn dữ liệu, hai giao diện cho hai vai trò. Đó cũng là cách chúng tôi hiểu cụm phần mềm quản lý khách sạn đa cơ sở: không phải một màn hình có nhiều biểu đồ hơn, mà là một hệ danh mục chung cộng với một lớp đọc riêng cho người ra quyết định. Toàn bộ cấu phần này nằm trong giải pháp quản lý khách sạn tổng thể của DiHotel Solutions Corps.

Nếu danh mục của bạn có khu nghỉ dưỡng, khách sạn 4–5 sao, nhiều pháp nhân hoặc cơ sở đang thuê đơn vị quản lý ngoài, thì bài cùng đợt bên DiHotel Blog bàn đúng tầng đó: một dashboard cho cả chuỗi — nhiều chủ sở hữu trong một danh mục, mùa vụ lệch nhau giữa các vùng, và ranh giới dữ liệu với đơn vị quản lý. Ở tầng đó, nghiệp vụ do phần mềm quản lý khách sạn AI DiHotel đảm nhiệm — nền tảng gốc dành cho khách sạn 4–5 sao, resort và chuỗi — trong khi các cơ sở nhỏ cùng danh mục dùng DiCloud, và cùng một ứng dụng DiOwner đọc số từ cả hai nền tảng.