OpenTable의 송장을 보면서 몸을 웅크리는 레스토랑 사장들을 지켜봤다. 한 달에 1,000명을 서빙하는 바는 손님들이 "예약" 버튼을 클릭할 수 있도록 하는 데만 연간 $18,000 이상을 잃고 있다. 그건 라인 요리사의 급여다. 그건 파티오 리노베이션이다. 그건 매달 당신의 문을 나가는 돈이다. 그것도 당신의 고객 데이터를 사용해 다른 레스토랑을 당신의 손님들에게 마케팅하는 플랫폼으로.

좋은 소식이 있다. 커스텀 예약 엔진을 구축하는 것은 5년 전만큼 엄청난 작업이 아니다. 현대적인 웹 프레임워크, 호스팅 데이터베이스, 그리고 몇 가지 똑똑한 통합을 통해 당신의 자체 도메인에서 실행할 수 있는 프로덕션 준비 예약 시스템을 OpenTable에 연간 지불하는 금액의 일부로 보유할 수 있다. 나는 레스토랑과 바 클라이언트를 위해 이 중 여러 개를 구축하는 것을 도왔으며, 정확히 어떻게 작동하는지 당신에게 설명하겠다.

OpenTable 수수료 없이 커스텀 레스토랑 예약 엔진 구축

목차

2025년 OpenTable의 실제 비용

실제 숫자를 테이블 위에 올려놓자 (말장난 의도). 2025년 OpenTable의 가격 책정은 다음과 같다:

  • 설정 수수료: $1,200+
  • 월간 구독: $249/월
  • 커버당 수수료: 자신의 사이트를 통해 만들어진 예약의 경우 $1.00, OpenTable 네트워크를 통해 만들어진 예약의 경우 $2.50
  • 월 평균 1,000명 커버하는 레스토랑의 연간 비용: 대략 $15,000-$18,000/년

커버당 모델이 문제다. 더 바빠질수록 더 많이 낸다. 그것은 당신의 자신의 성공에 대한 세금이다. 정말 따끔한 부분은 다음과 같다: OpenTable은 고객 관계 데이터를 소유한다. 그들은 손님의 식사 이력을 사용해 경쟁사를 제안할 것이다. 본질적으로 당신은 당신을 상대로 사용하는 데이터베이스를 구축하기 위해 중개자에게 돈을 지불하는 것이다.

단일 지점 바 또는 레스토랑의 경우 그 연간 $18K는 가혹하다. 다중 지점 그룹의 경우? 그에 따라 곱하라.

먼저 고려할 가치가 있는 기성 대안

커스텀 구축에 커밋하기 전에 기존 플랫폼이 당신의 문제를 해결하는지 정직하게 생각해보자. 시장은 균일 수수료 및 무료 모델로 급격히 변했다. 2025년 현황은 다음과 같다:

플랫폼 무료 계층 유료 가격 책정 커버당 수수료 Google 통합 주요 한계
Resos 월 25건 예약 $24/월 (정액) 없음 예 무료 계층이 너무 작음
GloriaFood 무제한 예약 무료 코어 + 추가 기능 없음 제한됨 최소 사용자 정의
Tablesit 월 500건 예약 미공개 없음 예 무료 계층에 SMS 없음
Anolla 기본 기능 모듈형 추가 기능 없음 예 무료가 주요 모듈 부족
Sagenda 완전 무료 N/A 없음 없음 실제 테이블 관리 없음
Tableo 100명 ~$75/월 없음 예 (Reserve) 무료 기능 제한
Tablein N/A 정액 월간 없음 예 더 작은 장소를 대상으로 함
Eveve N/A $150-$300/월 없음 예 가격은 위치에 따라 다름

월 500건 미만의 예약을 하는 작은 바라면 Tablesit 또는 Resos가 정말로 필요한 전부일 수 있다. GloriaFood는 온라인 주문도 원한다면 견고하다. 이 도구들은 놀랍도록 개선되었다.

하지만 그들 모두 일반적인 한계를 공유한다: 당신은 여전히 다른 사람의 플랫폼에 있고, 사용자 정의 옵션은 제한되어 있으며, 기존 기술 스택과 깊게 통합할 수 없고, 인프라를 소유하지 않는다. 많은 레스토랑의 경우 괜찮다. 다른 곳의 경우는 아니다.

OpenTable 수수료 없이 커스텀 레스토랑 예약 엔진 구축 - 아키텍처

