Статусы в CRM и задачах: как настроить жизненный цикл без хаоса

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

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

Этот материал для собственников, руководителей продаж, операционных директоров и руководителей проектов, которые хотят навести порядок не только в интерфейсе CRM, но и в логике работы. Разберем, как проектировать жизненный цикл заявки, сделки, задачи или проекта, какие статусы нужны бизнесу, как описывать переходы, где ставить контрольные точки и как связать это с ВЕБОФИС, отчетами и ИИ-помощниками.

Короткий вывод

• Статус — это не подпись на карточке, а управленческое состояние работы с понятным владельцем, входом, выходом и следующим действием.
• Хорошая схема статусов отвечает на вопрос: где сейчас работа, почему она там, кто отвечает и что должно произойти дальше.
• Статусы CRM, задач и проектов должны быть связаны между собой, иначе продажи обещают одно, исполнение видит другое, а руководитель получает искаженную картину.
• Чем меньше статусов, тем легче поддерживать дисциплину, но каждый статус должен закрывать реальную управленческую потребность.
• Переходы между статусами важнее самих названий: именно они определяют правила передачи, сроки, уведомления и автоматизацию.
• Нельзя копировать статусы из чужой CRM без адаптации к своему процессу, ролям, договоренностям и типам работ.
• Перед подключением ИИ, автозадач и дашбордов нужно очистить логику статусов, иначе автоматизация будет масштабировать путаницу.
• Запускать новую схему лучше не сразу на всю компанию, а на одном сквозном потоке: от лида до оплаты, от заявки до закрытия или от продажи до исполнения.

Почему статусы становятся источником хаоса

У большинства компаний статусы появляются постепенно. Сначала в CRM заводят простую воронку: новый лид, контакт установлен, КП отправлено, договор, оплата. Потом приходит руководитель и просит видеть проблемные сделки. Добавляют «думает», «ожидаем ответ», «перезвонить», «зависло». Потом отдел внедрения просит отделять задачи на анализ, разработку, тестирование и приемку. Поддержка просит свои статусы для обращений. Маркетинг хочет понимать, какие лиды качественные. Финансы хотят видеть, где согласование счета.

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

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

Что считать хорошим статусом

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

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

То же самое с задачами. Статус «в работе» полезен только тогда, когда команда договорилась, что он означает фактическое выполнение, а не просто принятие задачи в очередь. Если задача ждет уточнения от клиента, ей нужен отдельный статус или явная причина блокировки. Иначе исполнитель формально занят, руководитель видит активность, а срок все равно срывается.

Три типа состояний: этап, ожидание и проблема

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

1. Этап процесса

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

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

2. Ожидание

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

Ожидание должно иметь срок пересмотра. Если карточка ждет ответа клиента три дня, нужен следующий контакт. Если задача ждет согласования неделю, нужен эскалационный маршрут. Если проект ждет вводные от заказчика, это должно попадать в план-факт и риски.

3. Проблема

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

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

Матрица проектирования статусов

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

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

Как связать CRM, задачи и проекты

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

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

1. Лид или заявка. Нужно понять источник, потребность, контакт, ответственного и следующий шаг.
2. Квалифицированная сделка. Появляются требования, бюджет, сроки, вероятность, тип будущей работы.
3. Коммерческое предложение. Фиксируются условия, состав работ, ограничения, нестандартные договоренности.
4. Согласование и оплата. Подключаются руководитель, финансы, юрист или другой согласующий маршрут.
5. Передача в исполнение. Создается проект, задача, заказ или заявка с сохранением ключевых условий.
6. Выполнение и контроль. Команда ведет задачи, сроки, зависимости, риски и приемку.
7. Закрытие и повторная работа. Фиксируется результат, обратная связь, следующий контакт, допродажа или улучшение.

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

Какие статусы нужны в CRM

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

Минимальная рабочая схема для B2B

• Новый лид. Контакт получен, но еще не разобран. Важно ограничить время нахождения в этом статусе.
• Первичный контакт. Менеджер пытается связаться или уже назначил первый разговор.
• Квалификация. Проверяются потребность, роль контакта, бюджет, сроки, соответствие профилю клиента.
• Диагностика или встреча. Команда уточняет задачу и собирает вводные для предложения.
• Предложение готовится. Ответственность внутри компании, нужен срок подготовки.
• Предложение отправлено. Обязательна дата следующего контакта, иначе сделка зависнет.
• Согласование условий. Видны нестандартные условия, скидки, юридические вопросы, риски маржи.
• Оплата или договор. Фиксируется маршрут финального оформления.
• Передано в исполнение. Сделка не просто выиграна, а передана дальше с понятным набором данных.
• Проиграно или отложено. Нужна причина, чтобы маркетинг и продажи учились на фактах.

Для длинных B2B-сделок особенно важно не терять следующий шаг. Эту тему можно усилить материалом о том, как вести длинные B2B-сделки: там подробнее разобран контроль контактов, пауз и рисков.

Какие статусы нужны задачам

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

Базовая схема задач

• Новая. Задача создана, но еще не принята исполнителем или ответственным.
• Уточнение. Не хватает данных, критериев приемки или материалов.
• В очереди. Задача понятна, но ожидает своей очереди по приоритету или ресурсу.
• В работе. Исполнитель реально делает задачу.
• На проверке. Результат передан постановщику, руководителю или клиенту.
• Доработка. Есть замечания, задача вернулась с конкретным списком исправлений.
• Принята. Результат соответствует критериям приемки.
• Отменена или заморожена. Работа прекращена с причиной, чтобы не портить статистику выполнения.

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

