Почта → CRM
Письмо клиента доходит до CRM без ручного ввода
Общий ящик сервисного центра принимал всё вперемешку. Мы поставили перед моделью четыре дешёвые проверки, свели её ответ к разрешённому списку значений и замерили качество на 704 реальных письмах до того, как система получила право создавать заявки.
- Поля из письма
- Заполнено автоматически
- Ждёт проверки
входит Было
Сотрудник читал общий ящик подряд и заводил каждую заявку руками: 5–10 минут на письмо.
в работе Сделали
Перед моделью четыре бесплатные проверки, её ответ принимается только из разрешённого списка, каждое решение пишется в журнал.
готово Эффект
Менеджер открывает готовую карточку и проверяет её. На 704 архивных письмах все пороги ошибок пройдены.
Как это работает
Вручную
было: 5–10 мин руками
Автоматически
стало: готовая карточка
-
Письмо входит
вложение · 2 файла
-
Разбор готово
-
Карточка готово
- Тип обращения
- Ремонт
- Клиент
- карточка № 4127
- Серийный номер
- 7К-2026-118 авто
- Срок
- 3 рабочих дня
-
Ответ готово
Черновик ответа · источник: руководство, стр. 42
Ситуация
В один ящик приходили обращения клиентов, внутренняя переписка, счета, рассылки и ответы на существующие заявки. Сотрудник читал подряд всё и заводил заявку руками: 5–10 минут на каждую. Цена ошибок здесь разная, и это главное свойство задачи. Пропустить настоящее обращение дорого: клиент остаётся без ответа. Завести заявку по письму коллеги дорого иначе: мусор в базе подрывает доверие к системе целиком.
Что сделали
Собрали каскад «дёшево → дорого». Первыми идут четыре проверки, которые не стоят ничего: служебная метка уже созданной заявки, жёсткий фильтр внутренних адресов компании, признаки ответа на существующую заявку, признаки рассылки. До модели доходит только то, что проверки не разобрали. Модель возвращает строгий набор полей, и код читает лишь разрешённые значения: ответственного из белого списка, тип заявки из трёх известных, мусор в поле изделия отбрасывает. Когда внешний сервис недоступен, заявка не создаётся и письмо остаётся непрочитанным: лучше отложить, чем завести мусор. Каждое решение пишется строкой в журнал: стадия, действие, причина.
Результат в цифрах
Заведение заявки стоило 5–10 минут ручной работы. Классификатор прошёл проверку на 704 реальных письмах из архива: все пороги ошибок пройдены. Классификатор заводит заявки в ту же рабочую базу, что описана в кейсе «Учёт заявок».
Как проверяли
Собрали 704 письма за прошлый период и разметили вручную. Прогнали тем же кодом, который работает в проде: не копией логики, а импортом рабочих функций. Метрики считали отдельно по внутренним адресам и по остальным, потому что пороги для них разные. Отчёт перечисляет каждое ложное срабатывание и каждый пропуск с причиной, прогон возвращает ошибку при нарушении любого порога и потому годится как проверка перед выкатом.
Что переносится в ваш проект
Переносим метод. Порядок проверок перед моделью и правило «самый дорогой класс ошибок закрываем жёстким списком адресов ещё до модели». Асимметричные пороги под вашу цену ошибки. Проверочный набор из вашего архива и прогон тем же кодом, что пойдёт в прод. Журнал решений, по которому потом разбирают инциденты.
Похожая задача? Пришлите архив писем за месяц, вернём отчёт с цифрами по вашему потоку.