Что входит в техническую поддержку сайта автодилера

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

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

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

Наблюдение за работоспособностью и реакция на сбои

Первая задача поддержки — узнать о техническом сбое раньше клиента. Для этого настраивают мониторинг и оповещения.

В поддержку могут входить проверки:

• Доступности сайта

• Ошибок сервера

• Ошибок 404 на важных страницах

• Скорости загрузки

• Работы каталога

• Работы форм

• Доставки заявок в заданную систему

• Технических событий в аналитике

Ошибка 500 или 503 означает, что сайт не отвечает: сервер завис, обновляется модуль, произошел конфликт в коде или сломалась зависимость. Для клиента в этот момент важен понятный экран ошибки. Для команды — оповещение и порядок реакции.

Ошибка 404 менее заметна и не менее вредна. Посетитель пришел по ссылке из рекламы, рассылки, поиска или закладок, а страницы модели больше нет.

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

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

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

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

Регламентные обновления и безопасность

Статья

Сколько стоит разработка корпоративного сайта: бюджет дилерского проекта

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

На корпоративном сайте mts.by в рамках digital-поддержки маркетинга и корпоративного сайта ежеквартально обновляются ядро «Битрикс», версии PHP и MySQL, ведется мониторинг безопасности. Там же обновляются стилеобразующие элементы, когда меняется визуальная подача бренда.

В регламентные работы обычно входят:

• Обновления системы управления, библиотек, модулей и сертификатов

• Администрирование хостинга и инфраструктуры

• Резервное копирование

• Проверка восстановления после сбоя

• Мониторинг безопасности

• Проверка журналов ошибок

• Тестирование после обновлений

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

Для сайта дилера безопасность имеет отдельный вес. Через формы проходят персональные данные заявителей: имя, телефон, электронная почта, выбранная модель, дилерский центр, комментарий клиента. Утечка этих данных стоит дороже простоя.

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

Кейс

Прицепы в онлайне: тащим производителя техники в воронку продаж

Редизайн сайта, повышающий продажи.

Данные каталога и склад: регулярная часть поддержки

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

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

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

В поддержке можно закрепить проверки:

• Пришла ли выгрузка

• Сколько записей обработано

• Какие позиции не прошли

• Какие статусы не распознаны

• Не пропали ли автомобили из каталога

• Не выросло ли время обновления

• Не сломались ли фильтры и сортировка

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

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

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

Сопровождение форм и маршрутов заявок

Формы ломаются тихо. Счетчик посещений при этом остается прежним, рекламные кампании продолжают работать, а отдел продаж может перестать получать обращения.

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

В поддержке можно закрепить регулярные проверки:

• Отправляется ли форма

• Попадает ли заявка в нужную систему

• Сохраняется ли модель автомобиля

• Сохраняется ли выбранный дилерский центр

• Передается ли источник обращения

• Получает ли ответственная сторона техническое уведомление, если оно предусмотрено

• Фиксируется ли ошибка доставки

• Есть ли повторная отправка при сбое, если она заложена в проект

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

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

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

Что считается развитием и оплачивается отдельно

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

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

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

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

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

На mts.by в состав поддержки входят лендинги и новые шаблоны с нетиповой подачей. Такие задачи лучше считать отдельно от регламента: объем у них меняется от месяца к месяцу.

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

Платформа e-commerce на Laravel» Nineseven

Готовая e-commerce-платформа на Laravel для быстрого запуска и роста

Кто должен быть в команде поддержки

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

В поддержке должны быть закрыты несколько зон ответственности:

• Прием задач и связь с заказчиком

• Разработка и исправление ошибок

• Инфраструктура и хостинг

• Тестирование после правок и обновлений

• Безопасность

• Сопровождение интеграций

• Проверка складской выгрузки

• Проверка маршрутов заявок

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

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

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

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