Ниже описаны подробности процесса сквозной интеграции резервирования Центра действий.
Интеграция
Следуйте стандартному процессу высокоуровневой интеграции, описанному в руководстве по сквозной интеграции .
![Обзор адаптации для сквозной интеграции Reservations.](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/reserve_with_google_integration.png?authuser=0000&hl=ru)
Ключевые оговорки. Комплексное руководство
Следующий обзор пунктов представляет собой примеры и руководство, охватывающее ключевые функции, необходимые для сквозной интеграции резервирования:
- Каналы:
- Комплексная интеграция резервирования требует ежедневной отправки данных о продавцах, услугах и доступности через SFTP.
- В фидах продавцов важно, чтобы имя, адрес, номер телефона и URL-адрес каждого местоположения точно совпадали со списком Google, чтобы сопоставление было успешным.
- Продавцы в резервировании End-to-End могут использовать только одну службу для отображения доступности.
- Рекомендуется установить одинаковое статическое значение service_id для всех ваших продавцов, если бронирование является единственной услугой, предоставляемой вашими продавцами. Если применимо, укажите scheduling_rules и cancel_policy в фиде услуг.
- Главным отличием сквозного инвентаря Reservations является необходимость определить party_size для всей доступности. Для получения дополнительной информации обратитесь к этим руководствам:
- Сервер бронирования:
- Сервер бронирования действует как точка входа Google для подтверждения доступности, а также для создания, обновления, удаления и изменения бронирований, сделанных через поверхности Google.
- Чтобы обеспечить положительное взаимодействие с пользователем, мы требуем, чтобы ваш ответ на каждый из этих запросов не превышал наших пороговых значений частоты ошибок и задержки.
- Примеры запросов/ответов см. в следующих руководствах:
- Стандартная интеграция: реализация стандартной интеграции с сервером бронирования .
- Интеграция списка ожидания: реализация интеграции с сервером бронирования списка ожидания .
- Обновления в реальном времени:
- Хотя это и не обязательно, обновления в режиме реального времени могут позволить вам асинхронно отправлять нам обновления об отмене бронирования или изменении доступности до того, как пользователь попытается получить доступ к вашей доступности. Это приводит к тому, что в случае сбоя BatchAvailabilityLookup пользователям будет показано меньшее количество незабронированных слотов. Для получения дополнительной информации ознакомьтесь с нашей документацией по структурированию обновлений в реальном времени .
- Дополнительные замечания:
- Если размер файла фида доступности (после сжатия) превышает 200 МБ, необходимо сегментирование , чтобы разделить фид на файлы размером менее 200 МБ (сжатые).
- Продавцы в резервировании End-to-End могут иметь только одну услугу.
Дополнительные комплексные функции резервирования
Это функции, которые следует учитывать при выполнении комплексной интеграции системы бронирования. Ничего из этого не требуется, но многие из них потребуются, чтобы убедиться, что Центр действий следует бизнес-логике вашей компании при обслуживании вашего инвентаря:
- Бронирования, требующие одобрения ресторана (асинхронное бронирование)
- Добавление секций для сидения
- Добавление окон отмены
- Списки ожидания
- Сборы/депозиты за неявку
- Установка минимального времени предварительного бронирования