Уведомления менеджерам не включили после обновления сайта

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

Что именно технически сломалось при обновлении сайта

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

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

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

Как долго заявки продолжали оставаться незамеченными

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

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

Реакция клиентов на неожиданно долгую задержку с ответом

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

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

Как в итоге разобрались с истинной причиной

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

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

Почему такая проблема оказывается особенно коварной

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

Что обязательно стоит проверять после любого технического обновления

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

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

Разделение ответственности между подрядчиком и заказчиком

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

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

Как теперь тестируют обновления сайта

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

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

Резервная сводка как страховка на случай будущих сбоев

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

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

Итог

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

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