WooCommerce Bookings - Плагин WordPress

Руководство по настройке WooCommerce Bookings для бронирований, записей и аренды

WooCommerce Bookings нужен не просто для того, чтобы добавить календарь на страницу товара. Его реальная ценность раскрывается тогда, когда магазин умеет принимать записи на услуги, бронирование времени, аренду оборудования, групповые занятия и ресурсы с ограниченной доступностью без ручной переписки с каждым клиентом.

В этом руководстве разберём, как подойти к настройке плагина после установки: какие требования проверить, как создать первый бронируемый товар, чем отличаются фиксированные и пользовательские интервалы, где задаются правила доступности, как работают участники, ресурсы, стоимость, подтверждение, отмена и связь с заказами WooCommerce.

Материал не заменяет официальную документацию, но помогает собрать её в практический рабочий сценарий. После чтения вы сможете безопасно проверить WooCommerce Bookings на тестовом товаре, понять типичные причины пустого календаря, настроить ресурс без двойного бронирования и решить, подходит ли этот плагин для вашего магазина.

Когда плагин действительно решает задачу магазина

WooCommerce Bookings лучше всего раскрывается в проектах, где уже есть логика WooCommerce: карточки товаров, корзина, оформление заказа, письма, статусы заказов, купоны, налоги и привычная админ-панель магазина. Плагин добавляет к этой системе новый тип товара - Bookable product. Такой товар продаёт не только единицу товара, а время, слот, дату, длительность, место, специалиста, комнату или другой ограниченный ресурс.

На практике это удобно для салона, консультаций, мастер-классов, аренды студии, экскурсионных туров, проката оборудования, занятий с ограниченным числом участников, бронирования помещения или онлайн-сессий. Важно, что клиент проходит привычный путь WooCommerce: выбирает дату и параметры, добавляет бронирование в корзину, оформляет заказ, получает письма и видит запись в своей истории заказов.

Главный критерий выбора - насколько ваш сценарий похож на товар с календарём. Если вы продаёте услугу, которая должна попадать в заказ WooCommerce, учитывать оплату, письма и статусы, WooCommerce Bookings обычно логичнее отдельной внешней системы записи. Если же вам нужен независимый расписатель с личными кабинетами сотрудников, сложными сменами, отдельной клиентской базой и глубокой автоматизацией уведомлений, стоит заранее сравнить его с специализированными appointment-плагинами.

Типовые сценарии, где Bookings уместен

• Запись на консультацию или услугу с фиксированной длительностью, например 30 или 60 минут.
• Бронирование занятия, тура или мастер-класса с ограничением по числу участников.
• Аренда помещения, оборудования или транспорта на часы, дни или другой подтверждённый интервал.
• Продажа услуги с ресурсом, который нельзя выдать двум клиентам одновременно: сотрудник, зал, камера, лодка, кабинет.
• Сценарии, где нужно подтверждение менеджером перед оплатой или финальным статусом бронирования.

Плагин может быть лишним, если у вас всего одна простая форма заявки без оплаты и без календарной логики. В таком случае обычная форма обратной связи, календарь встреч или CRM-виджет будут проще. WooCommerce Bookings стоит внедрять тогда, когда календарь влияет на продажу, доступность и выполнение заказа.

Что проверить перед установкой и первым тестом

Перед установкой важно проверить не только сам ZIP-файл, но и окружение. WooCommerce Bookings завязан на WooCommerce, работу WordPress, корректные постоянные ссылки, почту, фоновые задачи и оформление заказа. Если один из этих слоёв работает нестабильно, календарь может открываться, но слоты будут исчезать, зависать в корзине или неправильно отображаться для клиента.

Официальная документация указывает базовые требования к PHP, WordPress, WooCommerce и рабочему WP-Cron. В статье не фиксируем номера версий, потому что они меняются, но перед установкой обязательно сверяйте текущие требования на странице продукта и в документации WooCommerce. Особенно внимательно проверьте WP-Cron: он участвует в очистке бронирований, которые были добавлены в корзину, но не завершились заказом.

