با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
شرکای شرکت کننده در برنامه لیست انتظار رزرواسیون باید تنظیمات حساب را قبل از شروع انجام دهند. با این حال، برخی از مراحل در راهنمای کلی برای استفاده از ویژگی لیست انتظار ضروری نیست. دستورالعمل های این صفحه توضیح می دهد که چه مراحلی برای شرکای علاقه مند به استفاده از ویژگی لیست انتظار در رزرو با Google اعمال می شود. پیشنهاد می کنیم قبل از انجام مراحل ادغام، این نمای کلی را مطالعه کنید.
فرآیند راه اندازی
شکل 1 روند راه‌اندازی بازرگانان دارای لیست انتظار شما را در مرکز اقدامات نشان می‌دهد.
شکل 1: مراحل ادغام سطح بالا
به طور کلی، جریان اصلی داده بین شما (شریک) و Google در شکل 2 نشان داده شده است:
شکل 2: نمودار جریان داده یکپارچه
دستورالعمل‌هایی برای همه شرکای فهرست انتظار رزرواسیون
هنگام اجرای ویژگی لیست انتظار رزرواسیون، موارد زیر را در نظر داشته باشید:
هم برای لیست انتظار و هم برای رزرو باید از یک سرویس استفاده کنید. به عبارت دیگر، اگر رستوران شما اجازه رزرو را نیز می‌دهد، فقط ابرداده مربوط به لیست انتظار را برای رزرو به سرویس اضافه کنید.
ارسال به روز رسانی SMS برای اجرای لیست انتظار در موارد زیر ضروری است:
برای تأیید اینکه کاربر با موفقیت به لیست انتظار ملحق شده است.
تا به کاربر اطلاع دهد که جدول او آماده است.
برای اطلاع دادن به کاربر مبنی بر لغو لیست انتظار وی.
پیام های اس ام اس باید حاوی پیوندی به صفحه ای باشد که در آن کاربران می توانند وضعیت لیست انتظار خود را مشاهده کنند.
تاجرانی که فقط فهرست انتظار هستند نیازی به ارائه فیدهای در دسترس به مرکز اقدامات ندارند.
سرور رزرو شما باید تمام مراحل خاص لیست انتظار فهرست شده در Implement the booking server را اجرا کند. شرکایی که از رزرو و لیست انتظار پشتیبانی می کنند، می توانند روش های جدید را به سرور رزرو موجود خود اضافه کنند.
مرکز اقدامات مجموعه‌ای از موارد آزمایشی را برای روش‌های فهرست انتظار در سرور رزرو اجرا می‌کند.
موارد زیر موارد لبه رایج در ادغام لیست انتظار رزروها و راه حل های ترجیحی برای آنها هستند.
اگر برخی از اندازه‌های مهمانی (اما نه همه) اضافه‌های فهرست انتظار جدید را نمی‌پذیرند، زیرا برای این اندازه‌های مهمانی انتظاری وجود ندارد، بازگشت WaitEstimates برای همه اندازه‌های مهمانی در پاسخ BatchGetWaitEstimates و اجازه دادن به کاربران برای پیوستن به لیست انتظار برای این اندازه‌های مهمانی بدون هیچ انتظاری است. ارجح. یک WaitLength با 0 parties_ahead_count و/یا با estimated_seat_time_range با 0 start_seconds و با 0 end_seconds برای party_size بدون انتظار برگردانید.
اگر یک یا چند اندازه مهمانی اضافه‌های فهرست انتظار جدید را نمی‌پذیرند زیرا انتظار بیش از حد طولانی شده است، حذف WaitEstimates برای آن اندازه مهمانی در پاسخ BatchGetWaitEstimates ترجیح داده می‌شود.
این رویکردها ترجیح داده می‌شوند زیرا گزینه‌هایی را در اختیار کاربر قرار می‌دهند حتی اگر فهرست انتظار تاجر کاملاً باز نباشد.
دستورالعمل‌ها برای شرکای فقط در فهرست انتظار رزروها
اگر از سرور رزرو فقط برای لیست انتظار استفاده می شود موارد زیر را در نظر داشته باشید:
شرکای فقط در فهرست انتظار رزرواسیون، فیدهای در دسترس را برای رزرو با Google ارائه نمی دهند.
شرکای فقط در فهرست انتظار رزروها با Google تماس API برقرار نمی کنند. این بدان معناست که شرکای فقط در لیست انتظار رزرواسیون نیازی به راه‌اندازی یک پروژه ابری یا ارائه آدرس ایمیل توسعه‌دهنده ندارند. نیازی به تکمیل به‌روزرسانی‌های Real-time API ندارید. با این حال، بازرگانان و فیدهای خدمات هنوز باید به مرکز اقدامات ارائه شوند.
دستورالعمل‌هایی برای شرکای که بازرگانان آنها باید به‌صورت دستی اضافه‌های فهرست انتظار را بپذیرند/رد کنند
اگر بازرگانان شما به توانایی پذیرش یا رد دستی افزوده‌های فهرست انتظار جدید از Google نیاز دارند، مراحل اضافی لازم است:
waitlist_confirmation_mode را در wait_estimate برای اندازه‌های مهمانی که نیاز به تأیید دستی دارند، روی WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS تنظیم کنید. این باید در BatchGetWaitEstimateResponse و GetWaitlistEntryResponse تنظیم شود.
ورودی‌های فهرست انتظار که توسط کاربر درخواست شده، اما هنوز توسط تاجر پذیرفته نشده‌اند، باید در حالت PENDING_MERCHANT_CONFIRMATION باشند.
موارد آزمایشی لیست انتظار رزروها
Google موارد استفاده زیر را برای اطمینان از عملکرد روش‌های فهرست انتظار در اجرای سرور رزرو شما آزمایش می‌کند. گوگل همچنین تأخیر را آزمایش و نظارت می کند. همه این تست ها باید قبل از راه اندازی انجام شود.
بازیابی WaitEstimate
برآوردهای انتظار برای هر اندازه طرف درخواست شده در BatchGetWaitEstimatesRequest برگردانده می شود.
برای اندازه‌های مهمانی که تاجر می‌تواند افزوده‌های فهرست انتظار جدید را بپذیرد یا رد کند، Waitlist_confirmation_mode را روی WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS تنظیم کنید.
ایجاد فهرست انتظار
یک ورودی لیست انتظار را می توان از یک درخواست CreateWaitlistEntry ایجاد کرد.
اگر ایجاد فهرست انتظار ناموفق باشد، یک خطای منطق تجاری در پاسخ ظاهر می شود.
اگر تلاش CreateWaitlistEntry با موفقیت انجام شود، زمانی که همان CreateWaitlistEntry دوباره دریافت شد، همان پاسخ برگردانده می شود.
اگر تلاش CreateWaitlistEntry با شکست مواجه شد، سرور با دریافت مجدد همان CreateWaitlistEntry دوباره تلاش می کند.
ورودی‌های فهرست انتظار در واسط تاجر نشان داده می‌شوند.
تماس های GetWaitlistEntry با موفقیت ورودی لیست انتظار ایجاد شده را برمی گرداند.
وضعیت های ورود به لیست انتظار و مهرهای زمانی
بررسی کنید که هر وضعیت ورودی لیست انتظار به درستی در ورودی لیست انتظار پاسخ های GetWaitlistEntry برگردانده شده است.
بررسی کنید که هر مهر زمانی در قسمت مُهر زمانی مناسب ورودی فهرست انتظار در پاسخ‌های GetWaitlistEntry تنظیم شده باشد.
حذف ورودی لیست انتظار
ورودی های لیست انتظار موجود را می توان حذف کرد. پاسخ به یک حذف موفق باید پروتو خالی {} باشد.
انصراف دهید
بررسی کنید که با بازرگانان انصرافی مطابق با توضیح در انصراف تاجر رفتار شود.
تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی."],[[["\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."]]
