В компании работают два менеджера, руководитель и специалист, который рассчитывает нестандартные заказы. Клиент присылает запрос на почту, уточняет детали в сообщениях и звонит другому менеджеру. Каждый помнит свою часть разговора. Когда приходит время отправлять предложение, никто не уверен, какие сроки уже обещаны.
CRM для такой команды должна помогать отвечать на четыре вопроса: что нужно клиенту, кто отвечает, что произойдёт дальше и когда. Начинать удобнее с одного процесса — например, от входящего запроса до передачи согласованного заказа исполнителю. Ниже — рабочая схема для небольшой B2B-команды. Это метод организации работы, а не перечень функций конкретного продукта.
Сначала определите границы процесса
Возьмите десять недавних обращений: обычные, потерянные, повторные и потребовавшие участия коллег. Восстановите фактическую цепочку действий. Где появился запрос? Кто решил, что он относится к продажам? Когда клиенту назвали срок? Как исполнитель узнал о согласованных условиях?
Не начинайте с переноса всей клиентской базы. Сначала договоритесь, какой результат должен давать новый порядок. Например: каждое новое обращение зарегистрировано в день получения, у него есть один ответственный и следующее действие. Для команды с другим графиком срок регистрации будет иным: правило должно соответствовать реальному режиму работы.
Если пока непонятно, в какой точке исчезают обращения, начните с разбора потерь в процессе продаж. Здесь задача уже практическая: собрать минимальный рабочий контур.
Настройте три связанных процесса
1. Регистрация и распределение обращений
Назначьте человека, который проверяет входящий поток, и замену на время его отсутствия. В небольшой команде это может быть дежурный менеджер. Он проверяет, не существует ли уже запись о клиенте, фиксирует суть вопроса и назначает ответственного. Если распределение происходит вручную, это тоже рабочий вариант при понятном регламенте.
Не превращайте любое сообщение в новую сделку. Просьба прислать закрывающий документ относится к обслуживанию существующего клиента; запрос на новую поставку может стать отдельной продажей. В документации Microsoft квалификация обращения также выделена в отдельное решение перед созданием возможности продажи. Названия записей в вашей системе могут отличаться; важно сохранить различие задач.
2. Работа с подтверждённой потребностью
Для простого процесса достаточно нескольких этапов: уточняем задачу, готовим предложение, согласуем условия, ждём подтверждения, передаём заказ. Отдельно фиксируются завершение и отказ с причиной. Этап должен показывать реальное состояние переговоров.
«Предложение отправлено» ещё не означает «клиент согласовал». Переход подтверждается событием: получены необходимые исходные данные, отправлена согласованная версия, клиент подтвердил состав заказа. Сотрудники должны одинаково понимать каждое условие.
3. Передача заказа исполнителю
Определите, что исполнитель получает вместе с заказом: состав, количество, согласованный срок, особые условия и контакт для уточнений. У передачи должно быть подтверждение приёмки. До него менеджер остаётся владельцем вопроса и проверяет, достаточно ли данных.
В условной компании менеджер Анна продаёт изготовление 40 корпусов. Расчёт делает Игорь. Его задача «подготовить стоимость по чертежу версии 3 к среде, 12:00» связана с клиентским запросом. Анна отвечает за общение с покупателем; Игорь — за результат расчёта. Два участника не означают двух владельцев одной коммуникации.
Оставьте в карточке данные для следующего действия
Для старта достаточно клиента, контакта, сути запроса, ответственного, этапа, следующего действия и срока. Условия заказа добавляйте по мере уточнения. Если бюджет неизвестен, так и укажите; обязательное выдуманное число ухудшает данные.
Проверьте каждое поле вопросом: кто использует его для решения? Если ответа нет, отложите поле. Это не запрет на подробную карточку: технически сложный продукт потребует больше исходных данных, чем стандартная поставка.
Вот заполненный учебный пример, который можно использовать как шаблон:
- Клиент и контакт: «Компания А», Ольга, специалист по закупкам; рабочий контакт указан в записи.
- Запрос: изготовить 40 корпусов по чертежу версии 3; покрытие требует уточнения.
- Ответственный: Анна; замена на время отсутствия — Сергей.
- Этап: уточняем задачу.
- Подтверждённые условия: количество 40; срок поставки пока не согласован.
- Следующее действие: Анна уточняет требования к покрытию у Ольги.
- Срок: вторник, 11:00; при отсутствии ответа — согласовать повторный контакт.
- Связанный результат: после уточнения Игорь получает задачу на расчёт стоимости и выполнимого срока.
Карточка должна позволять коллеге продолжить работу без пересказа всей переписки. Для этого записывайте результат разговора: что подтвердили, что осталось неизвестным, о чём договорились дальше.
Привяжите задачи к контексту
Задача «позвонить клиенту» плохо объясняет ожидаемый результат. Лучше: «уточнить, согласована ли версия предложения 2, и договориться о следующем шаге». После выполнения сохраняется итог, а не только отметка о звонке.
Связь задачи с клиентом помогает восстановить историю; такой подход описан в руководстве Microsoft по действиям в CRM. При выборе решения проверьте эту работу на своём примере: сможет ли заменяющий сотрудник найти последнее обещание и незавершённую задачу?
Не назначайте напоминания без условия остановки. Если клиент попросил вернуться через месяц, ежедневный звонок ухудшит отношения. Если вопрос закрыт, старые действия надо завершить или отменить с понятной причиной.
Запустите процесс на одной неделе работы
В понедельник согласуйте этапы, обязательные поля и правила ответственности. Во вторник пройдите пять реальных обращений вместе с менеджерами. В среду проверьте передачу вопроса коллеге и случай отсутствия ответственного. В четверг разберите записи без следующего действия. В пятницу уберите поля и действия, которые оказались лишними, и зафиксируйте исправленный регламент.
Это пример последовательности, а не обещание внедрить любую CRM за пять дней. Импорт данных, нестандартные роли и технические подключения могут потребовать отдельного этапа. Если переносите сведения из таблиц, подготовьте правила данных и пробную загрузку до массового переноса.
На проверке считайте наблюдаемые вещи. Допустим, за неделю поступило 24 обращения, а в учёте обнаружили 22. Полнота регистрации составила 22 / 24 × 100 ≈ 91,7%. Два пропуска надо найти по исходным каналам. Среди 18 активных записей у четырёх нет следующего действия: это конкретная очередь исправлений. Числа условные и не являются нормативами.
Когда минимальной схемы недостаточно
Несколько направлений продаж, тендеры, сложные согласования или строгие ограничения доступа могут потребовать разных процессов и ролей. Расширяйте модель после разбора такого сценария. Не переносите требования крупной компании только потому, что CRM позволяет добавить ещё один этап.
Для обсуждения ЧатПлюс подготовьте три обезличенных обращения: стандартное, проблемное и переданное коллеге. С ними можно проверить, как решение соотносится с вашей работой, какие настройки нужны и где потребуется отдельное решение. Расскажите ExtentLab о процессе команды — начните с того шага, на котором сейчас теряется договорённость.