Мини-чеклист до активации

• WooCommerce установлен, активирован и уже проходит обычный тестовый заказ на простом товаре.
• Постоянные ссылки WordPress включены не в режиме Plain, особенно если планируется REST API или внешняя интеграция.
• Почта сайта работает: письма WooCommerce доходят хотя бы на тестовый адрес администратора.
• Кеш-плагин, CDN и оптимизация JavaScript не ломают корзину, оформление заказа и AJAX-запросы WooCommerce.
• Тема корректно выводит стандартную страницу товара WooCommerce, цену, кнопку добавления в корзину и блоки товара.
• У администратора есть доступ к разделам Products, WooCommerce, Bookings и настройкам заказов.

Проверка перед установкой: сначала сделайте тестовый заказ на обычном товаре WooCommerce. Если письма, корзина или checkout уже работают с ошибками, бронируемый товар только усложнит диагностику.

Если исходная страница скачивания не является официальной страницей WooCommerce, используйте её только как точку входа к задаче, а факты о функциях и совместимости сверяйте с WooCommerce.com и документацией. Так вы не перенесёте в рабочий сайт устаревшие сведения о требованиях, интерфейсе или возможностях плагина.

Установка и первичная проверка в админ-панели WordPress

В обычном сценарии плагин устанавливается как любой коммерческий плагин WordPress: через Plugins и загрузку архива, либо через механизм WooCommerce.com, если сайт связан с аккаунтом. В этом руководстве не разбираем покупку, ключи лицензии или получение платной версии. Цель - настроить и проверить уже имеющийся установочный файл без вмешательства в ядро WordPress или WooCommerce.

После активации проверьте, что в админ-панели появились разделы Bookings и новые возможности в данных товара. Самый быстрый тест - открыть Products, создать черновой товар и посмотреть выпадающий список Product data. В нём должен появиться тип Bookable product. Если его нет, не переходите к сложной настройке: сначала проверьте активность WooCommerce, конфликт плагинов и права пользователя.

Первый безопасный тест после активации

1. Откройте Products и создайте черновой товар с понятным названием, например тестовая консультация.
2. В блоке Product data выберите Bookable product.
3. Если услуга не требует доставки, включите Virtual, чтобы убрать лишние настройки доставки.
4. Задайте простую фиксированную длительность и минимальную доступность на ближайшие дни.
5. Опубликуйте товар временно в закрытой категории или используйте режим предпросмотра, если он подходит для вашей проверки.
6. Откройте товар в отдельном окне без прав администратора и убедитесь, что календарь появляется на странице.

На этом этапе не нужно сразу подключать ресурсы, разные типы участников, сложные правила стоимости и интеграции. Сначала добейтесь простого результата: календарь есть, слот выбирается, товар попадает в корзину, заказ создаётся. Только после этого переходите к правилам, которые могут конфликтовать друг с другом.

Как устроен бронируемый товар: длительность, календарь и подтверждение

Основа WooCommerce Bookings - не отдельная форма, а товар WooCommerce с расширенной логикой времени. В обычном товаре магазин спрашивает количество и вариант. В бронируемом товаре клиент выбирает дату, время, длительность, участников и иногда ресурс. Поэтому настройка начинается с вопроса: что именно продаётся - фиксированный слот, произвольный отрезок времени, день аренды, несколько дней или место в групповом событии.

Фиксированные и выбранные клиентом блоки

Фиксированный блок подходит для услуги с заранее известной длительностью. Например, консультация длится один час, экскурсия - два часа, занятие - 90 минут. Клиент выбирает только доступный старт, а длительность определяется магазином. Такой режим проще проверять и меньше даёт ошибок, потому что каждый слот одинаковый.

Пользовательская длительность нужна, когда клиент сам выбирает, сколько блоков ему нужно: аренда переговорной на несколько часов, прокат оборудования на дни, бронирование рабочего места на часть дня. В этом случае особенно важны минимальная и максимальная длительность. Если они не заданы осмысленно, клиент может выбрать слишком короткий или слишком длинный интервал, а доступность станет непредсказуемой.

