47 URL, многофилиальный WordPress-сайт дневного спа за 103 дня

Клиент (конечный пользователь): Radiant Day Spa — Bend, Oregon (с филиалами в Sisters и Jacksonville)
Формат сотрудничества: White-label разработка для маркетингового агентства из США
Сроки: сентябрь – декабрь 2025 · 103 дня · 138 часов на разработку и длинный хвост правок и обратной связи

Подход к разработке

Wellness-сайт на 47 URL для дневного спа с тремя филиалами в Орегоне — где конверсионным примитивом была не одна контактная форма, а схема бронирования 33 процедуры × 3 филиала со ссылками Square Appointments на каждую услугу. Агентство на тестовой среде заметило, что все кнопки «Book Now» вели на общий список услуг филиала, а не на конкретную процедуру — потребовалась перелинковка каждой процедуры, чтобы гость, листая меню услуг, попадал на правильный Square-виджет.

Краткий обзор

Постановка задачи

Маркетинговое агентство из США, нанятое Radiant Day Spa — Wellness-практикой с тремя филиалами в центральном Орегоне (Bend, Sisters и Jacksonville) — передало нам таблицу Google Sheets с картой сайта на 49 строк (47 уникальных URL), 14-шаблонную библиотеку в Figma, контрольный список запуска на 30 строк с колонками Development / Pre-Launch / Both, вкладку AutoQA Setup для проверки тестовой среды и две пустые вкладки очередей задач (DEV — для задач разработчиков, CX — для клиентского опыта).

Сайт разворачивался на Kinsta-окружении агентства; SEO — Rank Math Pro; производительность — WP Rocket; а конверсионный примитив — то, ради чего посетитель заходит на сайт, — набор виджетов Square Appointments, по одному на филиал. Figma содержала дизайн главной и страниц процедур.

Задача была однофазной разработкой с длинным хвостом согласования: построить все 47 URL в девяти шаблонах агентства; реализовать многофилиальную логику бронирования так, чтобы кнопка «Book Now» каждой процедуры вела на правильный виджет (прямая ссылка для услуг, доступных только в одном из Bend / Sisters / Jacksonville, и всплывающий выбор для услуг в двух-трёх филиалах); затем, в течение нескольких недель на тестовой среде, параллельно отработать очереди задач DEV и CX и закрыть контрольный список запуска.

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

Риск, от которого агентство страховалось white-label-партнёром, был не в том, сможет ли кто-то собрать страницы на Kinsta, а в том, приведёт ли запись на боевом сайте гостя из Sisters, нажавшего «Book Now» на процедуре в Sisters и Bend, к правильному виджету Square — без того, чтобы агентство или конечный клиент держали эту логику в голове. Главный риск разработки — непрерывность записи при работе по нескольким филиалам; бриф был составлен так, чтобы именно это стало основной задачей, а не примечанием на полях.

Это была новая разработка «с нуля», без унаследованных URL и без миграции. Здесь нет «состояния до», которое можно сравнить, нет позиций в выдаче, которые нужно сохранить, нет карты редиректов. Есть таблица Google Sheets, которую составило агентство, есть тестовая среда, которую мы построили по ней, и есть боевой сайт, который был введён в эксплуатацию.

Как мы это сделали

1. Девять шаблонов, 47 URL, один процесс. URL Radiant Day Spa распределились по девяти из 14 стандартных шаблонов агентства: Homepage (1), Services Lander — лендинг меню услуг (1), Service Page (33 — самый объёмный, по одному на процедуру), Location (4), About Us (3 — по одному на филиал), Reviews (3 — по одному на филиал), Blog Lander (1), Blog (1), Loyalty Program (1).

Каждый URL был построен на назначенном шаблоне по строке карты сайта; ничего не делалось вручную вне шаблонной системы. В библиотеке агентства есть также шаблон Doctor Page — уместный на медицинском сайте, но не на сайте дневного спа, где конверсионные страницы — это меню процедур, а не профили специалистов, — и мы его не применяли.

2. Таблица Google Sheets — это контракт, включая оценку часов по строкам. Во вкладке Sitemap таблицы Google Sheets каждая строка содержала оценку часов (главная — 12 часов, About Us — по 0,5 ч, страницы процедур — обычно 1 ч, лендинг услуг и страницы филиалов — дороже). Сумма этих значений составляла оценку разработки; проектная оценка в 138 часов включала эту сумму плюс бюджеты на QA, проектное управление и согласование после тестовой среды. И то, и другое сошлось с фактическими затратами.

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

