테이크아웃은 다이닝과 다른 비즈니스입니다. 고객은 앉지 않습니다. 테이블에 주차할 곳도 없습니다. 고객은 두 가지를 알고 싶어합니다. 음식이 언제 준비되고, 어떻게 결제하는지. 이 두 가지 질문을 가로막는 모든 것은 마찰이며, 마찰은 더 매끄러운 프로세스를 가진 경쟁업체에 주문을 빼앗깁니다.
지난 몇 년간 테이크아웃의 플레이북은 전화 주문과 방문 카운터에서 확장 가능한 QR-대기열 워크플로우로 이동했습니다. 고객이 대기 번호를 받고, 자신의 휴대폰으로 주문을 만들고, 은행 이체 영수증을 업로드하여 결제하고, 번호가 호출될 때 픽업합니다. 전체 과정이 브라우저에서 실행되며, 앱도, 호스트 스테이션도, 헤드셋도 없습니다.
이 글은 이 워크플로우가 실제 레스토랑에서 작동하게 하는 실질적인 결정들을 다룹니다.
포장 가격 분리
첫 번째 결정은 테이크아웃 가격이 다이닝과 동일해야 하는지입니다. 많은 나라에서 답은 아니오입니다. 다이닝에는 접시, 유리잔, 테이블 서비스, 경험이 포함됩니다. 테이크아웃에는 포장재와 고객이 다른 곳에서 먹을 것이라는 가정이 포함됩니다. 비용 구조가 다르고, 지불 의향도 다릅니다.
일반적인 패턴은 포장재와 포장 및 인계에 필요한 추가 인건비를 충당하기 위해 테이크아웃에 소폭, 아마도 10~15퍼센트의 할증을 적용하는 것입니다. 일부 레스토랑은 설거지와 테이블 회전을 절감할 수 있기 때문에 소폭의 테이크아웃 할인을 제공하기도 합니다. 어떤 방식이든 메뉴 시스템은 고객이 픽업 주문을 할 때만 나타나는 다이닝 가격과 별도로 항목당 별도 가격 필드를 지원해야 합니다.
항목에는 또한 테이크아웃을 위한 별도의 가용성 플래그가 필요합니다. 일부 요리는 이동에 잘 견디지 못합니다. 수플레, 섬세한 카르파초, 다성분 플레이팅 디저트, 이것들 중 어느 것도 테이크아웃 메뉴에 속하지 않습니다. 두 개의 병렬 메뉴를 유지하지 않고 단일 토글로 다이닝 메뉴에 남기면서 테이크아웃 목록에서 숨겨야 합니다.
2단계 주문 확인
고전적인 실수는 테이크아웃 주문을 웹사이트 결제처럼 취급하는 것으로, 고객이 마지막에 모든 것을 확정합니다. 실제로 이것은 결제 단계가 가장 느리고 오류가 발생하기 쉬운 부분이기 때문에 실패합니다. 은행 이체는 시간이 걸립니다. 고객이 금액을 잘못 입력할 수 있습니다. 영수증이 불명확할 수 있습니다. 결제가 확인되기 전에 주문이 확정되면 레스토랑은 결코 결제받지 못할 음식을 주방이 조리하기 시작합니다.
더 나은 워크플로우는 2단계 인계입니다. 1단계: 고객이 주문을 합니다. 시스템이 항목을 기록하고, 총액을 계산하고, 결제 통화로 명확한 총액을 보여 줍니다. 2단계: 고객이 결제 영수증을 업로드합니다. 레스토랑이 수동으로 영수증이 유효한지 확인할 때까지 주문은 "확인 대기 중" 상태에 있습니다. 주방은 시작하지 않습니다. 고객의 상태 배지는 "레스토랑의 결제 확인을 기다리는 중"이라고 표시되어 공이 자신의 코트가 아닌 레스토랑의 코트에 있다는 것을 알 수 있습니다.
느리게 들립니다. 실제로 직원 확인은 10초 걸립니다. 대시보드를 열고, 영수증 이미지를 훑어보고, 버튼을 탭합니다. 주방은 결제가 확인되는 순간, 즉 정확히 올바른 순간에 주문을 봅니다.
끊기지 않는 결제 영수증 업로드
영수증 업로드에서 가장 일반적인 실패 방식은 권한입니다. 고객 휴대폰은 무작위 IP 주소를 사용합니다. 이미지 크기는 200KB에서 10MB까지 다양합니다. 일부 고객은 은행 앱을 스크린샷 찍고, 다른 이들은 카메라로 인쇄된 영수증을 촬영하고, 다른 이들은 채팅에서 전달된 이미지를 붙여넣습니다. 업로드 시스템은 오류를 뱉지 않고 이 모든 것을 흡수해야 합니다.
몇 가지 실용적인 규칙이 있습니다. 첫째, 여러 이미지 형식을 허용하십시오. JPEG, PNG, WebP는 사실상 모든 휴대폰 카메라와 스크린샷 도구를 커버합니다. 둘째, 몇 분 후에 만료되는 사전 서명 업로드 URL을 사용하여 업로드가 중간에 서버 없이 고객의 휴대폰에서 직접 스토리지로 이루어지도록 하십시오. 셋째, URL을 발급하기 전에 서버 측에서 파일 유형을 검증하십시오. 넷째, 나중에 결제 분쟁이 생길 때 감사할 수 있도록 명확하게 네임스페이스된 경로 아래에 영수증을 저장하십시오.
고객 대면 UI는 "결제 영수증 업로드"라고 레이블된 큰 버튼 하나여야 하며, 다단계 양식이 아닙니다. 업로드 후, 잘못된 스크린샷을 업로드한 경우를 위한 "교체" 옵션과 함께 고객에게 영수증의 썸네일을 돌려 보여 주십시오. 상태 배지는 업로드가 작동했음을 알 수 있도록 즉시 "레스토랑의 확인을 기다리는 중"으로 전환되어야 합니다.
픽업을 위한 참조 코드
고객이 픽업하러 도착할 때, 화면에 있는 주문에 휴대폰을 빠르게 맞추는 방법이 필요합니다. 5번 번호가 5명 줄 서 있는 시끄러운 버블티 상점에서는 대기 번호를 부르는 것이 실패합니다.
혼동 없는 문자 집합의 짧은 참조 코드, 6자리가 이를 해결합니다. 주문 배치 시 서버 측에서 생성하십시오. 대기 번호와 함께 고객의 휴대폰에 표시하십시오. 직원 대시보드에 같은 코드를 표시하십시오. 고객이 도착하면 휴대폰을 보여 주고, 코드를 비교하고, 봉지를 건네줍니다. 전체 교환은 3초 걸리며 외쳐진 이름에 의존하지 않습니다.
참조 코드는 또한 사기 방지 역할을 합니다. 고객은 42번에 해당하는 코드를 보여 주지 않고 "저는 42번입니다"라고 주장할 수 없습니다. 같은 날 같은 코드에서 두 명의 무작위 사람이 충돌하는 것은 어떤 그럴듯한 시나리오에서도 불가능합니다.
영업 마감 정산
테이크아웃 수익은 매일 은행 이체와 정산해야 합니다. 이를 수행하는 가장 간단한 방법은 해당 날짜에 서빙으로 표시된 모든 주문을 나열하는 대기열 대시보드의 히스토리 보기입니다. 대기 번호, 참조 코드, 시간, 총액, 영수증 이미지 링크가 있습니다. 날짜를 선택하고, 목록을 보고, 일일 총액을 보고, 은행 명세서와 교차 참조합니다. 이상적으로는 마감 루틴의 일부로 하루 5분입니다.
히스토리는 시간대를 올바르게 처리해야 합니다. 자정에 영업을 마치는 방콕의 레스토랑은 저녁 서비스 중간에 UTC 자정으로 분리되지 않고 해당 달력 날짜의 모든 주문을 함께 그룹화해야 합니다. 시스템은 레스토랑의 국가를 알고 그룹화에 현지 시간대를 사용해야 합니다.
문제가 발생했을 때 대처 방법
실제 워크플로우에서는 예외 케이스가 발생합니다. 고객이 잘못된 금액을 결제합니다. 영수증을 읽을 수 없습니다. 고객이 픽업하러 오지 않습니다. 주문과 확인 사이에 주방이 항목 재고를 소진합니다.
각각에 대해 명확한 경로를 설계하십시오. 잘못된 금액: 직원이 주문을 열고, 문제를 확인하고, 메모와 함께 부분 결제를 수락하거나 고객에게 재결제를 요청합니다. 읽을 수 없는 영수증: 직원이 고객에게 메시지를 보내거나(전화번호가 있는 경우) 단순히 확인하지 않습니다. 고객은 상태가 고착되어 있음을 알아차리고 다시 업로드합니다. 노쇼: 대기열 항목은 수동으로 서빙 또는 취소로 표시될 때까지 "준비 중"에 남아 있고, 그 때 활성 목록에서 제거됩니다.
주문과 확인 사이의 재고 소진이 가장 고통스러운 경우입니다. 가장 깔끔한 답은 사과 메모와 함께 고객의 동일한 은행 계좌로 빠른 환불입니다. 시스템은 이를 쉽게 해야 합니다. 영수증을 확인한 후 사용할 수 있는 주문의 취소 버튼으로, 고객의 휴대폰이 즉시 취소를 반영합니다.
행복한 경로를 너무 공격적으로 최적화하지 마십시오
테이크아웃 흐름을 설계할 때의 유혹은 모든 주문이 완벽하게 진행된다고 가정하고, 그에 따라 UI를 설계하는 것입니다. 이것은 함정입니다. 대부분의 주문은 완벽하게 진행되지만, 나쁜 주문은 불균형적인 시간을 소비하고 가장 많은 고객 서비스 작업을 만들어 냅니다. 먼저 나쁜 케이스를 중심으로 워크플로우를 구축하면 좋은 케이스는 스스로 처리됩니다.
고객이 3초 만에 읽을 수 있는 명확한 상태 배지. 직원이 한눈에 필요한 모든 것을 보여 주는 대시보드. 빠른 인계를 위한 참조 코드. 영업 마감 정산을 위한 히스토리 보기. 그리고 일부 주문이 수동 개입이 필요할 것이라는 기본 기대치, 그리고 시스템이 그 개입을 불가능하게 만들기보다 쉽게 만든다는 것. 이것들을 올바르게 구현하면 확장 가능한 테이크아웃 운영이 됩니다.