Как выбрать длительность без конфликтов

• Для услуг с жёстким расписанием используйте фиксированные блоки.
• Для аренды, где клиент определяет продолжительность, используйте клиентскую длительность с минимальным и максимальным пределом.
• Не делайте блок короче реального времени обслуживания, если после бронирования нужен перерыв или уборка.
• Сразу учитывайте буфер между записями, иначе календарь формально будет заполнен, но менеджер не успеет выполнить услугу.

Подтверждение администратором

Опция подтверждения полезна, когда бронирование нельзя автоматически принять сразу: требуется проверить сотрудника, помещение, заявку клиента или наличие дополнительного оборудования. В этом режиме клиент не проходит обычную оплату сразу, а отправляет запрос на доступность. После одобрения администратором клиент получает письмо для дальнейшего действия.

Важный нюанс: бронирования, требующие подтверждения, ведут себя не как обычная покупка с несколькими товарами в корзине. Документация WooCommerce описывает отдельный сценарий Check Availability, при котором такой товар может оформляться отдельно. Поэтому не стоит смешивать подтверждаемые бронирования с обычной корзиной, пока вы не проверили реальный checkout.

Отмена клиентом

Разрешение на отмену стоит включать только с понятным временным порогом. Для консультации это может быть одно значение, для аренды помещения - другое. Слишком свободная отмена создаёт операционный риск, а слишком строгая - увеличивает нагрузку на поддержку. В статье не задаём универсальное число: правильный предел зависит от того, успеваете ли вы перепродать слот и несёте ли расходы до начала услуги.

Правила доступности: почему календарь показывает или скрывает слоты

Большинство ошибок в WooCommerce Bookings связано не с установкой, а с доступностью. Плагин учитывает несколько уровней правил: общую доступность магазина, доступность конкретного товара и доступность ресурсов. Если эти уровни противоречат друг другу, календарь может выглядеть пустым даже при правильно созданном товаре.

Думайте о доступности как о фильтре. Сначала магазин задаёт общий режим работы. Затем товар уточняет, когда именно его можно бронировать. Потом ресурс может ещё сильнее ограничить слот, если этот сотрудник, зал или объект занят. Итоговый слот появляется клиенту только тогда, когда все применимые правила позволяют его выбрать.

Настройки, которые стоит проверить первыми

Если календарь пустой, не меняйте все правила подряд. Выберите одну тестовую дату, один товар и один ресурс. Временно упростите правила до минимального набора, проверьте слот, затем возвращайте ограничения по одному. Такой подход быстрее, чем хаотично переключать доступность на всех уровнях.

Стоимость, участники и ресурсы в WooCommerce Bookings

После простой проверки календаря переходите к тому, что делает WooCommerce Bookings сильнее обычного календаря: стоимость может зависеть от длительности, дня, времени, числа участников и выбранного ресурса. Здесь важно не пытаться сразу описать всю бизнес-логику одним товаром. Чем больше условий вы добавляете, тем сложнее проверить, почему клиент видит именно такую цену.

Стоимость бронирования

В бронируемых товарах есть базовая стоимость и стоимость блока. Базовая применяется к бронированию как к событию, а блочная зависит от количества выбранных блоков. Дополнительные правила позволяют менять цену для отдельных дат, временных диапазонов, групп или условий. Это полезно для выходных, вечерних часов, сезонных периодов и скидок за длительность, но каждое правило должно иметь проверяемую причину.

Хорошая практика - сначала настроить один простой тариф, сделать тестовый заказ и только затем добавить одно ценовое правило. После каждого изменения открывайте товар как клиент, выбирайте дату и смотрите, меняется ли итоговая стоимость. Если цена не совпадает с ожиданием, легче откатить последнее правило, чем разбирать сразу десять условий.

Участники и типы персон