커스텀 구축이 의미 있을 때

커스텀 예약 시스템이 의미 있을 때:

  • 당신이 다중 지점 그룹이고 위치별 논리를 가진 중앙집중식 관리가 필요한 경우
  • 당신이 기존 웹사이트를 가지고 현대적 스택(Next.js, Astro 등)으로 구축했고 예약 경험이 네이티브처럼 느껴지길 원하며, 2014년 iframe 같지 않은 경우
  • 당신이 커스텀 비즈니스 로직이 필요한 경우 -- 바 vs. 다이닝룸을 위한 다른 예약 규칙, 이벤트 기반 가용성, 메뉴와 연결된 시즈널 예약 슬롯
  • 당신이 당신의 데이터를 완전히 소유하길 원하는 경우, 제3자 액세스 없이
  • 당신이 OpenTable에 연 $10K 이상을 지출하고 있으며 커스텀 구축이 12-18개월 내에 비용을 뽑을 수 있는 경우
  • 당신이 기존 POS, CRM, 또는 마케팅 도구와의 통합을 원하는 경우 기성 플랫폼은 지원하지 않음

그 중 세 개 이상이 적용된다면 계속 읽자. 우리는 이러한 종류의 시스템을 헤드리스 CMS 개발 작업의 일부로 정기적으로 구축하고, ROI 대화는 거의 항상 간단하다.

레스토랑 예약 엔진의 아키텍처

현대적 커스텀 예약 엔진을 위해 내가 권장하는 높은 수준의 아키텍처는 다음과 같다:

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│  Frontend Widget │────▶│   API Layer      │────▶│   Database      │
│  (React/Astro)   │     │   (Node/Express)  │     │   (PostgreSQL)  │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │                        │                        │
        │                        ├──▶ Twilio (SMS)        │
        │                        ├──▶ SendGrid (Email)    │
        │                        ├──▶ Stripe (Deposits)   │
        │                        ├──▶ Google Calendar      │
        │                        └──▶ POS Integration     │
        │                                                  │
┌─────────────────┐                               ┌─────────────────┐
│  Admin Dashboard │──────────────────────────────▶│  Same API/DB    │
│  (Staff portal)  │                               │                 │
└─────────────────┘                               └─────────────────┘

프론트엔드 위젯은 당신의 레스토랑 웹사이트에 산다. API는 모든 비즈니스 로직을 처리한다 -- 가용성 확인, 충돌 해결, 알림 트리거. PostgreSQL는 모든 것을 저장한다: 예약, 플로어 플랜, 고객 프로필, 환경 설정. 외부 서비스는 당신이 처음부터 구축하길 원치 않는 것들을 처리한다.

프론트엔드 위젯 구축

예약 위젯은 당신의 손님이 상호작용하는 것이다. 빠르고, 모바일 우선이어야 하며 (레스토랑 예약의 70% 이상은 휴대폰에서 발생), 매우 간단해야 한다.

핵심 예약 폼을 위한 단순화된 React 컴포넌트는 다음과 같다:

import { useState } from 'react';

export function BookingWidget({ restaurantId }: { restaurantId: string }) {
  const [date, setDate] = useState('');
  const [time, setTime] = useState('');
  const [partySize, setPartySize] = useState(2);
  const [availableSlots, setAvailableSlots] = useState([]);

  async function checkAvailability() {
    const res = await fetch(`/api/availability`, {
      method: 'POST',
      body: JSON.stringify({ restaurantId, date, partySize }),
    });
    const data = await res.json();
    setAvailableSlots(data.slots);
  }

  async function confirmBooking() {
    const res = await fetch(`/api/reservations`, {
      method: 'POST',
      body: JSON.stringify({
        restaurantId, date, time, partySize,
        // guest details collected in a previous step
      }),
    });
    // Handle confirmation, redirect to success page
  }

  return (
    <div className="booking-widget">
      <input type="date" onChange={(e) => setDate(e.target.value)} />
      <select onChange={(e) => setPartySize(Number(e.target.value))}>
        {[1,2,3,4,5,6,7,8].map(n => (
          <option key={n} value={n}>{n} {n === 1 ? 'guest' : 'guests'}</option>
        ))}
      </select>
      <button onClick={checkAvailability}>Check Availability</button>
      
      {availableSlots.map(slot => (
        <button key={slot.time} onClick={() => { setTime(slot.time); confirmBooking(); }}>
          {slot.time}
        </button>
      ))}
    </div>
  );
}

