Разработка 27-страничного сайта стоматологии с несколькими филиалами на WordPress за 140 дней

Клиент (конечный пользователь): Alta Dental Group — Irvine, CA
Формат сотрудничества: White-label разработка для маркетингового агентства из США
Сроки: май – сен 2025 · 140 дней · 63 часа на разработку и исправления

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

27-страничный сайт стоматологии с несколькими филиалами по макетам Figma — две клиники под одним брендом, один домен, свои номера телефонов у каждого филиала. Кнопка звонка, которая на мобильном звонила только в один офис, — потерянная точка конверсии, а не мелкая неточность. Работа заняла 63 часа за 140 дней и шла по двум параллельным очередям QA — 75 SEO-замечаний от агентства и 29 пунктов по CX.

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

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

Маркетинговое агентство из США, нанятое Alta Dental Group — стоматологической практикой с несколькими филиалами в Irvine, работающей под единым брендом — передало таблицу Google Sheets с полной картой URL, дизайн-файл Figma, каталог шаблонов, контрольный список запуска и предзаполненные QA-очереди задач. Разработка велась на их окружении WP Engine; конструктор страниц — Elementor; формы — Gravity Forms. Дизайн Figma содержал полную спецификацию бренда, включая анимацию перехода при прокрутке, которую клиент отметил ещё до начала разработки.

Задача: собрать 27 URL по стандартной библиотеке шаблонов агентства для стоматологии, применить дизайн-спецификацию Figma ко всем страницам, наполнить страницы услуг контентом от агентства и отработать две параллельные очереди QA — SEO и CX — до приёмки сайта агентством. При этом не выходить на прямой контакт с конечным клиентом; спорное возвращать агентству; не импровизировать с контентом, навигацией или распределением звонков по филиалам.

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

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

1. 9 шаблонов, 27 страниц, единый процесс сборки. Страницы Alta Dental Group распределились по стандартной библиотеке шаблонов агентства для стоматологии: Homepage, About Us (2 страницы — лендинг команды и дополнительная страница о нас), Contact Us, Services Lander, Service Page (17 отдельных страниц услуг, включая неотложную стоматологию, зубные импланты, эстетическую стоматологию, костную пластику и специализированные процедуры), Doctor Page (4 страницы врачей), Location и Default Template для страницы страхования, добавленной в процессе работы.

Каждая страница построена на назначенном шаблоне из карты сайта; ни одна страница не создавалась вручную вне системы шаблонов.

2. Спецификация соблюдена построчно — включая колонку Hours Estimated на страницу. Таблица Google Sheets агентства содержала оценку часов для каждой строки карты сайта — главная страница за 12 ч (самая трудоёмкая строка, отражающая спецификацию анимации), страница About / Our Team за 3,5 ч, страницы услуг за 0,5 ч каждая после формирования начального корпуса контента.

Мы реализовали всё в рамках этих значений. 12-часовая строка главной страницы была ключевой: дизайн Figma содержал анимации перехода при прокрутке, отмеченные клиентом, и их корректная реализация в стеке Elementor потребовала дополнительных итераций, которые бюджет строки предусматривал.

Коротко: при разработке с заранее оценённой картой сайта таблица — это контракт. Задача команды — уложиться в построчные бюджеты, а не открывать заново разговор о цене, когда сложная страница требует больше календарного времени, чем стандартная шаблонная.

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

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

4. Распределение звонков по двум филиалам проверили при сдаче. Ближе к концу проекта очередь QA выявила сбой маршрутизации: мобильная кнопка звонка по умолчанию вела на номер только одного офиса. Правка была не косметической — пришлось встроить в мобильную навигацию всплывающее окно выбора офиса, такое же, как в модальном окне «Call Us» на большом экране. Задача прошла два цикла QA до приёмки агентством, а страница страхования, добавленная в меню в тот же момент, закрылась в том же проходе QA.

5. Два параллельных цикла QA, закрытых до запуска. Замечания отслеживали в двух очередях агентства — SEO (75 строк) и CX (29 строк). Из 75 SEO-пунктов 73 закрыты как Completed до выгрузки данных; 1 остался Info Needed и 1 — To Do, в ожидании ответа от агентства. Из 29 CX-пунктов 26 закрыты как Completed; 1 был In Progress и 2 — Info Needed на момент выгрузки. Контрольный список запуска из 29 строк — колонки Design, Functionality, Content, Pre-Migration, Post-Migration — согласован до выхода в работу.

12-часовая строка главной — самая трудоёмкая в карте сайта, со спецификацией анимации перехода при прокрутке — задала темп всей разработки: сначала решаем самую сложную страницу, затем принимаем пачки контента под страницы услуг в рамках оставшихся строк. Именно этот порядок позволил закрыть две поставки контента и правку распределения звонков по двум офисам в рамках исходной оценки в 63 часа.

Результаты

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

Строка 30 очереди CX несла самую острую находку по маршрутизации за весь проект: мобильная кнопка звонка в правом верхнем углу была привязана только к одному офису. Пришлось сделать всплывающее окно выбора офиса и связать его с тем же модальным окном «Call Us», что уже работало на большом экране, — иначе пациенты звонили бы не в тот офис.

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

Процесс

Этапы пересекаются — пачки контента поступали во время первого QA-прохода, поэтому календарная длительность составила 140 дней, а не сумма отдельных этапов.

Команда

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

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

Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались у партнёрского агентства на всём протяжении. Конечный клиент нас не видел.

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