Опция Has Persons нужна, если стоимость или вместимость зависит от количества людей. Для группового тура можно задать минимум и максимум участников. Для семейного мероприятия можно разделить взрослых и детей, если источники и настройки вашего товара подтверждают такую логику. При этом участники не всегда равны отдельным бронированиям: в настройках есть режим, при котором каждый человек учитывается как занятие вместимости.

Для магазина это критично. Если экскурсия вмещает 25 человек, одно бронирование на 10 участников должно занять 10 мест, а не один слот. И наоборот, если вы продаёте одну комнату для группы, количество людей может влиять на цену, но не должно превращать комнату в несколько независимых ресурсов. Перед запуском обязательно проверьте оба варианта на тестовом заказе.

Ресурсы и защита от двойного бронирования

Ресурс - это то, что нельзя использовать одновременно в двух бронированиях. Это может быть сотрудник, кабинет, студия, лодка, камера, автомобиль или любой другой ограниченный объект. WooCommerce Bookings позволяет связать ресурсы с товарами и управлять их доступностью отдельно от самого товара.

Есть два полезных режима. В одном клиент сам выбирает ресурс, например конкретный зал или тип комнаты. В другом ресурс назначается автоматически, если он свободен. Автоматическое назначение удобно для салона или сервиса, где клиенту не принципиален конкретный сотрудник, а магазину важно заполнить расписание без ручного выбора.

Практическая проверка ресурса: создайте два товара, которые используют один и тот же ресурс, сделайте тестовое бронирование на первом товаре и убедитесь, что второй товар не предлагает тот же ресурс на занятое время.

Как собрать реальный сценарий: запись на мастер-класс с участниками и ресурсом

Разберём предметный пример, который хорошо показывает логику WooCommerce Bookings. Допустим, магазин продаёт места на мастер-класс в студии. Есть ограниченная вместимость, несколько временных слотов, разная стоимость для взрослых и детей, один зал как ресурс и необходимость оставить буфер между занятиями.

Цель сценария

Нужно получить товар, где клиент выбирает дату и время, указывает количество участников, видит корректную стоимость, добавляет бронирование в корзину и оформляет заказ. Администратор должен видеть запись в заказах и календаре, а выбранный зал не должен стать доступным для другого занятия в то же время.

Подготовка

• WooCommerce уже создаёт обычный тестовый заказ без ошибок.
• Плагин активирован, тип Bookable product доступен в данных товара.
• Создан ресурс, например зал студии, если он должен блокироваться между товарами.
• Определены реальные слоты: длительность занятия, время подготовки, максимальное число участников.

Шаги настройки

1. Создайте новый товар и выберите Bookable product.
2. Включите Virtual, если физическая доставка не нужна.
3. В разделе длительности задайте фиксированный блок, соответствующий продолжительности занятия.
4. В доступности укажите дни и время, когда мастер-класс действительно проводится.
5. Добавьте буфер, если между занятиями нужна уборка, подготовка или перерыв сотрудника.
6. Включите Has Persons, задайте минимальное и максимальное количество участников.
7. Если взрослые и дети стоят по-разному, настройте типы персон и проверьте цену на нескольких комбинациях.
8. Включите Has resources и назначьте зал, если помещение должно блокироваться для других товаров.
9. Опубликуйте товар и откройте его в приватном окне браузера как обычный клиент.

Проверка результата

Выберите дату, время и участников. Убедитесь, что цена меняется предсказуемо, кнопка добавления в корзину доступна, заказ создаётся, а запись появляется в календаре Bookings. Затем попробуйте выбрать тот же зал и время на другом товаре, если он использует общий ресурс. Ожидаемый результат - занятый ресурс недоступен.

Если итоговая цена неожиданна, сначала проверьте, не сложились ли базовая стоимость, стоимость блока и правило по участникам. Если слот исчез, проверьте уровень ресурса и буфер. Если заказ создался, но бронирование осталось в промежуточном состоянии, посмотрите статус заказа и режим подтверждения.

Заказы, календарь, письма и ручное управление бронированиями

