Norra POS (Point of Sales)

Khi có nhu cầu gộp bàn từ khách hàng thì công việc của nhân viên phục vụ phải thực hiện các bước ghi chú lại vào giấy, xong thông báo qua cho thu ngân và quản lý. Tới lúc tính tiền, thì thu ngân phải xem xét hoá đơn đã được cập nhật thông tin đúng số bàn hay chưa sau đó nếu có sai xót thì chỉnh sửa hoá đơn bằng tay.

Lỗi chưa xuất hiện khi lúc tiến hành thanh toán, mà lỗi có thể sẽ xảy ra lúc có hành động đổi bàn/gộp bàn mà hệ thống chưa biết.

Khi gộp bàn, hoá đơn đi theo bàn. Không cần phải thao tác bằng tay. Chỉ cần cập nhật thẳng vào POS, tất cả các vị trí khác trong hệ thống cũng sẽ nắm được thông tin.

Khi tách bàn (hoặc tách hoá đơn), hệ thống sẽ hỗ trợ 3 cách: chia món (hoá đơn) theo 50/50 (chia đều), chia theo phần trăm và cuối cùng là chia thủ công.

Ban đầu các developer đề xuất chia đều và chia theo phần trăm sẽ đơn giản và hỗ trợ nhân viên chia bàn (hoá đơn) nhanh hơn.

Nhưng khách hàng không phải lúc nào cũng muốn chia cho đều, vì sẽ có các trường hợp

1. Khách muốn tách hoá đơn để xuất hoá đơn riêng
2. Khách chỉ muốn tách các món riêng để trả chi phí riêng cho phần món mang về
3. Khách muốn tách riêng các món có chi phí cao hơn nên sẽ tự thanh toán phần riêng đó

Và khi đó các cách chia đều hoặc chia theo phần trăm, không thể thực hiện được các trường hợp ngoài mà khách muốn.

Gộp, tách, chuyển bàn (hoá đơn) là yêu cầu dành cho POS, nên không ai tranh luận chuyện có làm hay không.

Mình đem đúng mấy câu chuyện khách hàng ở trên đi kể cho team, sau đó được duyệt cho thêm cách chia thủ công.

Dev không ngại làm thêm, vì bản chất chỉ là chọn món rồi chuyển sang hóa đơn khác.

Với việc các câu chuyện tách bàn đã được thông qua thì các thành viên team dev cũng hiểu được tầm quan trọng của tính năng này và cũng không phản đối việc làm thêm này.

Mình đã thử nghiệm trực tiếp từ phiên bản wireframe với nhân viên nhà hàng, khi các bạn nhân viên thường sử dụng việc tách hoá đơn trước đây là phải dùng tay để chỉnh sửa các món và hoá đơn thì họ ấn tượng nhất là cách chia món/hoá đơn bằng phần trăm hoặc chia đôi, nhưng khi họ thấy việc chia món/hoá đơn theo ý muốn, nhân viên cảm thấy tiện hẳn — vì điều đó giúp họ giải quyết nhanh được trong công việc của họ.

Vì trước đó khi gặp trường hợp muốn tách riêng những món mà khách hàng cần thì nhân viên phải làm 1 thao tác là tạo 1 bàn mới phụ thuộc vào hiện tại thì mới ghi lại được món mà khách cần tách ra — đây là lý do mình cần phải làm gọn lại.

Vào giờ cao điểm, có trường hợp khách đến dùng bữa mà không đặt bàn trước. Lúc đó, hệ thống chưa có sơ đồ bàn để quản lý biết ngay bàn nào đang trống, nên quản lý phải đi vòng quanh nhà hàng để kiểm tra trực tiếp.

Ngoài ra, hệ thống cũng chưa thể ước lượng được bàn đang phục vụ còn bao lâu nữa mới trống — ví dụ bàn A bắt đầu phục vụ từ 5 giờ chiều, nếu biết số lượng khách và món đã gọi thì đáng lẽ có thể tính được thời điểm bàn sẽ trống, nhưng lúc đó hệ thống chưa làm đến mức đó.

Đây là một nhu cầu của hầu hết nhân viên sử dụng hệ thống POS, bởi họ muốn biết toàn bộ tình trạng của tầng để có thể đưa ra những quyết định kịp thời.

Hệ thống được thiết kế với 9 trạng thái bàn: bàn trống, bàn đã đặt, khách đã tới, khách tới trễ, đang phục vụ, đã phục vụ, chờ thanh toán, đã thanh toán, và bàn hủy hoặc khách không đến.

Màn hình chính là danh sách bàn, có thêm nút chuyển sang sơ đồ bàn.

Lý do chọn danh sách làm màn hình chính là vì đa số nhân viên dùng danh sách để phục vụ khi khách tới — danh sách hiển thị đúng bàn nào đang phục vụ dựa theo thông tin khách đã đặt.