이것은 명백히 단순화된 것이다 -- 당신은 적절한 폼 검증, 로딩 상태, 에러 처리, 그리고 손님 이름, 이메일, 전화, 특별 요청을 수집하는 다단계 흐름을 원할 것이다. 하지만 핵심 상호작용은 간단하다: 날짜를 선택하고, 그룹 크기를 선택하고, 사용 가능한 시간을 보고, 하나를 예약한다.

Next.js에서 실행하는 레스토랑의 경우 (우리는 광범위하게 구축한다 -- Next.js 개발 역량 참조), 위젯은 가용성 데이터를 미리 가져올 수 있는 서버 컴포넌트가 된다. Astro로 구축된 정적 사이트의 경우, 나머지 페이지를 최대 성능을 위해 정적으로 생성하면서 대화형 예약 폼을 위해 클라이언트 측 아일랜드를 사용할 것이다.

백엔드: 가용성 엔진 및 충돌 해결

이것이 진정한 복잡성이 있는 곳이다. 가용성 엔진은 한 가지 질문을 빠르고 정확하게 답해야 한다: "이 날짜, 시간, 그룹 크기가 주어졌을 때, 어떤 테이블을 이용할 수 있는가?"

핵심 데이터베이스 스키마는 다음과 같다:

CREATE TABLE tables (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  restaurant_id UUID REFERENCES restaurants(id),
  label VARCHAR(50),          -- "Table 1", "Bar Seat 3"
  zone VARCHAR(50),           -- "patio", "bar", "main_dining"
  min_capacity INT NOT NULL,
  max_capacity INT NOT NULL,
  is_active BOOLEAN DEFAULT true,
  position_x FLOAT,           -- for floor plan rendering
  position_y FLOAT
);

CREATE TABLE reservations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  restaurant_id UUID REFERENCES restaurants(id),
  table_id UUID REFERENCES tables(id),
  guest_name VARCHAR(255) NOT NULL,
  guest_email VARCHAR(255),
  guest_phone VARCHAR(50),
  party_size INT NOT NULL,
  date DATE NOT NULL,
  start_time TIME NOT NULL,
  end_time TIME NOT NULL,       -- calculated from dining duration
  status VARCHAR(20) DEFAULT 'confirmed',  -- confirmed, seated, completed, cancelled, no_show
  notes TEXT,
  deposit_amount DECIMAL(10,2) DEFAULT 0,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE booking_rules (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  restaurant_id UUID REFERENCES restaurants(id),
  zone VARCHAR(50),
  day_of_week INT,              -- 0=Sunday, 6=Saturday
  first_slot TIME,
  last_slot TIME,
  slot_interval_minutes INT DEFAULT 15,
  dining_duration_minutes INT DEFAULT 90,
  buffer_minutes INT DEFAULT 15,
  max_covers_per_slot INT
);

가용성 확인 쿼리는 다음을 만족하는 테이블을 찾아야 한다:

  1. 그룹 크기에 맞음
  2. 요청된 시간 창 동안 (버퍼 포함) 이미 예약되지 않음
  3. 그 날짜/시간에 활성 존에 있음
SELECT t.id, t.label, t.zone
FROM tables t
WHERE t.restaurant_id = $1
  AND t.is_active = true
  AND t.min_capacity <= $2   -- party size
  AND t.max_capacity >= $2
  AND t.id NOT IN (
    SELECT r.table_id FROM reservations r
    WHERE r.date = $3
      AND r.status NOT IN ('cancelled', 'no_show')
      AND r.start_time < ($4::TIME + ($5 || ' minutes')::INTERVAL)  -- requested end
      AND r.end_time > ($4::TIME - ($6 || ' minutes')::INTERVAL)    -- buffer before
  )
ORDER BY t.max_capacity ASC;  -- prefer smallest suitable table

마지막 ORDER BY는 중요하다 -- 당신은 항상 그룹에 적합한 가장 작은 테이블을 할당하고 싶다. 금요일 저녁 서비스 동안 부부를 6인 테이블에 앉히는 것은 돈을 잃는 좋은 방법이다.

예약 사이의 버퍼 시간이 중요하다. 나는 일반적으로 캐주얼 장소에는 15분, 파인 다이닝에는 30분을 권장한다. 이것은 테이블 정리, 초기화, 그리고 불가피하게 디저트에 대해 머물러 있는 그룹을 설명한다.

테이블 관리 및 플로어 플랜

