Задачи, привязанные к записи CRM: работа остаётся на карточке

Четверг, 16:05. Менеджер по продажам только что завершил 24-минутный разговор по коммерческому предложению, которое висит в работе шестую неделю. Из этого разговора родились четыре разные задачи: переписать расчёт стоимости, назначить демонстрацию с участием двух инженеров, запросить документы для бухгалтерии и через две недели сделать контрольный звонок. Как только трубка положена, эти четыре дела расходятся по четырём местам — блокнот, сообщение самому себе, календарь и ничего. Через десять дней клиент пишет: «обновлённого предложения так и нет». Никто не отнёсся к делу халатно. Просто работа не осталась на той карточке, к которой относилась.

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

Почему задача должна жить на карточке, а не в отдельном инструменте?

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

Вторая выгода проявляется при передаче дел. Если менеджер уходит в отпуск или меняет команду, тому, кто его подхватывает, не нужно никого расспрашивать. Смысл CRM как раз в том, чтобы история клиента хранилась в одном месте, а задачи — это будущая часть той же истории. История отвечает на вопрос «что было», задачи — «что будет», и обе находятся под одной записью.

Третья причина — измеримость. Если работа лежит на карточке, у вопроса «сколько шагов мы сделали по этому клиенту за три недели» есть ответ. Если она в стороннем инструменте, вы знаете только количество закрытых задач, но не то, какие отношения реально сдвинулись. Рост числа закрытых задач одновременно с ростом числа зависших сделок — классический симптом такого разрыва.

Какие поля на самом деле описывают задачу?

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

• Заголовок с глаголом. «Иванов» — это не задача. «Отправить Иванову обновлённый расчёт в PDF» — задача. Без глагола запись превращается в заметку, которую легко отложить.
• Один владелец. Дело, назначенное на двоих, не принадлежит никому. Ответственность закрепляется за одним именем, остальных упоминают в комментариях.
• Привязанная запись. Задачу без связи с лидом, клиентом или сделкой нельзя ни измерить, ни передать.
• Срок и время выполнения. Это разные вещи; разницу разбираем в следующем разделе.
• Понятное условие завершения. «Вести клиента» не заканчивается никогда. «Отправить второе письмо, если до пятницы нет ответа» заканчивается.

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

К чему привязывать задачу: к лиду, клиенту или сделке?

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

В Rocketly эта связь называется прямо: задачи, привязанные к CRM. Когда вы связываете задачу с лидом или клиентом, открытое дело появляется на карточке записи, и по ней создаётся напоминание. Связь работает в обе стороны: тот, кто открыл запись, видит работу, а тот, кто открыл задачу, видит запись.

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

Чем задача отличается от напоминания и встречи?

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

Тип записи	Когда заводят	Когда закрывается	Где отслеживают
Задача	Есть конкретный результат	Результат передан	Канбан, список, календарь, Гант
Подзадача	Работа не помещается в один заход	В составе основной задачи	Под основной задачей
Напоминание	Внимание нужно в конкретный момент	Просмотрено или перенесено	Экран напоминаний
Встреча	Время согласовано со второй стороной	Встреча состоялась	Календарь
Повторяющаяся задача	Рутина возвращается с фиксированным шагом	Каждое повторение отдельно	Проект или карточка записи

Практический вывод прост: если завести реальную работу как напоминание, её невозможно измерить, потому что у напоминания нет результата. Если завести напоминание как задачу, список никогда не станет чистым. Операционная часть CRM, отвечающая за ежедневное исполнение, держится именно на этом разграничении; от него же зависит, сможет ли аналитическая часть выдать осмысленный отчёт.

Что происходит в первые девяносто секунд после разговора?

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

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

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

Как выстроить порядок крупной работы: подзадачи и зависимости

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

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

У дробления есть предел. Каждая подзадача должна быть настоящей работой хотя бы на полдня; превращать пятиминутные шаги в отдельные строки — значит раздуть список, который никто не будет вести. Брошенные подзадачи без владельца и без срока со временем становятся частью мусорных данных в CRM: они портят отчёты, замедляют поиск и подрывают доверие команды к системе.

Что делать с просрочкой: причина переноса и эскалация

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

Здесь работает перенос с указанием причины: откладывая напоминание, вы пишете, почему, и в историю напоминаний попадает, кто и по какой причине это сделал. В конце месяца вопрос «почему это встало» закрывается записью, а не догадками. Для напоминаний, оставшихся без ответа, есть политика эскалации: вы задаёте порог по времени и запасного исполнителя на уровне команды или организации, и при превышении порога дело автоматически переходит к нему. Клиенту не приходится ждать возвращения одного человека из отпуска.

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

Какой экран вы открываете утром первым?

Экзамен для системы задач начинается в девять утра. Если менеджер вынужден обходить четыре экрана и сам собирать свой день, система не работает. Цель — одна поверхность, которая утром отвечает на вопрос: что сегодня на мне?

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

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

По каким цифрам понять, что порядок работает?

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

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

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

Почему команда сопротивляется и как внедрить порядок за две недели?

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

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

Через две недели смотрите на один показатель — долю просроченных задач. Падает, значит порядок прижился; растёт, значит правил слишком много и поля надо убирать. Непринятое поле остаётся пустым, а пустое поле ломает отчётность — с этого круга начинается значительная часть причин, по которым проекты CRM проваливаются.

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

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

Не станет ли список неуправляемым, когда задач будут сотни?

Это решается сменой представления, а не сокращением пула. Один и тот же набор задач вы двигаете на канбан-доске, фильтруете в списке, раскладываете по датам в календаре или читаете цепочкой в диаграмме Ганта. Сотня задач подавляет в плоском списке и превращается в десяток строк при фильтре «сегодня».

Можно ли вести в этой же системе личные дела?

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

Вернётся ли случайно удалённая задача?

Да. Удалённые задачи и проекты попадают в корзину, откуда их восстанавливают. Кроме того, история активности фиксирует, кто и когда что изменил в каждой задаче, поэтому удаление остаётся прослеживаемым наравне с остальными действиями.

Нужен ли всё-таки отдельный инструмент управления проектами?

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