Перенесли сайт на новый хостинг, а почта осталась на старом

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

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

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

Что оказалось

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

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

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

Никто не получал сообщений об ошибке. Отчёты о недоставке уходили на тот же несуществующий адрес.

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

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

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

Почему проблему не заметили раньше

Несколько обстоятельств сложились неудачно.

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

Уведомления о заявках дублировались в систему учёта — но дублирование тоже шло через почту. Оно сломалось вместе со всем остальным.

Менеджеры работали по звонкам. Телефон работал, и ощущения полной тишины не возникало.

Никто не проверил форму после переезда. Ни программист, ни сотрудники компании. Сайт открылся — значит, всё в порядке.

Статистика показывала, что всё хорошо. В Яндекс.Метрике цель «отправка формы» исправно срабатывала. Форма-то отправлялась. Что письмо не доходит, счётчик знать не мог.

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

Что делали дальше

Первое — срочно восстановили приём почты. Создали ящики на новом хостинге и проверили, что письма доходят. Это заняло около часа.

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

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

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

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

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

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

Как это связано с продвижением 3 в 1

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

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

Яндекс.Справочник. В карточке в Яндекс Бизнесе указан адрес электронной почты, и часть людей писала туда напрямую. Они получали отказ. Плюс отдельная неприятность: уведомления от самого сервиса — о новых отзывах, вопросах и предложенных правках — тоже перестали приходить. Компания на две недели ослепла в отношении своей карточки.

2ГИС. То же самое с адресом в карточке и с уведомлениями сервиса. Аудитория 2ГИС чаще звонит, поэтому здесь потери были меньше, но они были.

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

Почему обычная проверка не помогла бы

Здесь есть тонкость, из-за которой подобные аварии переживают даже внимательные компании.

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

Что он подумает? Скорее всего: «наверное, письмо идёт с задержкой» или «может, попало в спам». Посмотрит в спам, не найдёт, подождёт. Через полчаса отвлечётся на другие дела.

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

Но в этом случае и отчёты об ошибке уходили на несуществующий адрес.

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

Сколько это стоило в деньгах

Точную цифру компания вывести не смогла, но оценку сделала.

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

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

Стоимость предотвращения: пятнадцать минут на проверку формы после переезда и ещё час на настройку дублирования заявок.

Это соотношение стоит держать в голове, когда возникает желание сэкономить на приёмке работ.

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

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

Сначала — список. Все ящики, включая технические и забытые. Все сервисы, которые отправляют письма от имени домена.

Потом — резервная копия. Полная выгрузка содержимого всех ящиков к себе.

Потом — создание ящиков на новом месте. Старые при этом работают.

Потом — копирование переписки. Инструментами переноса или вручную через почтовую программу. Со старого сервера ничего не удаляется.

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

Потом — переключение записей приёма почты.

Потом — переходный период. Минимум неделю, лучше две, старые ящики остаются доступными: часть отправителей ещё шлёт письма на старый сервер.

Потом — досбор писем, пришедших на старый сервер за это время.

Потом — настройка отправки писем сайтом и записей подлинности отправителя.

И только потом — отключение старого хостинга.

Главное правило: старое не отключается, пока новое не проверено целиком.

Проверка после любого переезда

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

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

Надёжная схема приёма обращений

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

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

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

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

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

Ежемесячная сводка по всем каналам. Сайт, карточка в Яндекс Бизнесе, карточка в 2ГИС, прямые звонки. Четыре числа в таблицу. Резкое изменение любого из них видно сразу.

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

Что стоило сделать иначе

Владелец компании потом перечислил свои выводы коротко.

Не совмещать переезд сайта и почты в один вечер. Разнести на разные дни, чтобы понимать, что именно сломалось.

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

Проверять результат самому, а не полагаться на «всё работает». Отправить заявку через форму и убедиться, что письмо пришло, — минута работы.

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

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

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

Вывод

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

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