직원은 한눈에 플로어를 보아야 한다. 관리자 대시보드는 SVG 또는 HTML Canvas를 사용하여 대화형 플로어 플랜을 렌더링해야 한다. 각 테이블은 실제 플로어 플랜의 배경 이미지 위에 위치한 드래그 가능한 요소다.

관리자 인터페이스의 경우, 나는 보통 이것을 별도의 Next.js 앱으로 구축하거나 (또는 역할 기반 액세스를 가진 메인 사이트 내의 보호된 경로), 역할 기반 액세스를 가진다. 호스트는 오늘 밤의 예약을 보고 드래그 앤 드롭으로 테이블을 재할당할 수 있다. 매니저는 분석과 구성을 본다.

테이블 위치를 데이터베이스에서 position_x 및 position_y 부동소수점으로 저장하면 플로어 플랜이 완전히 사용자 정의 가능하다. 당신의 실제 레스토랑 레이아웃의 사진을 가져오고, 위에 테이블을 배치하면, 당신의 물리적 공간을 반영하는 시각적 관리 도구를 가지고 있다.

알림, 리마인더, 노쇼 감소

자동 알림은 선택사항이 아니다 -- 그들은 당신이 노쇼를 20-30%로 줄이는 방법이다. 알림 흐름은 다음과 같다:

  1. 인스턴트 확인 -- 예약이 만들어지자마자 이메일 + SMS
  2. 24시간 리마인더 -- SMS는 손님에게 확인 또는 취소를 요청하라
  3. 2시간 리마인더 -- 선택 사항, 디너 서비스에 잘 작동
  4. 방문 후 팔로우 업 -- 그들을 감사히 여기는 이메일, 리뷰 요청, 다시 돌아오기 초대

Twilio는 미국에서 메시지당 대략 $0.0079의 SMS를 처리한다. SendGrid의 무료 계층은 일 100 이메일을 포함하며, 이는 대부분의 단일 지점 레스토랑에 충분하다. 규모에 따라도 당신은 두 서비스 모두에 대해 월 $20-50을 보고 있다.

리마인더 시스템을 위한 간단한 크론 작업 패턴은 다음과 같다:

// Run every hour via cron
async function sendReminders() {
  const tomorrow = new Date();
  tomorrow.setDate(tomorrow.getDate() + 1);
  
  const upcomingReservations = await db.query(
    `SELECT r.*, g.phone, g.email 
     FROM reservations r
     WHERE r.date = $1 
       AND r.status = 'confirmed'
       AND r.reminder_sent = false`,
    [tomorrow.toISOString().split('T')[0]]
  );
  
  for (const res of upcomingReservations.rows) {
    await twilioClient.messages.create({
      body: `Reminder: Your reservation at ${RESTAURANT_NAME} tomorrow at ${res.start_time} for ${res.party_size}. Reply C to confirm or X to cancel.`,
      to: res.phone,
      from: TWILIO_NUMBER,
    });
    
    await db.query(
      'UPDATE reservations SET reminder_sent = true WHERE id = $1',
      [res.id]
    );
  }
}

결제 보증금 및 취소 정책

고수요 슬롯(금요일/토요일 저녁, 브런치, 휴일 이벤트)의 경우, 예약 시간에 보증금을 수집하면 노쇼를 극적으로 줄인다. Stripe는 이것을 하찮게 만든다.

나는 잘 작동하는 것을 본 전형적인 보증금 구조:

  • 표준 저녁 예약의 경우 $10-25 per person
  • 특별 이벤트, 테이스팅 메뉴, 또는 prix fixe의 경우 전체 선불
  • 비수기 슬롯 (화요일 점심)의 경우 보증금 없음 (당신은 0 마찰을 원한다)

보증금은 청구서에 적용되거나 손님이 노쇼하거나 윈도우 내에서 취소한 경우 몰수된다 (보통 24-48시간). Stripe의 payment intents API는 hold-and-capture 흐름을 깔끔하게 처리한다.

Google Reserve 통합

여기 대부분의 커스텀 구축이 놓치는 기능이 있고, 그것은 큰 거래다. Google Reserve는 손님이 Google 검색 및 Google 지도에서 직접 예약할 수 있게 한다. 누군가 "near me 이탈리아 레스토랑"을 검색하고 당신의 리스팅을 보면, 그들은 당신의 웹사이트에 방문하지 않고 예약할 수 있다.

