← Quay lại blog

Cách vận hành spa, salon, nhà hàng khi mất internet

Wifi rớt giữa giờ cao điểm — đặt lịch, POS, màn hình bếp sẽ ra sao? Bài viết này giải thích phần mềm offline-first giúp bạn không ngừng phục vụ.

REENG Team

Mọi doanh nghiệp dịch vụ phụ thuộc vào internet đều mất tiền vì internet — chỉ là sớm hay muộn. Wifi rớt giữa lúc thanh toán. Cloud POS timeout vào giờ cao điểm. Hệ thống đặt lịch không xác nhận được hẹn vì API down.

Bài viết này giải thích phần mềm offline-first là gì, vì sao nó quan trọng cho doanh nghiệp dịch vụ, và cách đánh giá xem hệ thống hiện tại của bạn có đang âm thầm khiến bạn mất khách hay không.

Chi phí thực sự của “internet đang mất” tại doanh nghiệp dịch vụ

Hầu hết chủ quán đánh giá thấp chi phí của một lần mất mạng vì chi phí xuất hiện ở những chỗ không ai theo dõi:

  • Mất khách walk-in — khách đến, lễ tân không check-in được, khách bỏ đi. Không có ticket nào được tạo, không có số liệu nào ghi nhận thiệt hại.
  • Trùng lịch hẹn — nhân viên quay về sổ giấy trong lúc mất mạng, sau đó phải đối chiếu khi hệ thống có lại. Sai sót xảy ra.
  • Từ chối thanh toán thẻ — máy POS không xác thực được khi không có cloud, bạn nhận tiền mặt hoặc mất luôn giao dịch.
  • Ticket bếp hỗn loạn — order chất đống trên tablet phục vụ, rồi 50 ticket cùng bắn lên bếp khi có lại mạng.
  • Niềm tin sụt giảm — nhân viên bắt đầu không tin hệ thống. Họ tự nghĩ ra cách lách. Chất lượng dữ liệu sụp đổ.

Một salon mất 2 giờ đặt lịch vì 1 lần mất mạng thì mất ~5 triệu hoa hồng và ~2 triệu walk-in. Một nhà hàng 60 chỗ mất 1 giờ cao điểm tối thì mất ~30 triệu. Dòng trong P&L chỉ ghi “doanh thu tháng này thấp hơn.” Nguyên nhân vô hình.

”Offline-first” thực sự nghĩa là gì

Offline-first là quyết định thiết kế phần mềm, không phải feature flag. Nó nghĩa là:

  1. App làm việc trong trình duyệt, dùng database cục bộ (thường là IndexedDB hoặc PWA wrapper).
  2. Đồng bộ mạng là việc nền, không phải phụ thuộc bắt buộc. App không hỏi cloud xin phép nhận đặt lịch — nó ghi cục bộ trước, đồng bộ sau.
  3. Giải quyết conflict được tích hợp sẵn. Khi cloud quay lại và 2 thiết bị đã sửa cùng 1 record, hệ thống merge thay vì crash.

Phần mềm cloud-first đảo ngược điều này. Mọi hành động — nhận lịch, bắn ticket, thu tiền — đều nói chuyện với server trước. Khi server không tới được, hành động fail. UI quay vòng. Nhân viên rối. Khách chờ.

REENG được xây dựng offline-first. Trang load từ cache cục bộ, dữ liệu ghi vào PouchDB trong trình duyệt, đồng bộ chạy nền với cụm CouchDB. Khi wifi rớt, không gì trên màn hình thay đổi — nhân viên thậm chí không nhận ra cho đến khi nhìn vào báo hiệu kết nối.

Cách đánh giá xem hệ thống hiện tại có offline được không

Hỏi nhà cung cấp đúng 3 câu này:

  1. “Nếu tôi rút router ngay bây giờ và nhận 3 lịch hẹn, khi cắm lại thì sao?” Hệ thống offline-first thực sự sẽ hấp thụ các lịch vào queue cục bộ và đồng bộ khi có lại. Loại giả sẽ mất hoặc nhân đôi.
  2. “Nhân viên có in hoá đơn nhiệt được khi mất mạng không?” In hoá đơn thường qua local print bridge (QZ Tray, ePOS…). Nếu câu trả lời duy nhất của nhà cung cấp là “chúng tôi sẽ fix trên cloud,” bạn không phải offline-capable.
  3. “Màn hình bếp sẽ ra sao khi server room mất kết nối?” Với F&B, KDS là bài test offline quan trọng nhất. Order PHẢI tiếp tục chảy từ tablet FOH lên màn hình bếp qua mạng nội bộ, không phải qua round-trip cloud.

Nếu nhà cung cấp ngập ngừng ở bất kỳ câu nào, bạn đang dùng cloud-first đội lốt offline.

Hướng dẫn riêng cho từng ngành

Chúng tôi đã viết riêng cho từng ngành. Mỗi bài bao quát workflow cụ thể nơi offline quan trọng:

Việc cần làm trong tuần này

Chọn 1 kịch bản mất mạng đau nhất — tối thứ 6 cao điểm, chiều chủ nhật walk-in, đối soát cuối ngày. Chạy test thật: tắt wifi trên tablet trong 15 phút và làm workflow đó. Cái gì hỏng trước là cái cần fix trước.

Nếu phần mềm hiện tại fail bài test và bạn muốn thử cách khác, đăng ký dùng thử REENG miễn phí 3 tháng — không cần thẻ, đầy đủ tính năng, setup trong khoảng 1 giờ.