CRM не создает задачу после нового лида: как восстановить автоматизацию

Лид без задачи легко остается необработанным, даже если сама карточка успешно создана. Автоматизация может зависеть от источника, стадии, ответственного, рабочего времени или отдельного webhook. Нужно определить, было ли событие создания, сработало ли правило и на каком шаге задача перестала формироваться.

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

Что проверить в первую очередь

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

• Проверьте источник, pipeline и начальную стадию проблемного лида.
• Убедитесь, что назначен активный ответственный с правом создавать задачи.
• Посмотрите журнал workflow/robots и конкретное условие, которое не прошло.
• Проверьте, нет ли уже закрытой или скрытой задачи, считающейся дублем.

Почему возникает проблема

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

• Новый канал создает лид сразу на стадии, где робот не настроен.
• Поле, используемое в условии, приходит пустым или в другом формате.
• Ответственный уволен, деактивирован или не имеет прав.
• Webhook доставлен повторно, и дедупликация пропускает всю цепочку вместо только дубля.
• Лимит API, очередь или временная ошибка не имеют retry.

Пошаговая диагностика

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

• Сравните audit trail успешного и неуспешного лида по времени.
• Воспроизведите тестовым лидом из каждого источника.
• Проверьте request/response интеграции и correlation ID.
• Уточните timezone и правила рабочего времени для срока задачи.
• Получите список лидов без открытой задачи за период и оцените масштаб.

Как разделить создание лида и создание задачи

Это две бизнес-операции с разными возможными ошибками. Надежная система хранит факт необходимости задачи и может повторить вторую операцию без повторного создания лида.

• Лид получает стабильный external ID и источник.
• Правило определяет task_required и желаемый SLA.
• Создание задачи имеет собственный idempotency key lead_id + rule.
• Ошибка записывается и повторяется с ограничением.
• Контрольный отчет находит task_required без связанной задачи.

Как исправить проблему

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

• Расширьте условие робота на реальные стадии и источники.
• Назначайте fallback-ответственного, если основной недоступен.
• Нормализуйте обязательные поля до запуска workflow.
• Добавьте очередь retry для временных ошибок CRM API.
• Создайте безопасный backfill только для лидов без задачи и с уникальным ключом.

Безопасный порядок внедрения

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

Как проверить результат

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

• Тестовые лиды из всех каналов получают одну задачу с правильным сроком.
• Повтор webhook не создает дубль задачи.
• Деактивированный ответственный приводит к назначению fallback и уведомлению.
• Отчет лидов без задачи пуст либо содержит только явно исключенные случаи.

Типичные ошибки при исправлении

• Создавать задачи массово по всем лидам за период без проверки существующих.
• Использовать имя ответственного вместо стабильного ID.
• Считать создание карточки доказательством завершения всего workflow.
• Проглатывать ошибку CRM API и возвращать интеграции успешный статус.

Как предотвратить повторение

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

• Контролируйте долю лидов с задачей и время до первого действия.
• Тестируйте каждый рекламный источник после изменения форм.
• Храните журнал правил, retries и idempotency keys.
• Предусмотрите владельца для необработанных ошибок автоматизации.

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

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

Частые вопросы

Как восстановить задачи для старых лидов?

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

Почему вручную задача создается?

Ручной сценарий не проверяет те же условия, пользователя интеграции, API limit и очередь. Сравните контекст выполнения.

Когда нужна помощь специалиста

Если CRM принимает лиды, но не ставит задачи менеджерам, я могу найти условие или сбой интеграции, восстановить пропуски без дублей и настроить контроль SLA и очереди ошибок.