Google Reserve와의 통합은 승인된 예약 파트너가 되거나 이미 그러한 플랫폼 (Resos, Tableo 등)을 사용하는 것을 요구한다. 완전히 커스텀 구축의 경우, Google Reserve API 사양을 구현해야 하며, 여기에는 Google 시스템이 소비할 수 있는 특정 형식으로 가용성 데이터를 노출하는 것이 포함된다.

이것은 구축 대 구매 결정이 실제가 되는 하나의 영역이다. Google Reserve 트래픽이 당신의 레스토랑에 중요하다면 (그리고 대부분의 도시 레스토랑의 경우, 절대로 중요하다), 이미 이러한 통합을 가진 플랫폼과의 파트너십이 완전히 커스텀으로 구축하는 것보다 더 의미가 있을 수 있다. 당신은 여전히 자신의 웹사이트를 위한 커스텀 위젯을 구축할 수 있으면서 Google 채널을 위해 Resos 또는 유사한 것을 사용할 수 있다.

배포, 호스팅, 지속적 비용

Next.js 기반 예약 엔진의 경우, Vercel은 명백한 호스팅 선택이다 -- 무료 계층은 대부분의 단일 레스토랑 트래픽을 쉽게 처리한다. 데이터베이스의 경우, Supabase 또는 Neon.tech는 관대한 무료 PostgreSQL 계층을 제공한다. 스케일하거나 더 많은 안정성이 필요할 때, 당신은 다음을 보고 있다:

  • Vercel Pro: $20/월
  • Supabase Pro: $25/월
  • Twilio SMS: ~$20-40/월 (볼륨에 따라)
  • SendGrid: 대부분의 볼륨에 대해 무료
  • Stripe: 2.9% + 보증금 거래당 $0.30 (월간 수수료 없음)
  • Domain/SSL: 당신은 이미 이것을 가지고 있다

총 월간 호스팅 비용: $65-85/월. OpenTable의 $249/월과 비교하자, 이것은 커버당 수수료 이전이다.

실제 비용 비교: 커스텀 vs. OpenTable vs. 대안

월 1,000명 커버를 하는 레스토랑에 대한 숫자를 실행하자:

솔루션 1년차 비용 2년차 비용 3년 총합 당신이 데이터를 소유하는가?
OpenTable $18,000+ (설정 + 월간 + 커버당) $15,000+ $48,000+ 아니요
Resos 유료 $288 $288 $864 부분적으로
Tableo 유료 ~$900 ~$900 $2,700 부분적으로
커스텀 구축 $8,000-20,000 (개발) + $800 (호스팅) $800 (호스팅) $9,600-21,600 예, 100%
Tablesit 무료 $0 $0 $0 부분적으로

높은 끝에서의 커스텀 구축($20K 개발 비용)은 OpenTable과 비교해 13-16개월에 수익분기점을 달성한다. 낮은 끝에서, 당신은 6개월까지 도달한다. 그 후, 그것은 순 절감이다 -- 연간 $15,000+ 당신의 비즈니스에 머물러 있다.

개발 비용은 복잡성에 따라 다르다. 이메일 확인 및 간단한 관리 패널이 있는 기본 예약 위젯은 낮은 끝에 앉는다. 플로어 플랜 관리, 보증금 수집, POS 통합, 다중 위치 지원, 분석을 가진 완전히 기능하는 시스템은 높은 끝을 향해 푼다.

당신의 특정 상황에 대한 커스텀 구축이 비용이 얼마나 들지 궁금하다면, 우리의 가격 책정 페이지는 출발점을 가지고 있거나, 직접 연락할 수 있고 우리는 그것을 적절히 범위를 정할 것이다.

FAQ

커스텀 레스토랑 예약 시스템을 구축하는 데 얼마나 오래 걸리는가?

최소 실행 가능 제품 -- 예약 위젯, 확인 이메일, 기본 관리 패널 -- 4-6주의 개발 시간을 기대한다. 플로어 플랜 관리, SMS 리마인더, 보증금 수집, POS 통합이 있는 완전히 기능하는 시스템은 보통 8-12주를 소요한다. 우리는 범위가 타이트하고 레스토랑이 정확히 무엇이 필요한지 알 때 이른 3주 안에 MVP를 배송했다.

내 기존 OpenTable 예약 데이터를 커스텀 시스템으로 마이그레이션할 수 있는가?

