party_size: Số lượng người trong nhóm có thể được phục vụ trong khung giờ này. Một nhà hàng có thể được liên kết với nhiều Khung giờ trong cùng một thời điểm, mỗi khung giờ chỉ định một party_size khác nhau, ví dụ: 2, 3 hoặc 4 người có thể ngồi khi đặt trước
spots_open: Số chỗ hiện có cho mục nhập tình trạng còn chỗ này
spots_total: Tổng số vị trí mà người bán có cho cấu hình này (bao gồm cả những vị trí không có sẵn)
Ba tham số này hoạt động cùng nhau để tạo bản trình bày kỹ thuật số của bản vẽ mặt bằng. party_size là số người mà mỗi bàn có thể chứa (sẽ có một mục cho mỗi kích thước mà bàn có thể chứa). spots_open và spots_total là số lượng bảng có thể chứa party_size đó.
Ví dụ về sơ đồ tầng trống
Hãy tưởng tượng một nhà hàng có sơ đồ mặt bằng như sau và không có yêu cầu đặt chỗ nào đang hoạt động:
Hình 1: Bản vẽ mặt bằng không có
lượt đặt phòng đang hoạt động
Giá trị cho party_size, spots_open và spots_total sẽ là:
party_size
spots_open
spots_total
4
3
3
5
3
3
6
4
4
7
1
1
8
1
1
Nguồn cấp dữ liệu về tình trạng còn hàng cho một khung giờ tại người bán này sẽ có dạng như sau:
Chỉ định tình trạng phòng ăn có hỗ trợ bàn kết hợp
Nhà hàng có thể kết hợp các bàn theo nhiều cách để phục vụ các nhóm lớn hơn. Bạn cần chỉ định spots_open và spots_total trong nguồn cấp dữ liệu theo cách phản ánh chính xác liệu bạn có thể chấp nhận các bữa tiệc có kích thước nhất định hay không. Sau đây là một ví dụ về cách bạn có thể chỉ định kết hợp các bảng.
Cách tính toán này có thể khác một chút đối với nguồn cấp dữ liệu của bạn và bạn có thể chỉ định spots_open và spots_total theo cách phù hợp với logic kinh doanh của mình.
Nếu một nhà hàng hỗ trợ việc kết hợp các bàn để tạo thành một bữa tiệc lớn hơn, bạn có thể cập nhật spots_open và spots_total để phản ánh điều này.
Giả sử một nhà hàng có thể kết hợp hai bàn nhỏ để phục vụ một nhóm từ 7 đến 10 người.
Hình 3: Bản vẽ mặt bằng không có
lượt đặt phòng đang hoạt động
Trong trường hợp không có lượt đặt phòng đang hoạt động, giá trị của party_size, spots_open và spots_total sẽ là:
party_size
spots_open
spots_total
4
3
3
5
3
3
6
4
4
7
1
1
8
1
1
9
1
1
10
1
1
Bây giờ, với cùng một sơ đồ mặt bằng, một yêu cầu đặt chỗ được thực hiện cho một nhóm gồm 10 người, kết hợp hai bàn nhỏ.
Hình 4: Bản vẽ mặt bằng có một yêu cầu đặt chỗ đang hoạt động trải dài trên hai bàn
Sau đó, các giá trị cho party_size, spots_open và spots_total hiện là:
[null,null,["Cập nhật lần gần đây nhất: 2025-07-26 UTC."],[[["\u003cp\u003e\u003ccode\u003eparty_size\u003c/code\u003e, \u003ccode\u003espots_open\u003c/code\u003e, and \u003ccode\u003espots_total\u003c/code\u003e are key parameters in the Availability feed that represent a restaurant's floor plan and seating capacity.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003espots_open\u003c/code\u003e and \u003ccode\u003espots_total\u003c/code\u003e are dynamic values that reflect real-time availability, decreasing as bookings are made and tables are occupied.\u003c/p\u003e\n"],["\u003cp\u003eRestaurants can utilize these parameters to indicate support for combining tables for larger parties, adjusting \u003ccode\u003espots_open\u003c/code\u003e and \u003ccode\u003espots_total\u003c/code\u003e accordingly.\u003c/p\u003e\n"],["\u003cp\u003eThe provided JSON examples demonstrate how the Availability feed is structured and how these parameters are used to represent different booking scenarios.\u003c/p\u003e\n"],["\u003cp\u003eMerchants can adapt their feed logic to align with their specific business rules for managing table availability and combinations.\u003c/p\u003e\n"]]],["The core content details how `party_size`, `spots_open`, and `spots_total` define restaurant availability. `Party_size` indicates the capacity per table. `Spots_open` represents the currently available spots, while `spots_total` is the total spots a merchant has. Restaurants can have multiple slots for the same time, each with varying `party_size`. Examples illustrate floor plan representation both with and without bookings, showing how `spots_open` decreases as bookings are made and how table combination support is handled.\n"],null,["# Structuring availability data for Reservations\n\nParameter definitions\n---------------------\n\nAs specified in the\n[`Availability`](/actions-center/verticals/reservations/e2e/reference/feeds/availability-feed#Availability-definition)\ndefinition:\n\n- `party_size`: The party size that can be accommodated during this time slot. A restaurant can be associated with multiple Slots for the same time, each specifying a different `party_size`, if for instance 2, 3, or 4 people can be seated with a reservation\n- `spots_open`: The number of spots currently available for this availability entry\n- `spots_total`: The total number of spots that the merchant has for this configuration (including those that are not available)\n\nThese three parameters work together to build a digital representation of the\nfloor plan. `party_size` is the number of people each table can hold (there will\nbe an entry for every size a table can accommodate). `spots_open` and `spots_total`\nare counts of how many tables can accommodate that `party_size`.\n\nExample empty floor plan\n------------------------\n\nImagine a restaurant with the following floor plan and no active\nbookings:\n**Figure 1:** Floor plan with no active bookings\n\nThe values for `party_size`, `spots_open`, and `spots_total` would be:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 3 | 3 |\n| 5 | 3 | 3 |\n| 6 | 4 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n\nThe availability feed for one time slot at this merchant would look like: \n\n### JSON\n\n```json\n{\n \"availability\": [\n {\n \"spots_total\": 3,\n \"spots_open\": 3,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 4\n }\n },\n {\n \"spots_total\": 3,\n \"spots_open\": 3,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 5\n }\n },\n {\n \"spots_total\": 4,\n \"spots_open\": 4,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 6\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 7\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 8\n }\n }\n ]\n}\n```\n\nExample floor plan with a booking\n---------------------------------\n\nNow imagine that one of the round tables was booked:\n**Figure 2:** Floor plan with one active booking\n\nThe values for `party_size`, `spots_open`, and `spots_total` would now be:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 2 | 3 |\n| 5 | 2 | 3 |\n| 6 | 3 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n\n### JSON\n\n```json\n{\n \"availability\": [\n {\n \"spots_total\": 3,\n \"spots_open\": 2,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 4\n }\n },\n {\n \"spots_total\": 3,\n \"spots_open\": 2,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 5\n }\n },\n {\n \"spots_total\": 4,\n \"spots_open\": 3,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 6\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 7\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 8\n }\n }\n ]\n}\n```\n\nSpecifying dining availability with combined tables support\n-----------------------------------------------------------\n\nThere are many ways that a restaurant could combine tables to support larger\ngroups. You are expected in your feeds to specify `spots_open` and `spots_total`\nin a way that accurately reflects whether you can accept parties of a given\nsize. What follows is one example of how you can specify combining tables.\nYour feeds may differ somewhat in how this calculation is made and it is\nacceptable for you to specify `spots_open` and `spots_total` in a way that\nmatches your business logic.\n\nIf a restaurant supports combining tables to form a larger party, you can\nupdate your `spots_open` and `spots_total` to reflect this.\n\nSay a restaurant can combine two small tables to seat a party of 7-10\npeople.\n**Figure 3:** Floor plan with no active bookings\n\nIn the case of no active bookings, the values for `party_size`, `spots_open`,\nand `spots_total` are:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 3 | 3 |\n| 5 | 3 | 3 |\n| 6 | 4 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n| 9 | 1 | 1 |\n| 10 | 1 | 1 |\n\nNow, with the same floor plan, a booking is made for a party size of 10 that\ncombines two small tables.\n**Figure 4:** Floor plan with one active booking spanning two tables\n\nThen, the values for `party_size`, `spots_open`, and `spots_total` are now:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 1 | 3 |\n| 5 | 1 | 3 |\n| 6 | 2 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n| 9 | 0 | 1 |\n| 10 | 0 | 1 |"]]
