Почему задачи теряются между перепиской и CRM, даже когда всё записано

Недавно обратил внимание на одну странную вещь. В компании может быть CRM, общий рабочий чат, календарь и отдельная таблица с задачами. Информации вроде бы достаточно, ничего не удаляется, переписку всегда можно найти. А потом кто-нибудь спрашивает, почему клиенту так и не отправили документы.

И начинается поиск виноватого.

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

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

Сообщение в чате ещё не означает, что появилась задача

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

Коллега отвечает, что посмотрит.

На этом переписка заканчивается. Все заняты другими делами.

Через три дня клиент спрашивает, когда получит обновлённый договор. Выясняется, что документ никто не подготовил.

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

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

Здесь не хватило трёх простых вещей: конкретного результата, ответственного и срока.

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

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

Почему наличие CRM не спасает

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

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

В комментариях он оставляет информацию о пожеланиях заказчика.

Формально всё зафиксировано. Но отдельной задачи на подготовку предложения нет.

Другой сотрудник открывает CRM, видит новую сделку и предполагает, что менеджер продолжает работу самостоятельно.

Через несколько дней обнаруживается, что предложение не отправлено.

Мне кажется, здесь важно различать хранение информации и управление действиями.

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

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

Одна задача в трёх местах создаёт не порядок, а путаницу

Бывает и обратная крайность.

Компания пытается контролировать работу сразу несколькими способами. Задача появляется в CRM, дублируется в таблице и дополнительно отправляется в рабочий чат.

Сначала это кажется надёжной схемой. Если человек пропустит одно уведомление, увидит другое.

Но проблемы начинаются, когда информация меняется.

Например, клиент перенёс срок согласования макета со среды на пятницу.

Менеджер исправил дату в CRM. В таблице осталась среда, а в чате последнее сообщение вообще относится к понедельнику.

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

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

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

Если основной инструмент — CRM, именно там должны находиться срок, ответственный и статус. Чат можно использовать для обсуждения, но важные изменения необходимо переносить в карточку задачи.

Иначе приходится постоянно выяснять, какой из трёх источников считать правильным.

Самая опасная ситуация — когда ответственных несколько

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

На практике это иногда приводит к противоположному результату.

Возьмём небольшой интернет-магазин. Покупатель сообщает, что получил товар с повреждённой упаковкой. Обращение видят менеджер, сотрудник склада и специалист по возвратам.

Менеджер ждёт подтверждения со склада. Склад считает, что решение принимает специалист по возвратам. Последний уверен, что менеджер уже согласовал дальнейшие действия с покупателем.

Проходит день, а клиенту так никто и не объяснил, что делать.

Я бы разделил здесь две вещи: участие в решении проблемы и ответственность за конечный результат.

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

Ему необязательно выполнять всю работу самостоятельно. Его обязанность — не дать процессу остановиться между подразделениями.

Как проверить, где именно пропадают задачи

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

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

Для каждого случая достаточно восстановить короткую цепочку:

1. Где впервые появилась просьба выполнить работу.
2. Кто должен был превратить её в конкретную задачу.
3. Был ли назначен ответственный.
4. Где находились актуальные срок и описание результата.
5. На каком действии процесс остановился.

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

Это уже более полезная информация, чем общий вывод о плохой дисциплине.

Она показывает, что причины разные и исправлять их нужно по-разному.

Для первого случая подойдёт правило обязательной постановки задач после согласования. Для второго — единое место хранения сроков. Для третьего — понятный порядок передачи вопроса на согласование.

Не стоит вводить десять новых правил там, где достаточно исправить одну повторяющуюся ошибку.

Когда задачу действительно можно считать закрытой

Ещё один момент, который часто вызывает споры, — значение статуса выполнено.

Допустим, сотруднику поручили подготовить документы для клиента.

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

Но клиент ничего не получил.

С точки зрения исполнителя работа закончена. С точки зрения менеджера — нет. Для клиента вообще ничего не изменилось.

Поэтому при постановке задачи полезно заранее определить, какой результат считается завершением.

Подготовить документы и отправить документы — разные действия. Согласовать макет и передать макет в производство — тоже.

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

Что можно изменить без перестройки всей работы

Для небольшой команды я бы начал с трёх договорённостей.

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

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

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

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

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

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

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

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