Сайт компании в нескольких городах: как показывать нужные контакты и ассортимент

Что меняется после выбора города?

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

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

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

В документации 1С-Битрикс описана многосайтовость: несколько сайтов могут использовать одну установку и общие модули. Эта возможность подходит для связанных проектов, но региональные контакты, цены и правила обслуживания компания всё равно передаёт исполнителю отдельно. Установка не выбирает их за владельца.

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

Как предложить город без ошибочного решения?

Подсказка и явный выбор

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

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

Смена условий после переключения

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

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

Местный адрес и общий телефон

Один общий номер подходит централизованному отделу продаж, а адрес и график точки выдачи при этом остаются местными: человек звонит в общую команду, но приезжает за заказом в конкретное место. В 1С-Битрикс форма редактирования склада содержит данные о его расположении и работе. Поле «Адрес» определяет, куда приезжает покупатель. В списке контактов важно различать склад, офис продаж и место выдачи. Название города без пояснения роли адреса не поможет клиенту понять, где можно забрать заказ и куда обратиться за консультацией.

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

Поле «График работы» помогает показать часы посещения. Офис, выдача и приём звонков могут работать по разному расписанию, поэтому одно значение на весь город создаст неверное ожидание. В карточке контактов подпишите, к какому действию относится график. Поле «Сайт» связывает склад с выбранным сайтом установки, а не с любым переключателем города. Если проект использует один сайт с несколькими регионами, разработчик отдельно объясняет, как выбранный регион сопоставляется с точками выдачи. Эти связи стоит обсудить вместе с карточками контактов, чтобы адрес на странице относился к тому месту, которое действительно обслуживает посетителя.

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

Местный ассортимент и итоговая цена

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

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

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

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

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

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

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

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

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

Что происходит сразу после переключения?

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

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

В задании назовите различия городов, ожидаемое поведение при смене региона и получателя запроса: так разработчик предложит устройство сайта, а компания примет результат по тому, что увидит и получит клиент. При обсуждении разработки сайта с ШТАБ ИТ этот перечень поможет оценить работы, которые действительно меняют обслуживание посетителя.