Как доработать действующий сайт при открытии филиалов в других городах

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

При этом создавать новый сайт для каждого филиала обычно необязательно.

Во многих случаях существующий проект можно доработать:

• добавить управление подразделениями,
• изменить формы заявок,
• настроить передачу обращений,
• разграничить доступ сотрудников.

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

Почему старый сайт начинает мешать работе филиалов

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

После открытия нескольких подразделений появляются дополнительные условия.

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

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

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

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

Что необходимо предусмотреть на сайте филиальной сети

Объём изменений зависит от того, насколько самостоятельно работают подразделения.

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

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

Единый раздел с филиалами

Посетитель должен иметь возможность быстро найти подходящее подразделение.

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

Если подразделений много, удобнее предусмотреть поиск или фильтрацию по городу.

При этом отдельная страница каждого филиала имеет смысл не всегда.

Она полезна, если посетителю действительно нужна дополнительная информация:

• список специалистов,
• доступные услуги,
• особенности обслуживания,
• возможность записи.

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

В обоих случаях страница решает практическую задачу посетителя.

Различия в услугах и условиях работы

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

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

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

Избежать такой ситуации помогает связь между филиалом и доступными услугами.

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

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

Как правильно распределять заявки между филиалами

Это одна из наиболее значимых доработок для бизнеса.

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

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

Передача выбранного филиала

Предположим, клиент открыл страницу филиала в Томске и отправил заявку на обслуживание оборудования.

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

Без такой информации сотрудникам придётся самостоятельно определять, кому передавать запрос.

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

Это сокращает количество действий для посетителя и помогает сохранить контекст обращения.

Интеграция с CRM

Когда компания использует CRM, распределение заявок можно связать с существующими бизнес-процессами.

Например, обращения из одного филиала поступают определённой группе менеджеров, а из другого — сотрудникам соответствующего подразделения.

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

- Что делать, если клиент выбрал город, но нужной услуги там нет? 

- Кому передавать заявку, если подразделение временно закрыто? 

- Кто отвечает за обращения из городов, где компания ещё не открыла филиал?

На эти вопросы сначала должен ответить бизнес. Разработчик уже на основании согласованных правил настраивает техническую логику.

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

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

Телефонные обращения тоже нужно учитывать

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

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

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

Главное, чтобы посетитель попадал к сотруднику, способному решить его вопрос.

Как организовать управление филиалами в CMS

CMS — система управления содержимым сайта. Через неё сотрудники добавляют страницы, меняют тексты, изображения, цены и другую информацию.

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

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

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

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

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

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

Нужна ли новая CMS

Само открытие филиалов не означает, что существующую систему управления обязательно нужно менять.

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

Иногда необходимые функции можно добавить без смены платформы.

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

В таком случае стоит сравнить два сценария: доработку существующей системы и переработку отдельных компонентов.

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

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

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

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

Поэтому иногда требуется разграничение прав.

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

Это особенно полезно, если подразделения самостоятельно обновляют данные.

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

Выбор зависит от реальной организации работы.

Что происходит при открытии, переезде или закрытии филиала

Обычно при разработке думают о том, как добавить новое подразделение. Но работающая сеть постоянно меняется.

Филиал может переехать, временно прекратить обслуживание клиентов, изменить график или закрыться.

Если сайт не предусматривает такие ситуации, посетители продолжают видеть устаревшую информацию.

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

Поэтому полезно предусмотреть несколько состояний филиала:

• работает,
• готовится к открытию,
• временно закрыт,
• прекратил деятельность.

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

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

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

Можно ли сохранить существующий дизайн и структуру

Во многих случаях да.

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

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

При этом некоторые элементы интерфейса действительно могут потребовать переработки.

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

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

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

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

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

От чего зависит стоимость доработки

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

Представим две ситуации.

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

Для неё может оказаться достаточно одного раздела, обновления контактов и небольшой настройки форм.

Вторая компания тоже открыла три подразделения. Однако каждое самостоятельно обрабатывает заявки, управляет сотрудниками, устанавливает условия обслуживания и работает со своими данными в CRM.

Здесь потребуется более сложная логика.

На стоимость влияют:

• состояние действующего сайта и его CMS;

• количество различий между филиалами;

• необходимость индивидуальных страниц и интерфейсов;

• правила распределения обращений;

• интеграции с CRM, телефонией и другими системами;

• права доступа сотрудников.

При этом количество филиалов само по себе не определяет сложность проекта.

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

До начала разработки полезно разделить работы на обязательные для открытия филиалов и те, которые можно выполнить позднее.

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

Как проверить сайт перед открытием нового филиала

Проверку стоит проводить на реальных сценариях, а не ограничиваться просмотром страниц.

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

Для этого полезно выполнить несколько проверок.

1. Найти филиал с главной страницы и из раздела контактов.

2. Проверить адрес, телефон, график и доступные услуги.

3. Открыть сайт на смартфоне и пройти основной сценарий обращения.

4. Отправить тестовые заявки из разных филиалов.

5. Убедиться, что CRM или почта получает правильные сведения о подразделении.

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

7. Посмотреть, что произойдёт, если филиал временно перестанет принимать заявки.

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

После запуска необходимо контролировать не только техническую работу форм, но и фактическую обработку обращений.

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

Когда достаточно небольшой доработки, а когда нужен полноценный проект

Оценивать масштаб работ лучше после изучения действующего сайта.

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

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

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

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

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

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

Поэтому начинать разумнее с проверки действующей системы, а не с заказа нового сайта.