После оформления клиентом бронирование становится частью обычной операционной жизни магазина. Администратор работает не только с товаром, но и с заказом, статусом, календарём, письмами и иногда ручными бронированиями. Именно здесь WooCommerce Bookings удобен для магазинов, которые уже живут внутри WooCommerce: менеджеру не нужно держать отдельную систему, если сценарий укладывается в логику заказов.

Календарь администратора

Раздел Bookings помогает видеть записи в календарном виде, фильтровать их и открывать детали. Это полезно для проверки загруженности по дням, услугам и ресурсам. Но календарь не должен быть единственным источником контроля. При спорной ситуации всегда сопоставляйте запись с заказом WooCommerce, потому что оплата, письма и статус клиента проходят через заказ.

Ручное бронирование

Ручное добавление бронирования пригодится, когда клиент звонит, пишет в мессенджер или переносит запись через администратора. В таком случае менеджер может создать бронирование в админ-панели, выбрать товар, дату, клиента и связанный заказ. Перед использованием этой функции на рабочем сайте сделайте тест: ручная запись должна также блокировать слот, как и запись с публичной страницы товара.

Письма и напоминания

WooCommerce Bookings использует письма для разных этапов: новая запись, подтверждение, напоминание, отмена или запрос оплаты после подтверждения. Настройки писем лучше проверять вместе с обычными письмами WooCommerce. Если письма заказов не доходят, письма бронирований тоже могут пропадать или попадать в спам.

Для критичных услуг полезно отправить тестовое письмо на внешний адрес, а затем проверить тему, тело письма, дату, время, имя товара и ссылку для клиента. Не ограничивайтесь предпросмотром в админ-панели: письмо должно быть понятным в реальном почтовом клиенте.

Производительность, кеш и безопасные улучшения без правки плагина

Календарь бронирования чувствителен к кешу, оптимизации JavaScript, устаревшим фрагментам корзины и тяжёлым правилам доступности. Чем больше активных бронирований, ресурсов и правил, тем важнее тестировать скорость именно на странице бронируемого товара, а не только на главной странице сайта.

Первое правило - не кешировать динамический ответ календаря как обычную статическую страницу. Официальная диагностика WooCommerce Bookings прямо указывает на кеш и сессии WooCommerce как частые причины некорректных слотов. Поэтому страницы с календарём, корзину, оформление заказа и AJAX-запросы WooCommerce нужно исключать из агрессивной оптимизации, если она ломает выбор времени.

Что безопасно настроить в кеш-плагине

• Исключите страницы корзины, checkout и аккаунта из полного кеширования.
• Не объединяйте и не откладывайте скрипты WooCommerce Bookings без теста выбора слота.
• Проверьте календарь в приватном окне, чтобы не ориентироваться только на админскую сессию.
• После изменения кеша очистите кеш страницы, браузера, CDN и объектного кеша, если он используется.

Маленький документированный snippet для зависших бронирований в корзине

WooCommerce Bookings создаёт бронирование уже при добавлении в корзину, чтобы слот был зарезервирован и не достался другому клиенту. По документации такие записи имеют срок жизни и очищаются через WP-Cron. Если у магазина много незавершённых корзин, можно осторожно уменьшить время удержания слота через документированный фильтр. Делайте это только после теста: слишком короткий срок может удалить бронирование до завершения checkout.

Код вставляйте через дочернюю тему или безопасный плагин для snippets, не в файлы ядра WordPress и не в файлы WooCommerce Bookings.

<?php
/**
 * Уменьшает время удержания бронирования в корзине.
 * Используйте только после теста оформления заказа.
 */
function cb13168_change_incart_bookings_expiry_minutes( $minutes ) {
    return 30;
}
add_filter( 'woocommerce_bookings_remove_inactive_cart_time', 'cb13168_change_incart_bookings_expiry_minutes' );

После добавления откройте тестовый товар, положите слот в корзину, не завершайте заказ и проверьте, освобождается ли слот после заданного времени. Если клиенты не успевают оформить заказ, верните стандартное поведение: отключите snippet и очистите кеш.

