Если в CRM накопилась просрочка, начните с разбора обязательств, а не с массового переноса дат. В одном списке могут находиться невыполненные обещания клиенту, уже сделанная работа без отметки, дубли автоматизации и задачи с ошибочным сроком. Для каждой причины нужно своё действие. Общий запрет переносов не исправляет очередь и может сделать учёт ещё формальнее.
Ниже — порядок разбора для руководителя продаж. Практический результат — таблица причин просрочки с решениями, исполнителями и проверкой. Примеры интерфейса относятся к amoCRM; организационный порядок можно применять в другой CRM после проверки её возможностей.
Сначала сохраните исходную картину
Выберите одну команду или воронку, момент среза и единое понимание просрочки. Выпишите задачи, срок которых уже наступил, но результат ещё не зафиксирован. Сохраните идентификатор задачи, связанную карточку, исходный срок и ответственного. Если сразу перенести всё на завтра, исчезнет возможность понять, какие обязательства нарушены и как долго они ждут.
Проверьте видимость данных под ролью руководителя. Отсутствие чужой задачи в списке может быть следствием прав, а не отсутствия работы. Отдельно убедитесь, что смотрите нужную сущность: действие по клиенту может быть записано у контакта, компании или сделки.
Для amoCRM полезен отчёт по сотрудникам: официальная справка описывает задачи в работе, новые, просроченные, завершённые и завершённые с результатом за выбранный период. Эти показатели дают отправную точку, но не объясняют причину задержки. Аналитика и статистика по задачам.
Сначала выделите случаи, где клиент уже ждёт обещанный расчёт, ответ или документ. Их нужно вернуть в работу сразу. Остальную очередь разбирайте группами по источнику и типу задачи. При большой очереди сначала исследуйте выборку из каждой группы, но не выдавайте её результат за проверку всех задач.
Таблица разбора очереди просрочки
Добавьте к таблице ссылки на конкретные задачи, ответственного за исправление и дату повторной проверки. В колонке причины записывайте подтверждённый факт. Если его нет, оставляйте «требует выяснения», а не назначайте виновного по красному индикатору.
| Что обнаружено | Чем подтвердить | Что сделать | Как проверить результат |
|---|---|---|---|
| Обещанное клиенту действие не выполнено | Договорённость и отсутствие результата | Назначить исполнителя, согласовать реальный срок, сообщить клиенту об изменении | Результат передан клиенту, новый срок соблюдён |
| Работа сделана, задача осталась открытой | Отправленный документ, запись звонка или иной след действия | Закрыть с фактическим результатом и пояснением даты выполнения | Из записи понятно, что и когда сделано |
| Клиент изменил договорённость | Сообщение или итог разговора | Изменить срок, сохранив причину и новый следующий шаг | Новая дата соответствует договорённости |
| Не хватает мощности команды | Оценка времени нужных действий и доступного рабочего времени | Перераспределить работу и пересмотреть приоритеты | Очередь сокращается без скрытого переноса обязательств |
| Робот создаёт дубли или неверные сроки | Повторяемая ошибка на тестовой карточке | Исправить правило, затем разобрать созданные им задачи | Повторное событие не создаёт лишнего действия |
| Задача больше не нужна | Отмена заказа, завершение другого действия или подтверждённый дубль | Зафиксировать причину снятия с работы по принятому регламенту | Не осталось актуального обязательства без исполнителя |
Не объединяйте «клиент перенёс встречу» и «менеджер не успел позвонить» в одну причину «перенос». В первом случае меняется договорённость, во втором — требуется разбор выполнения прежней.
Как отличить перегрузку от формального учёта
Количество задач не измеряет трудозатраты. Подготовка сложного расчёта и короткое уточнение статуса могут выглядеть в списке одинаково. Для выбранного дня оцените время обязательных действий, назначенные встречи, входящий поток и доступное рабочее время. Учитывайте отпуск, обучение и другие обязанности сотрудника.
Учебный пример. На день поставлены шесть расчётов примерно по 40 минут и двадцать уточняющих контактов примерно по 10 минут. Это уже 440 минут без встреч, подготовки и новых обращений. Такие оценки нужно проверить на реальной работе, но они показывают, почему требование «просто закрой все задачи» может быть невыполнимым.
Признаки формального учёта другие: одинаковые задачи без цели, ежедневное изменение даты без нового основания, завершение без понятного результата, повторное создание того же действия сразу после закрытия. Это повод проверить несколько карточек с сотрудником. Сам по себе перенос ещё не доказывает бездействия.
Если задачи существуют, но не задают продолжения продажи, используйте отдельный регламент следующего шага. В этом разборе цель уже другая: выяснить причину накопленного долга и устранить её источник.
Нужно ли запрещать перенос задач
Начните с правила обоснованного переноса. Оно должно отвечать на четыре вопроса: что изменилось, чем это подтверждено, какой новый срок реалистичен и требуется ли предупредить клиента. Причину можно фиксировать комментарием в карточке; отдельное обязательное поле или технический запрет требуют проверки и настройки выбранной системы.
В amoCRM задаче можно изменить дату, время, ответственного и текст. В списке доступны массовые изменения сроков. Для проверки изменений справка предлагает добавить в таблицу дату и автора изменения; это не следует автоматически считать полным журналом всех прошлых сроков. Редактирование и отслеживание изменений задачи.
Если нужна история каждого переноса, сначала выясните, какие события действительно сохраняются в вашем аккаунте и за какой период. До настройки такого контроля фиксируйте исходный срок и основание изменения в журнале разбора. Не обещайте руководителю отчёт, для которого система не собирает данные.
Ограничение имеет смысл для конкретного риска: например, перенос обещанного клиенту срока требует согласования руководителя. Заранее опишите исключения, замещение руководителя и аварийный порядок. Проверьте, не начинают ли сотрудники вместо переноса удалять задачу или формально завершать её и создавать новую.
Как закрывать задачу по клиенту
Закрытие должно подтверждать действие, указанное в задаче. Попытка звонка и получение согласования — разные результаты. Если задачей было получить решение, запись «не дозвонился» объясняет попытку, но не подтверждает достижение результата.
Используйте короткую структуру: действие, полученный результат, подтверждение и продолжение. Например: «Учебная запись: отправлен расчёт по согласованному составу; клиент подтвердил получение; решение ожидается в четверг; в пятницу менеджер уточняет статус, если ответа нет». Дни недели здесь приведены для примера.
Если работы больше не требуется, укажите причину: заказ отменён, задача дублировала другую или обязательство завершено другим сотрудником. Технический способ снятия задачи выбирайте по регламенту CRM, сохраняя объяснение. Не записывайте отменённую работу как успешно выполненный контакт.
При очистке старой очереди отдельно помечайте позднее внесение результата. Дата нажатия кнопки и фактическая дата работы могут различаться, поэтому всплеск закрытий в день разбора нельзя автоматически объявлять ростом производительности.
Какие задачи создавать автоматически
Автоматизируйте повторяемые действия с определённым событием, ответственным, сроком и условием завершения. В amoCRM официально описано создание задач через Digital Pipeline и Salesbot; для задач в сделках можно задавать условия запуска, время, ответственного, тип и текст. Доступность сценария проверяйте в своей конфигурации. Автоматические действия с задачами.
Перед настройкой заполните правило: «Когда происходит X, сотрудник Y выполняет Z к сроку T; если событие повторяется или заказ отменён, действует условие N». Срок из разговора с клиентом должен поступить в правило из согласованных данных, а не заменяться удобным роботу значением «завтра».
В тесте проверьте повторный вход на этап, смену ответственного, отмену заказа и уже существующую задачу на то же действие. Не предполагается, что CRM сама устранит дубли. Если автоматизация создаёт больше шума, сначала исправьте её условие, затем разбирайте накопленную очередь.
Как понять, что разбор помог
Проверьте три результата на сопоставимых срезах:
- У актуальных просроченных обязательств появились исполнители, решения и реалистичные сроки.
- Источник повторной просрочки изменился: исправлено правило, перераспределена нагрузка или уточнён регламент.
- Сокращение очереди не объясняется только переносом дат, удалением задач или массовыми закрытиями без результата.
Сохраняйте отдельно исходную очередь и новые просроченные задачи. Иначе очистка старых записей может скрыть появление новых проблем. Для контроля на планёрке используйте макет ежедневного отчёта РОПа, а причины и решения храните в таблице разбора.
Начать можно с одной группы задач в рамках сопровождения CRM. Если причина в сценариях постановки, таблица станет исходным материалом для настройки автоматизации amoCRM. Приёмка должна подтвердить исправленное поведение на тесте и отсутствие прежней причины в повторной проверке рабочей очереди.