3. Многофилиальная схема бронирования. Это была ключевая индивидуальная разработка в проекте. Каждая из 33 процедур содержала флаг доступности по филиалам — BD (Bend), SS (Sisters), JV (Jacksonville) или их комбинацию. Механизм «Book Now» работал по-разному: для услуги в одном филиале — прямая ссылка на Square-виджет этого филиала; для двух-трёх филиалов — всплывающий выбор с вариантом для каждого, и каждый вариант с собственным Square-кодом. Мы реализовали матрицу один раз по спецификации агентства, вывели её в шаблон Service Page через небольшой набор произвольных полей, привязанных к флагам BD/SS/JV, и затем отстаивали её через обе QA-очереди задач, пока агентство добавляло, удаляло и перемаркировало процедуры в длинном хвосте.

Мы выбрали подход с произвольными полями, а не отдельные страницы для каждой процедуры по филиалам, потому что таблица Google Sheets содержала 33 процедуры с пересекающимися флагами — хранение каждой процедуры на одном URL с маршрутизацией в произвольных полях удержало количество шаблонов на уровне 9, а не умножило его на число филиалов, предлагающих каждую услугу. Виджет бронирования — Square Appointments — находится в строке «Технологии» раздела «Краткий обзор» не случайно: на Wellness-сайте это конверсионный примитив, как Gravity Forms на медицинском сайте.

4. Два параллельных QA-цикла через длинный хвост обратной связи на тестовой среде. Задачи отслеживались в двух очередях задач агентства: очередь задач разработки (вкладка «Ошибки DEV») — для задач, влияющих на разработку (регрессии вёрстки, битые ссылки, отсутствующие строки контента, замены изображений, пограничные случаи схемы бронирования по мере их выявления). Очередь задач CX (вкладка «Ошибки CX») — для задач на стороне аккаунта агентства (правки текстов, запросы на замену изображений, коррекция голоса бренда, контентные запросы по филиалам, направляемые конечному клиенту).

Из 49 DEV-задач 26 закрыты как Completed; 10 в QA (ожидают подтверждения агентства или конечного клиента), 9 To Do, 3 In Progress, 1 зависла на Info Needed к моменту передачи. Из 51 CX-задачи 19 закрыты как Completed (ещё одна отмечена как закрытая); 15 в QA, 3 To Do, 1 In Progress, 13 на Info Needed в ожидании решений агентства или конечного клиента. Контрольный список запуска на 30 строк — Development / Pre-Launch / Both — закрыт на 24 согласованных пункта, оставшиеся шесть также зависели от тех же Info Needed-ожиданий.

Задача #1222 — «Логика Book Now» — стоила 14 часов при оценке 4 часа, перерасход в 3,5 раза, который показывает, где на самом деле была нагрузка проекта. Согласование схемы бронирования, а не вёрстка страниц, потребовало основного времени; две параллельные QA-очереди задач, работавшие рядом с ним 103 дня, удерживали все остальные правки в открытом доступе, а не откладывали их в тихую очередь задач.

Результаты

Результат, если коротко: 47-URL многофилиальный сайт дневного спа для агентства сдан на 9 шаблонах на Kinsta в рамках бюджета 138 часов. Две QA-очереди задач работали параллельно через длинный хвост согласования; 45 из 100 заведённых задач закрыты как Completed до окончания нашей работы, остальные разделены между текущим QA и ожиданиями статуса «Info Needed» решений агентства или конечного клиента. Контрольный список запуска закрыт на 24 из 30 согласованных пунктов; боевой сайт введён в эксплуатацию в конце 103-дневного окна.

Контроль качества

Перед первой проверкой агентства на исходной сборке был запущен Site Checker — QA показал открытые замечания («надо чекера и исправить косяки», чат #963, 2025-09-23) — а проход агентства после передачи затем выявил #1222, показавшую, что все кнопки «Book Now» в матрице из 33 процедур вели на общий список услуг филиала в Square, а не на URL конкретной процедуры.

QA перед сдачей прошёл через Site Checker — см. наш подход к QA с категориями и принципом нулевых ошибок. Собственный QA агентства — их инструменты, их процесс — работал после передачи и добавлял задачи в общую очередь задач для нашего цикла исправлений до согласования.

Процесс

Фазы значительно перекрываются — работа над схемой бронирования началась до завершения первого прохода по всем Service Page, а хвост согласования DEV/CX шёл параллельно с ними, поэтому 103 календарных дня существенно меньше суммы длительностей отдельных фаз.

Команда

Команда проекта

• Никита Тумашевич — ведущий разработчик в фазе сборки и реализации многофилиальной схемы бронирования
• Павел Сажин — QA-итерации и правки в обеих очередях задач DEV и CX
• Тимур Арбаев — поддержка QA, основная ответственность за длинный хвост согласования (крупнейший QA-вклад в проекте)
• Людмила Травкина — QA-проход и координация до сдачи проверки
• Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с агентством, согласование)

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

Агентствам, заказывающим разработку WordPress