У двух CRM похожие презентации: воронка, карточка клиента, задачи, отчёты. На демонстрации поставщик за несколько минут создаёт сделку и показывает красивую диаграмму. Но главный вопрос остаётся открытым: сможет ли ваш менеджер провести обычный запрос через уточнения, изменение условий и передачу коллегам?
CRM-систему для продаж стоит проверять на законченных действиях. Один подготовленный клиентский пример показывает больше, чем перечень разрозненных функций: видно, где повторно вводятся данные, как сохраняются обещания и что остаётся следующему участнику.
Ниже — пять сценариев для демонстрации. Они не требуют, чтобы все действия были автоматическими. Важно увидеть работоспособный способ выполнения, его ограничения и необходимую настройку.
Подготовьте один связный пример
Возьмите обычную B2B-продажу с двумя контактами и несколькими участниками со своей стороны. Замените реальные сведения учебными, сохранив связи между документами. Отдельно выпишите результаты, которые должны остаться после каждого шага.
В нашем примере «Компания К» уже есть в базе. Закупщик Ольга запрашивает 30 комплектов, технические условия подтверждает инженер Павел. Запрос поступает через выбранный рабочий канал; позже приходит уточнение по тому же заказу. Менеджер Анна готовит предложение, затем её на день заменяет Борис.
Перед встречей согласуйте исходное состояние: карточка компании создана, текущего запроса ещё нет, прежний заказ завершён. Поставщик может подготовить окружение, но должен раскрыть, какие настройки сделаны специально. Так проще отличить стандартный сценарий от результата отдельной разработки.
Сценарий 1. Принять обращение и определить следующий шаг
Попросите обработать сообщение Ольги так, как его получит обычный менеджер. Нужно найти существующую компанию, установить контакт, зарегистрировать потребность и назначить ответственного. На этом этапе точный срок закупки неизвестен.
Проверьте, можно ли сохранить обращение без выдуманных обязательных значений. Затем добавьте уточнение от Ольги. Оно должно быть связано с текущим вопросом, а не незаметно превращаться в новую компанию или независимую продажу.
Критерии прохождения:
- Пользователь находит исходное сообщение и знает, какой запрос оно породило.
- Существующая компания используется осознанно; совпадение названия не считается достаточным доказательством автоматически.
- Ответственный и следующее действие видны коллеге.
- Неизвестный срок отмечен как требующий уточнения.
- После повторного сообщения история доступна в согласованном рабочем контексте.
В документации Microsoft квалификация также отделена от самого поступления обращения. На демонстрации важно проверить смысл перехода: подтверждённая потребность и случайное сообщение не должны одинаково попадать в прогноз продаж.
Сценарий 2. Изменить предложение и сохранить договорённости
Пусть Анна отправила учебное предложение на 30 комплектов. Затем клиент попросил 40 и изменил место поставки. Попросите внести уточнение и показать, как сотрудник отличит прежние условия от актуальных.
Не обязательно требовать встроенный редактор коммерческих предложений. Если команда работает с внешними файлами, проверьте весь путь: где хранится актуальная версия, кто её согласовал и как она связана с продажей. Если поставщик предлагает штатный редактор, проверяются те же результаты.
Особенно важен срок: желаемая клиентом дата не должна самопроизвольно превращаться в обещанную компанией. Разделите запрос покупателя, проверку выполнимости и подтверждение условий.
Попросите другого пользователя ответить без подсказки Анны: какое количество согласуется сейчас, что изменилось и какое действие ожидается от клиента. Если для ответа надо открыть несколько несвязанных чатов, зафиксируйте дополнительную работу в оценке.
Сценарий 3. Передать работу на время отсутствия менеджера
Анна недоступна, Ольга звонит Борису. Попросите показать, как Борис найдёт последнюю договорённость, открытые вопросы и срок следующего действия. Затем пусть он зафиксирует результат разговора.
В учебном примере Павел ещё должен подтвердить техническую часть. Борис узнаёт, что ответ ожидается в четверг. После его записи Анна должна увидеть новое событие и понять, что требуется дальше. При этом прежняя задача не должна остаться вторым независимым обещанием позвонить клиенту.
Различайте временную помощь и смену владельца отношений. Правила задаёт компания; CRM должна позволять выполнить выбранный порядок без потери контекста. Распределение обращений подробнее разобрано в отдельном регламенте назначения.
Руководство Microsoft по действиям в CRM описывает связывание звонков, задач и встреч с клиентскими записями. На вашей проверке результатом должна быть восстановимая история, а не просто наличие кнопки создания задачи.
Сценарий 4. Передать согласованный заказ в исполнение
После подтверждения количества и условий попросите сформировать передачу исполнителю. В неё входят состав заказа, актуальная версия исходных данных, подтверждённый срок и специальные договорённости.
Проверяйте сценарий с сотрудником, который действительно принимает заказ: снабженцем, координатором или производственным планировщиком. Он должен найти нужные сведения и подтвердить, что может начать свою часть работы.
В учебном случае поставка состоит из 40 комплектов для одной площадки; специальное условие — согласованный способ маркировки по документу заказчика. Не добавляйте технические требования от имени программы: в проверке достаточно ссылки на утверждённый документ.
Если передача требует обмена с другой системой, покажите фактический результат на обеих сторонах. Обещание будущего подключения отмечается как открытая работа. Завершение продажи в CRM не должно скрывать неисполненную передачу заказа.
Сценарий 5. Оформить повторную потребность
Через условный месяц «Компания К» обращается за новой партией. Ольга остаётся контактом, но количество и требуемая дата другие. Попросите создать новую работу с использованием существующей компании и доступной истории.
Проверьте, что прежний заказ не переписывается и его результат остаётся самостоятельным. Условия новой продажи нужно подтвердить заново: старое количество, адрес или специальное требование не обязательно подходят новому заказу.
Затем измените контакт для технического согласования: Павел больше не занимается этой задачей. Команда должна видеть актуального участника, сохранив достоверную историю прежних разговоров. Переименование старого контакта в нового человека неприемлемо как способ обновления базы.
В конце найдите обе продажи из карточки клиента и объясните, какая ещё требует действий. Это проверяет, насколько CRM помогает длительным отношениям, а не только созданию первой записи.
Заполненный сценарный лист сравнения
Для каждого поставщика используйте одинаковую структуру. Пример записи по передаче коллеге:
- Код: CRM-03, временная замена менеджера.
- Исходное состояние: Анна ведёт запрос на 40 комплектов, ожидается техническое согласование.
- Пользователь: Борис с ролью замещающего менеджера.
- Действия: найти историю, ответить клиенту, записать результат и следующий срок.
- Ожидаемый результат: Анна после возвращения видит договорённость и единственное актуальное следующее действие.
- Проверка: другой сотрудник воспроизводит состояние без устного пересказа.
- Результат демонстрации: выполнено, но изменение задач требует дополнительного ручного шага.
- Ограничение: шаг занимает время и может быть пропущен.
- Дальнейшая проверка: повторить сценарий на пилоте обычным пользователем.
Последние три пункта — условный пример оценки, а не характеристика конкретной CRM.
Сравнивайте доказательства, а не сумму обещаний
Используйте отметки «показано», «показано с ограничением», «нужна настройка», «нужна разработка», «не подтверждено». Для каждого ограничения запишите влияние на работу, владельца решения и способ повторной проверки.
Некоторые условия стоит сделать проходными. Если невозможно сохранить историю принятого обязательства или получить нужные права замещающему сотруднику, высокий балл за другие функции не устраняет проблему.
Время выполнения измеряйте после одинакового короткого знакомства с интерфейсом. Скорость обученного представителя поставщика нельзя напрямую сравнивать со скоростью вашего сотрудника в незнакомой программе.
После показа сохраните результат: заполненные карточки, примеры документов, список ручных действий и недостающих настроек. Это станет основой ограниченного пилота. Общий список возможностей без доказательств не годится для приёмки будущего внедрения.
Что проверить перед решением о запуске
Попросите ещё раз пройти один полный сценарий обычным пользователем. Проверьте доступ к данным, возможность выгрузить нужную историю, работу используемых каналов и перечень дополнительных затрат на настройку и сопровождение. Проверять всё сразу не обязательно: обязательные для первого процесса условия должны быть закрыты явно.
Если ещё не определён сам процесс, начните с минимальной схемы работы команды. В ЧатПлюс заявлены единые входящие, CRM, воронки, проекты и задачи. Передайте ExtentLab свой сценарный лист, чтобы обсудить демонстрацию на вашей последовательности действий.