История: заказчик сам поправил код в админке и сломал форму заявки

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

Что произошло: желание сделать лучше и маленькая правка в коде

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

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

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

Как заметили: тишина, которую долго принимали за нормальный ритм

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

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

Во что это обошлось: три дня без обращений и немного нервов

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

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

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

Как восстановили: сначала возврат рабочей версии, потом разбор

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

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

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

Какие правила работы с админкой нужны: роли и границы допустимого

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

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

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

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

Копии и откат: страховка, которая должна быть настроена заранее

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

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

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

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

Тестовая заявка после каждой правки: самый дешёвый способ избежать беды

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

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

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

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

Как это связано с подходом 3 в 1

Сломанная форма в этой истории оказалась слабым звеном только одной из трёх точек. Заявки приходят из поиска, из карточки в Яндекс Бизнесе на Яндекс Картах и из карточки в 2ГИС. Когда форма на сайте не работает, остальные две точки продолжают приводить людей, причём именно те, кто хочет позвонить прямо из карточки. В этом смысле «3 в 1» работает как страховка: звонки с карт во время сбоя частично компенсируют потери.

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

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

Чек-лист в прозе: что должно быть у заказчика, который сам работает с сайтом

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

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

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

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

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

Вывод: самостоятельность хороша, когда есть страховка

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

Если вы работаете с сайтом сами или это делают ваши сотрудники, обратитесь к специалистам компании «Сайты Профессионально». Мы настроим роли и права в ХостСМС, организуем резервные копии, подключим оповещения о тишине в заявках и проверим, что обращения идут и с сайта, и с карточек в Яндекс Бизнесе и 2ГИС. Запишитесь на бесплатную консультацию, и мы вместе определим, какие правки можно доверять вам, а какие лучше оставить нам.