Sơ đồ bàn thì dùng trong trường hợp cần biết bàn nào đang trống, bàn nào đã được đặt trước, để quản lý nắm được tình trạng chung của cả nhà hàng.

Ban đầu team Dev không đồng ý với việc quá nhiều trạng thái trên hệ thống, nhưng mỗi trạng thái sẽ hỗ trợ nhân viên biết được tình trạng thực tế tại bàn đang như thế nào - để hỗ trợ nhân viên phục vụ tốt nhất công việc của họ.

Trạng thái hiện tại được cập nhật bằng nút bấm reload. Mình từng đề xuất thêm thông báo trong app để báo có gì mới, nhắc nhân viên bấm reload — nhưng vẫn giữ quan điểm là hệ thống nên tự cập nhật, chỉ cần bấm lại khi có lỗi mạng hoặc lỗi hệ thống. Việc làm real‑time vẫn nằm trong hướng phát triển tiếp theo, chứ không bị bỏ hẳn.

Trong nhà hàng có nhiều vai trò cùng xem vào một đơn hàng. Nếu ai cũng có quyền sửa thì dễ dẫn đến sai sót và khó kiểm soát, còn nếu quản lý chỉ được xem thôi thì không xử lý được những tình huống thực tế phát sinh.

Mình nhận ra cần tách quyền xem ra khỏi quyền hành động, và đặt một nguyên tắc chung: ai là người thực hiện thao tác thì người đó không được là người duyệt thao tác đó. Ngoài ra với mỗi vai trò sẽ có thêm quyền xem và thao tác riêng biệt.

Mỗi vai trò chỉ được thực hiện đúng phần việc của mình — phục vụ tạo và sửa đơn của mình, gộp, tách, chuyển bàn; quản lý xem được toàn bộ và duyệt các thao tác nhạy cảm; thu ngân giữ toàn quyền xử lý tiền; còn bếp thì đứng ngoài hệ thống POS, sử dụng riêng màn hình KDS. Chi tiết đầy đủ được thể hiện trong bảng phân quyền bên dưới.

Ban đầu, đội ngũ sản phẩm muốn quản lý được biết hết mọi thứ và có quyền chỉnh sửa trực tiếp.

Mình thuyết phục theo hướng ngược lại: việc của ai thì người đó làm, quản lý chỉ nên xác nhận và giám sát cách nhân viên làm việc, chứ không được tự ý chỉnh sửa.

Lý do là lúc đó hệ thống chưa có audit log (nhật ký thao tác), nên nếu quản lý có quyền sửa hoặc xóa món, có thể dẫn đến trường hợp quản lý tự ý xóa món cho một bàn quen biết, rồi khi có vấn đề lại đổ ngược trách nhiệm cho nhân viên. Hoặc quản lý có thể tự ý áp mã giảm giá cho bàn mình muốn mà không cần ai xác nhận. Cách an toàn nhất là không để họ có quyền dẫn tới những sai phạm đó.

Khi khách đổi ý, phục vụ phải chạy xuống bếp để hỏi xem món đã được làm chưa, còn giấy order thì cứ phải chuyền qua chuyền lại giữa bếp và thu ngân.

Ý tưởng này đến từ chính trải nghiệm của mình khi đi ăn ở ngoài.

Khi muốn đổi món, mình sẽ hỏi nhân viên xem món đã làm chưa — nếu chưa làm thì đổi được, còn nếu đã làm thì thường mình sẽ đợi. Nhưng nếu đợi quá lâu, ví dụ hơn 30 phút kể từ lúc gọi món, thì mình có quyền yêu cầu hủy, và lúc đó là chuyện giữa quản lý, nhân viên và bếp tự giải quyết với nhau.

Mình nhận ra bếp thật ra đã luôn biết câu trả lời cho câu hỏi "món tới đâu rồi", chỉ là trước giờ POS không hỏi đến nó.

Thay vì làm riêng một luồng "đổi món", mình để trạng thái món trên KDS quyết định việc hủy hay đổi:

• Món chưa bắt đầu làm: hủy hay đổi đều được, cần mã xác nhận của quản lý.
• Món đang làm: hệ thống sẽ báo không thể hủy.
• Món đã chuẩn bị phục vụ hoặc đã phục vụ: chuyển thành void, quản lý xác nhận và ghi lý do.

Trạng thái từ KDS được hiển thị ngay trên dòng món của bàn đó. Ngoài trạng thái, hệ thống còn tính luôn thời gian tính từ lúc gọi món — nếu khách phải chờ quá lâu (như tình huống hơn 30 phút ở trên), có thể kiểm lại ngay trên POS xem đã thật sự quá thời gian hay chưa, để quản lý, nhân viên và bếp xử lý đúng người đúng việc.

Không có ai trong team phản biện hướng làm này.

Void flow (luồng xử lý món đã phục vụ) đã được thiết kế xong màn hình, không còn dừng ở mức ý tưởng.