Интеграции и дополнительные расширения вокруг бронирований

WooCommerce Bookings редко живёт в полной изоляции. В реальном магазине рядом с ним часто работают Product Add-Ons, Deposits, Product Vendors, Google Calendar, почтовые плагины, CRM-интеграции, кеш и аналитика. Ошибка многих внедрений - включить все расширения сразу и потом пытаться понять, какое из них изменило поведение календаря. Лучше строить систему слоями: сначала бронируемый товар, потом ресурс, затем оплата, после этого дополнительные поля и только в конце внешние интеграции.

Официальные материалы WooCommerce описывают несколько направлений интеграции. Product Add-Ons может добавить к бронируемому товару дополнительные опции, например оборудование, питание, сопровождение или другие услуги. Deposits может быть полезен, если бизнес принимает частичную оплату. Product Vendors важен для marketplace-сценариев, где поставщики участвуют в управлении предложениями. WooCommerce Bookings Availability выводит доступные слоты через блоки календаря или расписания на странице или в записи, но это отдельное расширение, а не обязательная часть основного плагина.

Как не сломать основной сценарий при подключении add-on

Перед включением дополнительного расширения зафиксируйте контрольный сценарий: какой товар тестируется, какая дата свободна, сколько стоит бронирование, какой ресурс блокируется и какое письмо приходит клиенту. После включения add-on повторите тот же путь. Если изменился checkout, итоговая цена, письмо или доступность, у вас будет точка сравнения.

Особенно осторожно подключайте дополнения, которые меняют корзину, оплату, статус заказа или поля товара. Они могут быть полезны, но должны быть проверены не на абстрактной странице, а на реальном bookable product. Например, дополнительная опция может корректно появиться на странице товара, но не попасть в ручное бронирование администратора или письмо клиента. Такой нюанс лучше поймать на тестовой копии.

Google Calendar и ожидания команды

Интеграция с Google Calendar помогает видеть бронирования вне админ-панели WordPress. Но её не стоит воспринимать как полноценную систему персональных календарей для каждого сотрудника без проверки ограничений. В официальной документации отдельно описан сценарий, где сайт синхронизирует бронирования с одним календарём администратора, а для нескольких календарей может потребоваться обходной путь через дополнительную интеграцию.

Если у вас один общий зал или один менеджер, такой режим может быть достаточным. Если есть пять сотрудников с разными графиками, личными календарями и переносами записей, сначала сделайте пилот на одном ресурсе. Проверьте, что запись появляется в календаре, время не смещается, отмена понятна команде, а ручное изменение в админ-панели не создаёт путаницу.

Когда нужен WooCommerce Bookings Availability

Основной WooCommerce Bookings показывает календарь на странице конкретного товара. Если пользователь должен видеть доступные даты сразу по нескольким бронируемым товарам, отдельным категориям или ресурсам, может понадобиться add-on WooCommerce Bookings Availability. Он добавляет блоки календаря и расписания для страниц и записей, чтобы клиент мог быстрее найти подходящий слот.

Этот add-on не должен становиться первым шагом настройки. Сначала проверьте, что каждый отдельный bookable product работает правильно. Только потом выводите общий календарь. Иначе вы будете диагностировать не сам add-on, а ошибки доступности, цены или ресурса, которые уже были в исходных товарах.

Локализация, понятные подписи и доверие клиента к календарю

Календарь бронирования должен быть не только технически правильным, но и понятным. Клиенту важно видеть, что именно он бронирует, на какой срок, когда начинается услуга, можно ли отменить запись и что произойдёт после оформления. Если подписи товара, письма и условия написаны расплывчато, поддержка получит вопросы даже при идеальной настройке доступности.

Начните с карточки товара. В коротком описании объясните, что входит в бронирование, как выбрать дату, нужно ли подтверждение менеджера и за сколько времени можно отменить запись. Если услуга онлайн, отдельно уточните часовой пояс или способ получения ссылки. Если это аренда, напишите, входит ли подготовка, доставка, залог или возврат. Не перегружайте карточку юридическим текстом, но уберите неоднозначность.

