Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Partner yang berpartisipasi dalam program Daftar Tunggu Reservasi harus menyelesaikan Penyiapan akun sebelum memulai. Namun, beberapa langkah dalam panduan umum tidak diperlukan untuk
penggunaan fitur daftar tunggu. Panduan di halaman ini menjelaskan langkah-langkah yang berlaku untuk partner yang berminat menggunakan fitur daftar tunggu di Pesan dengan Google. Sebaiknya baca ringkasan ini sebelum melakukan langkah-langkah integrasi.
Proses peluncuran
Gambar 1 menguraikan proses untuk meluncurkan penjual Anda yang didukung fitur daftar tunggu di Pusat Actions.
Gambar 1: Langkah integrasi tingkat tinggi
Secara keseluruhan, alur data utama antara Anda (Partner) dan Google
diilustrasikan dalam Gambar 2:
Gambar 2: Diagram alur data integrasi
Panduan untuk semua partner Daftar Tunggu Reservasi
Perhatikan hal-hal berikut saat Anda menerapkan fitur Daftar Tunggu Reservasi:
Anda harus menggunakan layanan yang sama untuk daftar tunggu dan reservasi. Dengan kata lain, jika
restoran Anda juga mengizinkan reservasi, cukup tambahkan metadata terkait daftar tunggu ke layanan
untuk reservasi.
Pengiriman pembaruan SMS diperlukan untuk penerapan daftar tunggu dalam
kasus berikut:
Untuk mengonfirmasi bahwa pengguna telah berhasil bergabung ke daftar tunggu.
Untuk memberi tahu pengguna bahwa meja mereka sudah siap.
Untuk memberi tahu pengguna bahwa entri daftar tunggunya telah dibatalkan.
Pesan SMS harus berisi link ke halaman tempat pengguna dapat melihat
status daftar tunggu mereka.
Penjual khusus daftar tunggu tidak perlu menyediakan feed ketersediaan ke Pusat Tindakan.
Server pemesanan Anda harus menerapkan semua langkah khusus daftar tunggu
yang tercantum dalam
Menerapkan server pemesanan. Partner yang mendukung
reservasi dan daftar tunggu dapat menambahkan metode baru ke server pemesanan
yang ada.
Pusat Action menjalankan kumpulan
kasus pengujian untuk metode daftar tunggu di server pemesanan.
Berikut adalah kasus ekstrem umum dalam integrasi Daftar Tunggu Reservasi dan solusi pilihan untuk kasus tersebut.
Jika beberapa (tetapi tidak semua) jumlah tamu tidak menerima penambahan daftar tunggu baru karena tidak ada waktu tunggu dengan jumlah tamu tersebut, sebaiknya tampilkan WaitEstimates untuk semua jumlah tamu dalam respons BatchGetWaitEstimates dan izinkan pengguna bergabung ke daftar tunggu untuk jumlah tamu tersebut tanpa waktu tunggu. Menampilkan WaitLength dengan
0 parties_ahead_count dan/atau dengan estimated_seat_time_range dengan 0
start_seconds dan dengan 0 end_seconds untuk party_size
tanpa menunggu
Jika satu atau beberapa jumlah tamu tidak menerima penambahan daftar tunggu baru karena waktu tunggu menjadi terlalu lama, sebaiknya hapus WaitEstimates untuk jumlah tamu tersebut dalam respons BatchGetWaitEstimates.
Pendekatan ini lebih disarankan karena memberikan opsi kepada pengguna meskipun daftar tunggu penjual mungkin tidak sepenuhnya terbuka.
Panduan untuk partner khusus Daftar Tunggu Pemesanan
Perhatikan hal berikut jika server pemesanan hanya digunakan untuk daftar tunggu:
Partner khusus Daftar Tunggu Reservasi tidak menyediakan feed ketersediaan ke Pesan dengan Google.
Partner khusus Daftar Tunggu Reservasi tidak menerapkan metode reservasi di server pemesanan mereka. Sebagai gantinya, Anda
Menerapkan server pemesanan dengan petunjuk untuk Penerapan
Daftar Tunggu.
Partner khusus Daftar Tunggu Reservasi tidak melakukan panggilan API ke Google. Artinya, partner khusus Daftar Tunggu Reservasi tidak perlu menyiapkan project cloud atau memberikan alamat email developer. Anda tidak perlu menyelesaikan
Update API real-time. Namun,
feed penjual dan
layanan tetap harus disediakan ke Pusat Tindakan.
Panduan untuk partner yang penjualnya harus
menyetujui/menolak penambahan daftar tunggu secara manual
Jika penjual Anda memerlukan kemampuan untuk menyetujui atau menolak penambahan daftar tunggu baru dari Google secara manual, langkah tambahan diperlukan:
Tetapkan waitlist_confirmation_mode ke
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS di
wait_estimate untuk jumlah tamu yang memerlukan konfirmasi
manual. Nilai ini harus ditetapkan di
BatchGetWaitEstimateResponse dan
GetWaitlistEntryResponse.
Entri daftar tunggu yang telah diminta oleh pengguna, tetapi belum disetujui oleh penjual harus berada dalam status PENDING_MERCHANT_CONFIRMATION.
Kasus pengujian Daftar Tunggu Reservasi
Google menguji kasus penggunaan berikut untuk memastikan fungsi metode daftar tunggu dalam penerapan server pemesanan Anda. Google juga menguji dan
memantau latensi. Semua pengujian ini harus dinyatakan lulus sebelum peluncuran dilakukan.
Pengambilan WaitEstimate
Estimasi waktu tunggu ditampilkan untuk setiap jumlah tamu yang diminta dalam
BatchGetWaitEstimatesRequest.
Untuk jumlah tamu yang memberikan opsi bagi penjual untuk menerima atau menolak
penambahan daftar tunggu baru, tetapkan waitlist_confirmation_mode ke
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS.
Pembuatan entri daftar tunggu
Entri daftar tunggu dapat dibuat dari permintaan CreateWaitlistEntry.
Jika pembuatan entri daftar tunggu gagal, error logika bisnis akan muncul dalam respons.
Jika percobaan CreateWaitlistEntry berhasil, respons yang sama
ditampilkan saat CreateWaitlistEntry yang sama diterima
kembali.
Jika percobaan CreateWaitlistEntry gagal, server akan mencoba lagi saat CreateWaitlistEntry yang sama diterima kembali.
Entri daftar tunggu muncul di antarmuka penjual.
Panggilan ke GetWaitlistEntry berhasil menampilkan entri daftar tunggu yang dibuat.
Status dan stempel waktu entri daftar tunggu
Verifikasi bahwa setiap status entri daftar tunggu ditampilkan dengan benar dalam entri daftar tunggu dalam respons GetWaitlistEntry.
Verifikasi bahwa setiap stempel waktu status ditetapkan di kolom stempel waktu yang sesuai di entri daftar tunggu dalam respons GetWaitlistEntry.
Penghapusan entri daftar tunggu
Entri daftar tunggu yang ada dapat dihapus. Respons terhadap penghapusan yang berhasil harus berupa proto kosong {}.
Nonaktifkan
Verifikasikan bahwa penjual yang tidak ikut serta ditangani seperti yang dideskripsikan dalam
Ketidakikutsertaan penjual.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-26 UTC."],[[["\u003cp\u003eThis guide explains the integration process for Reserve with Google's Waitlist feature, specifically designed for partners already familiar with Reservations.\u003c/p\u003e\n"],["\u003cp\u003ePartners need to implement waitlist-specific steps in their booking server and ensure it passes Google's test cases before launching.\u003c/p\u003e\n"],["\u003cp\u003eSMS updates for confirmations, table readiness, and cancellations are mandatory, including a link for users to check their waitlist status.\u003c/p\u003e\n"],["\u003cp\u003eIntegration typically requires 12-14 weeks with dedicated technical resources, and partners should be prepared for common edge cases and merchant opt-out scenarios.\u003c/p\u003e\n"],["\u003cp\u003eWhile Reservations partners need to add waitlist metadata to existing services, Waitlist-only partners don't need to provide availability feeds or implement reservation methods.\u003c/p\u003e\n"]]],["Partners in the Reservations Waitlists program must complete account setup. Key actions include populating `waitlist_rules` in the service feed, implementing a booking server with waitlist-specific steps, and sending SMS updates for waitlist confirmations, table readiness, and cancellations. Waitlist-only merchants do not require availability feeds or reservation methods. Manual accept/reject requires setting `waitlist_confirmation_mode`. Google tests wait estimate retrieval, waitlist entry creation/deletion, status reporting and opt out responses, all of which must pass prior to launch.\n"],null,["# Overview\n\n| **Note:** This section is only relevant for partners completing Reservations Waitlists integration.\n\nPartners participating in the Reservations Waitlists program must complete the account\n[Setup](/actions-center/verticals/reservations/waitlists/integration-steps/setup) before\nthey begin. However, some steps in the general guide aren't necessary for\nuse of the waitlist feature. The guidelines on this page explain what steps\napply to partners interested in using the waitlist feature on Reserve with\nGoogle. We suggest that you read through this overview before going through\nthe integration steps.\n\nLaunch process\n--------------\n\nFigure 1 outlines the process to launch your waitlist-enabled merchants\non the Actions Center.\n| **Note:** Integration typically takes 12-14 weeks with dedicated technical resources.\n**Figure 1:** High-level integration steps\n\nOverall, the major data flows between you (the Partner) and Google are\ncaptured in Figure 2:\n**Figure 2:** Integration data flow diagram\n\nGuidelines for all Reservations Waitlists partners\n--------------------------------------------------\n\nKeep the following in mind as you implement the Reservations Waitlists feature:\n\n- The service for every Reservations Waitlists merchant must have [`waitlist_rules` populated](/actions-center/verticals/reservations/waitlists/reference/feeds/services-feed).\n - You must use the same service for both waitlist and reservation. In other words, if your restaurant also allows reservations, just add the waitlist related metadata to the service for reservation.\n- Sending out SMS updates is required for the waitlist implementation in the following cases:\n - To confirm the user has successfully joined the waitlist.\n - To notify the user that their table is ready.\n - To notify the user that their waitlist entry has been cancelled.\n- SMS messages must contain a link to a page where users can view their waitlist status.\n- Waitlist-only merchants do not need to provide availability feeds to the Actions Center.\n- Your booking server must implement all the waitlist-specific steps listed in [Implement the booking server](/actions-center/verticals/reservations/waitlists/integration-steps/implement-waitlist-booking-server). Partners that support both reservations and waitlists can add on the new methods to their existing booking server.\n- The Actions Center runs a set of [test cases](/actions-center/verticals/reservations/waitlists/integration-steps/overview#test-cases) for the waitlist methods in the booking server.\n\n### Status flowchart\n\n\nThis chart describes the statuses that must be reported in\n[`WaitlistEntry.waitlist_entry_state`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistentry-definition) when responding to\n[`GetWaitlistEntry`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method) calls. The chart also indicates when to record and populate the\n[`WaitlistEntry.waitlist_entry_state_times.*_time_seconds`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistentry-definition) fields and when to send an SMS to the user to inform them they have entered a new state.\n**Figure: 3** Waitlist status flowchart\n\n### Common edge cases\n\nThe following are common edge cases in a Reservations Waitlists integration and preferred\nsolutions for them.\n\n- If some (but not all) party sizes are not accepting new waitlist additions because there is no wait on these party sizes then returning `WaitEstimates` for all party sizes in the `BatchGetWaitEstimates` response and allowing users to join the waitlist for these party sizes with no wait is preferred. Return a `WaitLength` with 0 `parties_ahead_count` and/or with an `estimated_seat_time_range` with 0 `start_seconds` and with 0 `end_seconds` for the `party_size`s with no wait\n- If one or more party sizes are not accepting new waitlist additions because the wait has become too long then omitting `WaitEstimates` for those party sizes in the `BatchGetWaitEstimates` response is preferred.\n\nThese approaches are preferred since they give the user options even though\nthe merchant's waitlist may not be fully open.\n\nGuidelines for Reservations Waitlists-only partners\n---------------------------------------------------\n\nKeep the following in mind if the booking server is used only for\nwaitlists:\n\n- Reservations Waitlists-only partners don't provide availability feeds to Reserve with Google.\n- Reservations Waitlists-only partners do not implement the reservation methods in their booking server. Instead, you [Implement the booking server](/actions-center/verticals/reservations/waitlists/integration-steps/implement-waitlist-booking-server) with the instructions for the Waitlist implementation.\n- Reservations Waitlists-only partners do not make API calls to Google. This means that Reservations Waitlists-only partners do not need to set up a cloud project or provide a developer email address. You do not need to complete [Real-time API updates](/actions-center/verticals/reservations/waitlists/integration-steps/real-time-api-updates). However, [merchant](/actions-center/verticals/reservations/waitlists/reference/feeds/merchants-feed) and [service](/actions-center/verticals/reservations/waitlists/reference/feeds/services-feed) feeds still need to be provided to the Actions Center.\n\nGuidelines for partners whose merchants must\nmanually accept/reject waitlist additions\n--------------------------------------------------------------------------------------\n\nIf your merchants require the ability to manually accept or reject new\nwaitlist additions from Google, extra steps are required:\n\n- Set the `waitlist_confirmation_mode` to `WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS` in the `wait_estimate` for party sizes which require manual confirmation. This must be set in the [`BatchGetWaitEstimateResponse`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/batchgetwaitestimates-method) and the [`GetWaitlistEntryResponse`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method).\n- Waitlist entries that have been requested by the user, but not yet accepted by the merchant should be in state `PENDING_MERCHANT_CONFIRMATION`.\n\nReservations Waitlists test cases\n---------------------------------\n\nGoogle tests the following use cases to ensure the functionality of the\nwaitlist methods in your booking server implementation. Google also tests and\nmonitors latency. All of these tests must pass prior to launch.\n\n### WaitEstimate retrieval\n\n- Wait estimates are returned for each party size requested in a `BatchGetWaitEstimatesRequest`.\n- For party sizes which the merchant has the option to accept or reject new waitlist additions, set waitlist_confirmation_mode to `WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS`.\n\n### Waitlist entry creation\n\n- A waitlist entry can be created from a `CreateWaitlistEntry` request.\n- If waitlist entry creation fails, a business logic error shows up in the response.\n- If a `CreateWaitlistEntry` attempt succeeds, the same response is returned when the same `CreateWaitlistEntry` is received again.\n- If a `CreateWaitlistEntry` attempt fails, the server retries when the same `CreateWaitlistEntry` is received again.\n- Waitlist entries show up in the merchant's interface.\n- Calls to `GetWaitlistEntry` successfully return the created waitlist entry.\n\n### Waitlist entry states and timestamps\n\n- Verify that each waitlist entry state is returned properly in the waitlist entry of `GetWaitlistEntry` responses.\n- Verify that each state timestamp is set in the appropriate timestamp field of the waitlist entry in `GetWaitlistEntry` responses.\n\n### Waitlist entry deletion\n\n- Existing waitlist entries can be deleted. The response to a successful delete must be the empty proto `{}`.\n\n### Opt out\n\n- Verify that opted out merchants are treated as described in [Merchant opt out](/actions-center/verticals/reservations/waitlists/integration-steps/overview#merchant-opt-out).\n\nSample waitlist service feed (JSON)\n-----------------------------------\n\n[Waitlist service feed](/actions-center/verticals/reservations/waitlists/reference/feeds/services-feed)\n\nMerchant opt out\n----------------\n\nGoogle expects certain responses for merchants that previously had waitlists\nenabled but have decided to opt out.\n\n### Immediate opt out\n\n- Return [`CLOSED_OTHER`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistbusinesslogicfailure-definition) for [`BatchGetWaitEstimates`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/batchgetwaitestimates-method) requests.\n- Return [`WAITLIST_CLOSED`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistbusinesslogicfailure-definition) for [`CreateWaitlistEntry`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createwaitlistentry-method) requests.\n- Return [`GetWaitlistEntry`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method) requests properly for users who are already on the waitlist.\n\n### Extended opt out\n\n- Remove the `waitlist_rules` from the service feed for the merchant if the merchant is not opting out of reservations.\n- Remove the merchant from the merchant feed if they opt out of all Google integrations."]]
