Mang đi là một hoạt động kinh doanh khác với ăn tại chỗ. Khách không ngồi xuống. Không có bàn để đặt họ vào. Họ muốn biết hai điều: khi nào thức ăn sẵn sàng và làm thế nào để thanh toán. Bất cứ điều gì cản trở hai câu hỏi đó là ma sát, và ma sát làm mất đơn hàng vào tay đối thủ có quy trình gọn gàng hơn.
Trong vài năm qua, bảng quy tắc cho mang đi đã chuyển xa khỏi điện thoại và quầy đến tận nơi sang quy trình QR-và-hàng-đợi có khả năng mở rộng. Khách lấy số hàng đợi, xây dựng đơn hàng trên điện thoại riêng, thanh toán bằng cách tải ảnh chụp chuyển khoản ngân hàng và nhận hàng khi số của họ được gọi. Toàn bộ hoạt động trong trình duyệt, không ứng dụng, không quầy lễ tân, không tai nghe.
Bài viết này hướng dẫn qua các quyết định thực tế làm cho quy trình này hoạt động trong nhà hàng thực.
Định giá mang đi riêng
Quyết định đầu tiên là liệu giá mang đi có nên giống giá ăn tại chỗ không. Ở nhiều quốc gia câu trả lời là không. Ăn tại chỗ bao gồm đĩa, cốc, dịch vụ bàn và một trải nghiệm. Mang đi bao gồm bao bì và giả định rằng khách sẽ ăn ở nơi khác. Cấu trúc chi phí khác nhau và mức sẵn sàng chi trả khác nhau.
Một mô hình phổ biến là tăng nhỏ cho mang đi, có lẽ mười đến mười lăm phần trăm, để bù đắp bao bì và công sức biên cho việc đóng gói và bàn giao. Một số nhà hàng đảo ngược điều này và cung cấp giảm giá nhỏ cho mang đi vì họ tiết kiệm được chi phí rửa bát và vòng quay bàn. Dù thế nào, hệ thống menu cần hỗ trợ trường giá riêng cho mỗi món, khác với giá ăn tại chỗ, chỉ xuất hiện khi khách đặt hàng để lấy đi.
Các món cũng cần cờ khả dụng riêng cho mang đi. Một số món không chịu được vận chuyển tốt. Bánh soufflé, carpaccio tinh tế, tráng miệng có nhiều thành phần được trang trí — không cái nào thuộc menu mang đi. Chúng phải giữ trên menu ăn tại chỗ nhưng bị ẩn khỏi danh sách mang đi chỉ bằng một công tắc, không phải bằng cách duy trì hai menu song song.
Xác nhận đơn hàng hai giai đoạn
Lỗi kinh điển là đối xử với đơn mang đi như thanh toán trang web, nơi khách xác nhận mọi thứ ở cuối. Trong thực tế điều này thất bại vì bước thanh toán là phần chậm nhất, dễ xảy ra lỗi nhất. Chuyển khoản ngân hàng mất thời gian. Khách có thể nhập sai số tiền. Biên lai có thể không rõ ràng. Nếu đơn hàng bị khóa trước khi xác nhận thanh toán, bếp bắt đầu nấu thức ăn mà nhà hàng có thể không bao giờ được trả tiền.
Quy trình tốt hơn là bàn giao hai giai đoạn. Giai đoạn một: khách đặt đơn hàng. Hệ thống ghi lại các món, tính tổng và hiển thị cho họ tổng rõ ràng bằng cùng loại tiền tệ họ đang thanh toán. Giai đoạn hai: khách tải biên lai thanh toán. Cho đến khi nhà hàng xác nhận thủ công biên lai là hợp lệ, đơn hàng ở trạng thái "đang chờ xác nhận." Bếp không bắt đầu. Huy hiệu trạng thái của khách nói "Đang chờ nhà hàng xác nhận thanh toán" để họ biết bóng đang ở phía bạn, không phải của họ.
Điều này nghe có vẻ chậm. Trong thực tế xác nhận của nhân viên mất mười giây — mở bảng điều khiển, liếc nhìn ảnh biên lai, nhấn nút. Bếp thấy đơn hàng ngay khi thanh toán được xác nhận, không phải trước đó — đây chính xác là thời điểm đúng.
Tải biên lai thanh toán không bị hỏng
Chế độ thất bại phổ biến nhất cho tải biên lai là quyền truy cập. Điện thoại khách sử dụng địa chỉ IP ngẫu nhiên. Kích thước hình ảnh khác nhau từ 200 KB đến 10 MB. Một số khách chụp màn hình ứng dụng ngân hàng, số khác chụp ảnh biên lai in bằng máy ảnh, số khác dán hình ảnh được chuyển tiếp từ ứng dụng chat. Hệ thống tải lên phải hấp thụ tất cả điều này mà không báo lỗi.
Một số quy tắc thực tế. Thứ nhất, chấp nhận nhiều định dạng hình ảnh: JPEG, PNG và WebP bao gồm hầu hết mọi máy ảnh điện thoại và công cụ chụp màn hình. Thứ hai, sử dụng URL tải lên đã ký sẵn hết hạn trong vài phút, để quá trình tải lên xảy ra trực tiếp từ điện thoại của khách đến bộ nhớ của bạn mà không có máy chủ của bạn ở giữa. Thứ ba, xác thực loại tệp phía máy chủ trước khi cấp URL. Thứ tư, lưu biên lai dưới đường dẫn có tên rõ ràng để bạn có thể kiểm tra sau nếu thanh toán bị tranh chấp.
Giao diện người dùng phía khách phải là một nút lớn có nhãn "Tải biên lai thanh toán," không phải biểu mẫu nhiều bước. Sau khi tải lên, hiển thị hình thu nhỏ của biên lai trở lại cho khách với tùy chọn "Thay thế" trong trường hợp họ tải lên ảnh chụp màn hình sai. Huy hiệu trạng thái của họ phải ngay lập tức chuyển sang "Đang chờ nhà hàng xác nhận" để họ biết tải lên đã thành công.
Mã tham chiếu để nhận hàng
Khi khách đến lấy hàng, bạn cần cách nhanh để khớp điện thoại của họ với đơn hàng trên màn hình của bạn. Gọi to số hàng đợi hoạt động trong nhà hàng yên tĩnh nhưng thất bại trong tiệm trà sữa ồn ào với năm số 12 đang xếp hàng.
Mã tham chiếu ngắn, sáu ký tự từ bộ ký tự không gây nhầm lẫn, giải quyết điều này. Tạo nó phía máy chủ khi đặt hàng. Hiển thị nó trên điện thoại của khách cùng với số hàng đợi. Hiển thị cùng mã trong bảng điều khiển nhân viên. Khi khách đến, họ cho thấy điện thoại, bạn so sánh mã và bàn giao túi. Toàn bộ trao đổi mất ba giây và không bao giờ phụ thuộc vào tên được gọi to.
Mã tham chiếu cũng hoạt động như chống gian lận. Khách không thể nhận là "số 42" mà không trình bày mã đi kèm với số 42. Hai người ngẫu nhiên không thể trùng trên cùng một mã trong cùng một ngày trong bất kỳ tình huống nào có thể xảy ra.
Đối soát cuối ngày
Doanh thu mang đi cần đối soát với chuyển khoản ngân hàng hàng ngày. Cách đơn giản nhất để làm điều này là chế độ xem Lịch sử trong bảng điều khiển hàng đợi liệt kê mỗi đơn hàng được đánh dấu Đã phục vụ trong một ngày nhất định, với số hàng đợi, mã tham chiếu, thời gian, tổng cộng và liên kết đến ảnh biên lai. Chọn một ngày, xem danh sách, xem tổng ngày, đối chiếu với sao kê ngân hàng. Năm phút mỗi ngày, lý tưởng là một phần của quy trình đóng cửa.
Lịch sử cần xử lý múi giờ chính xác. Nhà hàng ở Bangkok đóng cửa lúc nửa đêm giờ địa phương nên thấy tất cả đơn hàng cho ngày lịch đó được nhóm lại với nhau, không bị chia cắt qua nửa đêm UTC ở giữa ca bữa tối. Hệ thống phải biết quốc gia của nhà hàng và sử dụng múi giờ địa phương để nhóm.
Phải làm gì khi có sự cố
Trong bất kỳ quy trình thực tế nào, các trường hợp ngoại lệ xảy ra. Khách thanh toán số tiền sai. Biên lai không đọc được. Khách không đến lấy hàng. Bếp hết món giữa đặt hàng và xác nhận.
Đối với mỗi trường hợp này, hãy thiết kế một con đường rõ ràng. Số tiền sai: nhân viên mở đơn hàng, thấy vấn đề và hoặc chấp nhận thanh toán một phần với ghi chú hoặc yêu cầu khách thanh toán lại. Biên lai không đọc được: nhân viên nhắn tin cho khách (nếu bạn có số điện thoại của họ) hoặc đơn giản là không xác nhận; khách nhận thấy trạng thái của mình bị kẹt và tải lại. Không đến lấy: mục hàng đợi ở trong trạng thái "đang chuẩn bị" cho đến khi được đánh dấu thủ công là Đã phục vụ hoặc Đã hủy, lúc đó nó rời khỏi danh sách hoạt động.
Hết hàng giữa đặt hàng và xác nhận là trường hợp khó chịu nhất. Câu trả lời gọn gàng nhất là hoàn tiền nhanh vào cùng tài khoản ngân hàng của khách, với lời xin lỗi và ghi chú. Hệ thống phải làm cho điều này dễ dàng: nút Hủy trên đơn hàng mà bạn có thể sử dụng sau khi xem biên lai, với điện thoại của khách ngay lập tức phản ánh việc hủy.
Đừng tối ưu hóa con đường tốt quá mức
Sự cám dỗ khi thiết kế quy trình mang đi là giả định mọi đơn hàng đều diễn ra hoàn hảo và thiết kế giao diện phù hợp. Đây là bẫy. Hầu hết đơn hàng đều diễn ra hoàn hảo, nhưng những cái tệ tiêu tốn thời gian không tương xứng và tạo ra nhiều công việc dịch vụ khách hàng nhất. Xây dựng quy trình xung quanh các trường hợp xấu trước, và các trường hợp tốt sẽ tự lo lấy.
Huy hiệu trạng thái rõ ràng mà khách có thể đọc trong ba giây. Bảng điều khiển hiển thị mọi thứ nhân viên cần chỉ trong một cái nhìn. Mã tham chiếu để bàn giao nhanh. Chế độ xem lịch sử để đối soát cuối ngày. Cộng thêm kỳ vọng mặc định rằng một số đơn hàng sẽ cần can thiệp thủ công, và rằng hệ thống làm cho việc can thiệp đó dễ dàng thay vì không thể. Làm đúng những điều đó và bạn có hoạt động mang đi có khả năng mở rộng.