Как не перегрузить систему статусами

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

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

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

Правила переходов: место, где появляется управляемость

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

Примеры правил:

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

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

Статусы и отчетность: почему цифры начинают врать

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

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

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

Типовые процессы, где статусы особенно важны

Продажа сложной услуги

В сложной продаже менеджер работает не только с клиентом, но и с внутренними экспертами: пресейлом, руководителем, юристом, финансами, исполнением. Если статус не показывает, кто сейчас владеет следующим шагом, сделка начинает зависать между отделами. Менеджер считает, что ждет расчет. Эксперт считает, что не получил вводные. Руководитель видит «КП готовится» и не понимает, где узкое место.

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

Передача проекта после оплаты

После оплаты сделка не должна просто исчезать из CRM. Нужно состояние, которое подтверждает передачу: создан проект, назначен ответственный, перенесены условия, приложены документы, зафиксированы сроки и ограничения. Если этого нет, исполнение начинает заново выяснять то, что продажи уже обсуждали с клиентом.

Сервисная заявка или обращение клиента

В поддержке статус должен отделять реакцию от решения. «Принято» не равно «решается», «ответили» не равно «закрыто», «ждем клиента» не равно «забыли». Если эти состояния смешаны, компания не видит реальное качество сервиса и не может управлять ожиданиями клиента.

Внутренняя доработка системы

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

Ошибки и риски

Ошибка 1. Делать статусы под руководителя, а не под процесс

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

Ошибка 2. Смешивать статус и причину

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

Ошибка 3. Оставлять закрытые карточки без результата

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

Ошибка 4. Не назначать владельца статуса ожидания

Если карточка ждет клиента, смежника или согласующего, все равно нужен внутренний владелец контроля. Иначе ожидание становится ничьей зоной. Владелец не обязан сам решать чужую часть, но обязан держать дату следующего шага и эскалацию.

Ошибка 5. Внедрять новую схему без очистки старых данных

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

Ошибка 6. Сразу автоматизировать все переходы

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

Чеклист запуска новой схемы статусов

1. Выберите один сквозной поток: лиды, сделки, клиентские заявки, проектные задачи или внутренние доработки.
2. Опишите фактический путь работы от входа до закрытия без попытки сразу рисовать идеальную модель.
3. Разделите состояния на этапы, ожидания и проблемы.
4. Для каждого статуса назначьте владельца следующего шага, событие перехода и допустимый срок нахождения.
5. Проверьте, какие состояния лучше сделать тегами, причинами, полями или чек-листами, а не статусами.
6. Определите обязательные поля для переходов: сумма, дата следующего контакта, результат, файл, причина, критерий приемки.
7. Согласуйте правила передачи между отделами: продажи — исполнение, исполнитель — проверяющий, поддержка — разработка, бэк-офис — финансы.
8. Настройте отчеты не только по количеству карточек, но и по времени в статусах, просрочкам, возвратам и причинам остановки.
9. Проведите пилот на небольшом наборе карточек и соберите реальные спорные случаи.
10. После пилота включайте автоматизацию: уведомления, автозадачи, контроль SLA, управленческие сигналы и шаблоны отчетов.

Как применить это в ВЕБОФИС

ВЕБОФИС полезен не тем, что в нем можно завести много статусов, а тем, что статусы можно связать с рабочим контуром: CRM, задачами, проектами, документами, командой, отчетами и внутренними правилами. Для компании это означает, что карточка сделки не заканчивается в момент продажи. Она может породить проект, задачу, согласование, уведомление, маршрут приемки или повторный контакт.

Практичный сценарий внедрения выглядит так. Сначала команда описывает жизненный цикл одного потока: например, от заявки до оплаты и передачи в исполнение. Затем в готовом решении ВЕБОФИС настраиваются роли, статусы, обязательные поля и связи между сущностями. После этого добавляются отчеты по времени в статусах, просрочкам, возвратам на доработку и сделкам без следующего шага.

Когда контур стабилен, можно подключать более умные функции: ВЕБОФИС: AI для управленческих сводок, поиска рисков и подготовки ответов, нейроконсультанта для работы с базой знаний и регламентами, а также материалы по задачам и проектам для развития управленческой практики.

Контекстный следующий шаг: если в компании уже есть CRM или таск-трекер, но отчеты не вызывают доверия, начните не с новой системы, а с ревизии статусов. Возьмите 30-50 последних карточек, проверьте, одинаково ли сотрудники понимают состояние работы, и зафиксируйте 5-7 управленческих сигналов, которые руководитель должен видеть без ручной сводки. После этого можно переходить к настройке воронок, досок и автоматизации.

FAQ

Сколько статусов должно быть в CRM?

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

Нужно ли делать одинаковые статусы для всех отделов?

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

Что делать со статусом «в работе», если он слишком широкий?

Разделите его на очередь, фактическое выполнение, ожидание данных и проверку результата. Так руководитель увидит, где задача реально движется, а где просто числится активной.

Можно ли менять статусы в уже работающей CRM?

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

Какие поля обязательны рядом со статусами?

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

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

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

Как понять, что текущие статусы плохие?

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

Нужен ли отдельный статус для каждой причины задержки?

Обычно нет. Причины задержки лучше хранить в отдельном поле или списке причин. Статус должен показывать состояние потока, а причина — объяснять, почему карточка в этом состоянии.