تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
على الشركاء المشاركين في برنامج "قوائم الانتظار للحجز" إكمال إعداد الحساب قبل البدء. ومع ذلك، ليست بعض الخطوات الواردة في الدليل العام ضرورية ل
استخدام ميزة "قائمة الانتظار". توضّح الإرشادات الواردة في هذه الصفحة الخطوات التي
تنطبق على الشركاء المهتمين باستخدام ميزة "قائمة الانتظار" في ميزة "الحجز عبر
Google". ننصحك بقراءة هذه النظرة العامة قبل تنفيذ
خطوات الدمج.
عملية الإطلاق
يوضّح الشكل 1 عملية إطلاق ميزة "الإجراءات" لدى التجّار المدرَجين في قائمة الانتظار.
الشكل 1: خطوات الدمج على مستوى عالٍ
بشكل عام، تم توضيح عمليات نقل البيانات الرئيسية بينك (الشريك) وGoogle
في الشكل 2:
الشكل 2: مخطّط تدفق بيانات الدمج
إرشادات لجميع شركاء قوائم انتظار الحجوزات
يُرجى مراعاة ما يلي عند تنفيذ ميزة قوائم الانتظار للحجوزات:
يجب استخدام الخدمة نفسها لكل من قائمة الانتظار والحجز. بعبارة أخرى، إذا كان
مطعمك يسمح أيضًا بالحجوزات، ما عليك سوى إضافة البيانات الوصفية ذات الصلة بقائمة الانتظار إلى الخدمة
للحجز.
يجب إرسال معلومات عبر الرسائل القصيرة لتنفيذ قائمة الانتظار في
الحالات التالية:
لتأكيد انضمام المستخدم إلى قائمة الانتظار بنجاح.
لإعلام المستخدم بأنّ طاولته جاهزة
لإعلام المستخدم بأنّه تم إلغاء إدخاله في قائمة الانتظار
يجب أن تحتوي رسائل SMS على رابط يؤدي إلى صفحة يمكن للمستخدمين من خلالها الاطّلاع على
حالة انتظارهم.
لا يحتاج التجّار المدرَجون في قائمة الانتظار فقط إلى تقديم خلاصات معلومات التوفّر إلى
مركز الإجراءات.
يجب أن ينفِّذ خادم الحجز جميع الخطوات المتعلّقة بقائمة الانتظار
والمُدرَجة في مقالة
تنفيذ خادم الحجز. يمكن للشركاء الذين يتيحون كلاً من
الحجوزات وقوائم الانتظار إضافة الطرق الجديدة إلى
خادم الحجز الحالي.
يُجري "مركز الإجراءات" مجموعة من حالات الاختبار لطرق القائمة الانتظار في خادم الحجز.
في ما يلي الحالات الشائعة في دمج قوائم الانتظار للحجز والحلول المفضّلة
لها.
إذا كانت بعض أحجام المجموعات (وليس كلها) لا تقبل طلبات جديدة للانضمام إلى قائمة الانتظار
لأنّه لا يوجد وقت انتظار لهذه الأحجام، يُفضّل إعادة عرض
WaitEstimates لجميع أحجام المجموعات في ردّ BatchGetWaitEstimates والسماح للمستخدمين بالانضمام إلى
قائمة الانتظار لهذه الأحجام بدون انتظار. عرض WaitLength مع
0 parties_ahead_count و/أو مع estimated_seat_time_range مع 0
start_seconds و0 end_seconds للparty_sizes
بدون انتظار
إذا كانت فئة واحدة أو أكثر من فئات عدد الضيوف لا تقبل إضافات جديدة إلى قائمة الانتظار
لأنّ وقت الانتظار أصبح طويلاً جدًا، يُفضَّل حذف
WaitEstimates لهذه الفئات في ردّ
BatchGetWaitEstimates.
ويُفضّل استخدام هذه الأساليب لأنّها تمنح المستخدم خيارات حتى إذا كانت قائمة الانتظار لدى التاجر غير مفتوحة بالكامل.
إرشادات للشركاء الذين يستخدمون قوائم انتظار الحجوزات فقط
يُرجى مراعاة ما يلي إذا كان خادم الحجز مخصّصًا فقط لأجل
قوائم الانتظار:
لا يوفّر الشركاء الذين يوفّرون قوائم انتظار للحجز فقط خلاصات مدى التوفّر لخدمة "الحجز عبر Google".
لا يطبّق الشركاء المدرَجون في قوائم الانتظار للحجز فقط طرق الحجز في
خادم الحجز. بدلاً من ذلك، عليك
تنفيذ خادم الحجز باستخدام تعليمات تنفيذ قائمة الانتظار.
لا يُجري الشركاء المدرَجون في قوائم الانتظار للحجز فقط طلبات بيانات من واجهة برمجة التطبيقات إلى Google. وهذا يعني أنّه ليس على
الشركاء المدرَجين في قوائم الانتظار للحجز فقط إعداد مشروع على السحابة الإلكترونية أو تقديم
عنوان بريد إلكتروني للمطوّر. لست بحاجة إلى إكمال
تعديلات واجهة برمجة التطبيقات في الوقت الفعلي. ومع ذلك، يجب توفير خلاصتَي التاجر والخدمة في "مركز الإجراءات".
إرشادات للشركاء الذين يجب أن يقبل تاجروهم
أو يرفضوا يدويًا عمليات إضافة عملاء إلى قائمة الانتظار
إذا كان التجّار بحاجة إلى إمكانية قبول أو رفض طلبات الإضافة الجديدة
إلى قائمة الانتظار من Google يدويًا، يجب اتّخاذ خطوات إضافية:
اضبط waitlist_confirmation_mode على
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS في
wait_estimate لحجم المجموعات التي تتطلّب
تأكيدًا يدويًا. يجب ضبط هذه القيمة في
BatchGetWaitEstimateResponse و
GetWaitlistEntryResponse.
إنّ إدخالات قائمة الانتظار التي طلبها المستخدم ولم يقبلها التاجر بعد
يجب أن تكون في الحالة
PENDING_MERCHANT_CONFIRMATION.
حالات اختبار قوائم انتظار الحجوزات
تختبر Google حالات الاستخدام التالية لضمان وظيفة methods
في قائمة الانتظار عند تنفيذ خادم الحجز. تختبر Google أيضًا وقت الاستجابة و
تراقبه. يجب اجتياز جميع هذه الاختبارات قبل الإطلاق.
استرجاع WaitEstimate
يتم عرض تقديرات وقت الانتظار لكل حجم مجموعة مطلوب في
BatchGetWaitEstimatesRequest.
بالنسبة إلى أحجام المجموعات التي يتوفّر للتاجر خيار قبول أو رفض
إضافات جديدة إلى قائمة الانتظار، اضبط waitlist_confirmation_mode على
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS.
إنشاء إدخال في قائمة الانتظار
يمكن إنشاء إدخال في قائمة الانتظار من طلب
CreateWaitlistEntry.
إذا تعذّر إنشاء إدخال في قائمة الانتظار، سيظهر خطأ في منطق النشاط التجاري في
الاستجابة.
إذا نجحت محاولة CreateWaitlistEntry، يتم عرض الاستجابة نفسها
عند تلقّي CreateWaitlistEntry نفسه
مرة أخرى.
إذا تعذّر إكمال محاولة CreateWaitlistEntry، يعيد الخادم المحاولة
عند تلقّي CreateWaitlistEntry نفسه مرة أخرى.
تظهر إدخالات قائمة الانتظار في واجهة التاجر.
تؤدي المكالمات إلى GetWaitlistEntry إلى عرض إدخال قائمة الانتظار الذي تم إنشاؤه
بنجاح.
حالات إدخالات قائمة الانتظار والطوابع الزمنية
تأكَّد من أنّه يتم عرض حالة كل إدخال في قائمة الانتظار بشكل صحيح في إدخال قائمة الانتظار الذي يحتوي على
GetWaitlistEntry ردّ.
تأكَّد من ضبط الطابع الزمني لكل حالة في حقل الطابع الزمني المناسب لentry
في ردود GetWaitlistEntry.
حذف إدخال قائمة الانتظار
يمكن حذف إدخالات قائمة الانتظار الحالية. يجب أن يكون الردّ على عملية حذف ناجحة
هو العنصر proto الفارغ {}.
إيقاف
تأكَّد من أنّه يتم التعامل مع التجّار الذين أوقفوا الميزة على النحو الموضّح في
إيقاف التجّار للميزة.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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."]]
