Исходная ситуация
Форма на сайте отправляет письмо на общий ящик — info@ или sales@. Ящик открыт у двух-трёх сотрудников: кто первый увидел, тот и ответил. Иногда отвечают двое, и клиент получает два разных предложения. Иногда не отвечает никто, потому что каждый решил, что заявку взял коллега.
Рядом живут другие каналы. Звонок менеджер записывает в блокнот и переносит в CRM вечером. Сообщение в мессенджере копируется руками. Лендинг, который делал подрядчик, шлёт на третий адрес — так было быстрее настроить.
Время утекает в четырёх местах:
- Между отправкой формы и первым взглядом человека. Ночью и в выходные — до утра понедельника.
- Между «увидел» и «взял». Ответственности нет, есть общий ящик.
- На перепечатывании. Из письма в CRM, из блокнота в CRM, из мессенджера в CRM.
- На поиске истории. Клиент перезванивает через неделю, и никто не помнит, о чём была речь.
Отдельная беда — тишина при поломке. Если форма перестала отправлять письмо (сменился пароль SMTP, письма поехали в спам, endpoint отдаёт 500), об этом узнают по падению продаж недели через две.
Что смотрели
Диагностика начинается со сверки двух чисел, которые обязаны совпадать: сколько раз форма была отправлена и сколько заявок заведено в системе.
- Отправки формы — из веб-аналитики (цель на отправку) и из логов самого endpoint. Два источника, потому что аналитика режется блокировщиками, а логи не видят случаев, когда запрос вообще не дошёл до сервера.
- Заведённые заявки — выгрузка из CRM или трекера за тот же период и в той же таймзоне.
Разрыв между числами — размер дыры. Дальше его разбирают на составляющие.
| Метрика | Как снять | О чём говорит |
|---|---|---|
| Время до первого касания | Метка отправки минус время первого исходящего | Реальный, а не заявленный срок ответа |
| Доля заявок без ответа | Заявки без исходящего дольше суток | Потери на ровном месте |
| Доля дублей | Совпадение телефона или почты в окне суток | Двойные клики и ретраи |
| Распределение по часам | Гистограмма по времени отправки | Нужен ли ночной сценарий |
| Доля мусора | Спам и боты | Оправдана ли защита формы |
Полезно один раз пройти путь заявки руками: отправить тестовую форму и проследить её через логи, почту, спам-папку, CRM. Половина проблем находится на этом шаге без всякой аналитики.
Что поменяли
Порядок шагов имеет значение: сначала надёжный приём, потом умный разбор.
1. Собственная точка приёма. Форма шлёт POST на свой endpoint. Первым действием запрос пишется в базу целиком, как пришёл — вместе с заголовками, UTM-метками, адресом страницы и временем. Всё остальное выполняется только после успешной записи.
2. Идемпотентность. Ключ считается из контакта, хеша текста и окна времени. Повторный запрос с тем же ключом не создаёт вторую заявку. Это закрывает двойные клики, ретраи браузера и повторные вебхуки.
3. Отсев ботов без капчи. Скрытое от человека honeypot-поле и проверка времени заполнения. Капча включается только для подозрительных запросов, чтобы не резать живых.
4. Нормализация. Телефон приводится к единому формату, почта — к нижнему регистру, UTM раскладываются по отдельным полям. По этим полям потом ищутся дубли и строится отчётность.
5. Разбор свободного текста. Модель раскладывает сообщение по полям: тип обращения, продукт, срочность, город. Обязательное условие — явный отказ. Нет уверенности — заявка получает категорию «разобрать вручную» и попадает в общую очередь, а не в случайную корзину.
6. Маршрутизация правилами. Таблица вида «категория плюс признак → ответственный и срок первого ответа» лежит в конфиге. Её правит руководитель отдела, а не разработчик. Модель готовит признаки, решение принимает таблица.
7. Создание задачи через API трекера. В карточке — исходный текст целиком, разобранные поля, ссылка на запись в базе, срок первого ответа. Исходный текст обязателен: разбор может ошибиться, оригинал нет.
8. Автоответ клиенту. Номер обращения и срок ответа. Клиенту — подтверждение, компании — общий идентификатор для переписки.
9. Эскалация по времени. Карточку не тронули за отведённый срок — уведомление ответственному, затем в общий канал, затем руководителю. Уведомление адресное, с упоминанием конкретного человека, иначе его читают как фоновый шум.
10. Очередь и мёртвые письма. Трекер недоступен — заявка остаётся в базе со статусом «не доставлено», отправка ретраится с нарастающей паузой. Ретраи исчерпаны — алерт человеку. Заявка не теряется ни при каком сбое внешней системы.
11. Монитор тишины. Отдельная проверка: нет ни одной заявки за несколько часов рабочего времени при обычном трафике — сигнал. Дешевле любого разбора постфактум.
Что не трогали
- Саму форму. Поля остались прежними. Каждое новое обязательное поле снижает число отправок, а разбор текста и так даёт нужные признаки.
- Письма на общий ящик. Уходят параллельно весь переходный период. Пока новый путь не отработал месяц без сбоев, старый остаётся страховкой.
- CRM и трекер. Инструмент не менялся, добавился только вход через API. Смена трекера одновременно с перестройкой приёма даёт два источника проблем вместо одного.
- Ручное заведение заявок. Менеджер по-прежнему создаёт карточку руками — через тот же endpoint, чтобы данные лежали в одном месте.
Обратимость
- Классификатор — за флагом. Выключается, все заявки идут в общую очередь с маршрутизацией по умолчанию.
- Автосоздание задач — отдельный флаг. Выключается, письма продолжают идти, работа не встаёт.
- Правила маршрутизации — конфиг под версионированием. Откат равен возврату предыдущей версии файла.
- Автоответ — третий флаг, независимый от остальных.
- База принятых заявок остаётся при любом откате. Данные, накопленные за время эксперимента, переживают отключение автоматики.
Порядок отключения при проблемах: сначала автоответ, потом классификатор, потом автосоздание задач. Приём и хранение не отключаются никогда.
Границы
- Мало заявок. При единицах обращений в неделю почтовый фильтр и дисциплина дают тот же результат без разработки.
- Заявка требует квалификации. Когда решение зависит от разговора, маршрутизация ускорит передачу, а узкое место останется в человеке.
- Конструкторы сайтов без вебхуков. Придётся парсить письма, а почтовый парсер ломается при любом изменении шаблона. Работает, но требует присмотра.
- Персональные данные под регулированием. Согласие, срок хранения, состав полей и содержание автоответа проверяются до запуска, а не после.
- Ответственные не реагируют. Автоматика ускорит накопление просрочки и сделает её видимой. Видимость полезна, но проблема организационная, и кодом она не закрывается.
Правило: заявка сначала записывается в собственное хранилище, и только потом разбирается, маршрутизируется и рассылается.