Что проверить в письмах

Письмо клиента должно отвечать на четыре вопроса: что забронировано, когда, какой статус сейчас и что делать дальше. Для подтверждаемого бронирования особенно важно объяснить, что запрос ещё не является финальной записью или оплатой, если именно так настроен товар. Для обычного оплаченного заказа письмо должно содержать дату, время, товар и понятный статус.

Проверьте не только письмо о заказе, но и письма, связанные с бронированием: подтверждение, напоминание, отмену и запрос оплаты после одобрения, если этот режим используется. Если шаблон письма переопределён темой, проверьте, что он не потерял дату бронирования или ресурс.

Мультиязычные сайты и формат времени

На мультиязычных сайтах важно разделять перевод интерфейса и данные бронирования. Название услуги, описание, условия и письма должны быть понятны на языке клиента. При этом системные настройки времени и часового пояса должны оставаться едиными и проверяемыми. Если посетители бронируют из разных стран, особенно аккуратно протестируйте отображение времени на публичной странице, в корзине, письме и календаре администратора.

Мини-итог перед публикацией: хороший календарь не заставляет клиента угадывать. Дата, длительность, цена, статус и следующий шаг должны быть понятны до обращения в поддержку.

Как проверить результат перед запуском на рабочем сайте

Проверка WooCommerce Bookings должна повторять поведение настоящего клиента и администратора. Недостаточно увидеть календарь на странице товара. Нужно пройти весь путь: выбор слота, цена, корзина, заказ, письмо, календарь администратора, занятость ресурса и повторная попытка выбрать тот же слот.

Сценарий сквозного теста

1. Откройте товар в приватном окне как гость.
2. Выберите дату, время, ресурс и участников, если они включены.
3. Сравните итоговую цену с ожидаемой логикой стоимости.
4. Добавьте бронирование в корзину и перейдите к оформлению заказа.
5. Создайте тестовый заказ разрешённым способом оплаты на вашем тестовом окружении.
6. Проверьте письмо клиента и письмо администратора.
7. Откройте календарь Bookings в админ-панели и найдите запись.
8. Попробуйте повторно выбрать тот же слот и убедитесь, что вместимость или ресурс учитываются правильно.

Что считать успешным результатом

Успешная настройка - это не только опубликованный товар. Клиент должен понимать, что он бронирует, какие даты доступны, сколько стоит выбранный вариант и что произойдёт после оформления. Администратор должен видеть запись, связанный заказ и ресурс. Если бронирование требует подтверждения, письмо и статус должны ясно объяснять следующий шаг.

Для сложных сценариев заведите отдельный чек-лист регрессионной проверки. Повторяйте его после обновления WooCommerce, темы, кеш-плагина и самого WooCommerce Bookings. Особенно это важно для магазинов, где один ресурс используется несколькими товарами.

Когда WooCommerce Bookings будет удачным выбором

WooCommerce Bookings стоит использовать, если ваш сайт уже работает как WooCommerce-магазин и бронирование должно быть частью товарной логики: клиент выбирает слот на странице товара, оплачивает через checkout, получает письма, а администратор видит заказ и запись в календаре. Особенно полезен плагин там, где есть ресурсы, участники, длительность, буферы и правила доступности.

Перед запуском не ограничивайтесь установкой. Создайте один тестовый товар, проверьте простой заказ, затем добавьте реальные правила доступности, стоимость, участников и ресурс. Отдельно протестируйте кеш, письма, WP-Cron и поведение занятых слотов. Такой порядок снижает риск, что ошибка обнаружится уже после первой заявки клиента.

Если после проверки сценарий совпадает с вашей моделью работы, можно скачать установочный файл, установить его на тестовую копию сайта и пройти полный сквозной тест до публикации бронируемых товаров. Если же главный фокус проекта - расписание сотрудников, многоуровневые appointment-формы или внешняя CRM-логика, сравните альтернативы до переноса клиентов на новый календарь.