예, 하지만 그것은 일을 소요한다. OpenTable은 손님 데이터 (이름, 이메일, 전화, 방문 이력)를 CSV 파일로 내보낼 수 있게 한다. 당신은 라이브로 가기 전에 당신의 새 시스템으로 이것을 가져오길 원할 것이다 그래서 당신이 손님 이력을 잃지 않는다. Tablesit 및 Resos 같은 일부 대안 플랫폼도 데이터 임포트를 지원한다. 중요한 것은 OpenTable을 취소한 후가 아니라 이전에 이것을 한다는 것이다.

나가면 Google에서 예약을 잃을까?

반드시 그렇지 않다. Google Reserve는 OpenTable뿐 아니라 여러 예약 파트너와 작동한다. Resos 및 Tableo 같은 플랫폼은 Google Reserve 통합이 내장되어 있다. 당신이 완전히 커스텀으로 구축하는 경우, 당신은 여전히 Google Reserve API를 구현하거나 하이브리드 접근을 사용해서 -- 자신의 사이트를 위한 커스텀 위젯, Google 채널을 위한 제3자 플랫폼 -- Google 검색 결과에서 "Reserve" 버튼으로 나타날 수 있다.

커스텀 예약 시스템으로 노쇼를 처리하는 방법은?

세 가지 입증된 전략: 예약 24시간 전의 자동 SMS 리마인더 (노쇼를 20-30%로 감소), 고수요 슬롯에 신용 카드 보증금 요구, 반복된 위반자를 플래그하는 노쇼 추적 시스템. 당신의 커스텀 시스템은 모두 세 가지를 구현할 수 있다. 일부 레스토랑은 또한 자동으로 취소된 슬롯을 채우는 대기자 명단 기능을 사용한다.

단일 작은 레스토랑을 위해 커스텀으로 구축할 가치가 있는가?

솔직하게? 아마 아니, 당신이 매우 구체적인 요구사항을 가지지 않으면. 월 500명 미만의 커버를 하는 단일 위치의 경우, Tablesit의 무료 계층 (월 500건 예약) 또는 Resos at $24/월이 당신을 잘 섬길 것이다. 커스텀 구축 ROI는 당신이 OpenTable 수수료에 연 $10K 이상을 지출하고 있거나, 여러 위치를 실행하거나, 기성 플랫폼이 지원하지 않는 시스템과의 통합이 필요할 때 정말로 시작된다.

레스토랑 예약 엔진을 위해 어떤 기술 스택을 사용해야 하는가?

나는 예약 위젯과 관리 대시보드 모두에 Next.js를 권장하고, 데이터베이스에는 PostgreSQL (예약 데이터는 매우 관계형이다), 호스팅에는 Vercel. 더 가벼운 무게 접근의 경우, Astro with React islands는 손님 대면 예약 위젯에 대해 아름답게 작동한다 -- 최대 성능을 위해 정적 페이지와 대화형 예약 폼. Node.js with Express은 API 계층을 잘 처리한다. 이것은 우리가 보통 우리의 Next.js 및 Astro 클라이언트 프로젝트에 사용하는 스택이다.

온라인 예약과 함께 워크인을 위해 테이블 할당을 처리하는 방법은?

당신의 관리 대시보드는 플로어의 실시간 뷰가 필요하다. 워크인이 도착하면, 호스트는 대시보드를 확인하고, 어떤 테이블이 자유로운지 본다 (다가오는 예약과 버퍼 시간을 설명), 그리고 수동으로 하나를 할당한다. 시스템은 온라인에서 예약되는 것을 차단해야 한다 그 테이블을 적절한 식사 시간 동안. 이것은 기본적으로 OpenTable이 사용하는 것과 같은 흐름이다 -- 당신은 그것을 단지 당신의 자신의 시스템에서 실행하고 있다.

커스텀 예약 시스템은 나의 POS와 통합할 수 있는가?

예, 하지만 그것은 당신의 POS에 따라 다르다. Toast, Square, Clover, Lightspeed 같은 시스템 모두는 예약 데이터가 POS로 흐를 수 있게 하는 API를 가진다 (그래서 서버는 손님 이름, 그룹 크기, 그리고 그들이 도착하기 이전의 어떤 노트를 안다). 더 고급 통합은 분석에 대한 예약 시스템으로 데이터를 다시 확인할 수 있다 -- 커버당 평균 지출, 시간대별 인기 있는 항목, 등. POS 통합은 보통 커스텀 구축의 가장 시간이 오래 걸리는 부분이다 왜냐하면 모든 POS API는 다르기 때문이다.