Выберите одну задачу вместо большого меню
Запишите, какое действие должен завершить посетитель: записаться на консультацию, описать задачу для расчёта или узнать условия конкретной услуги. Формулировка «автоматизировать продажи» слишком широкая для первого запуска. Из неё непонятно, какие вопросы задавать, кому передавать обращение и что считать завершённой работой.
Просмотрите недавние обращения и выпишите повторяющиеся вопросы. Если люди прежде всего уточняют, работаете ли вы с их задачей, начните с выбора услуги и короткого описания ситуации. Если для ответа нужен специалист, не стройте длинный опрос: предложите передать вопрос человеку. Для каждого шага запишите, зачем бизнесу нужны эти сведения. Уберите вопросы, ответы на которые пока никто не использует.
Соберите короткий сценарий обращения
Пример стартового сообщения: «Помогу передать задачу специалисту. Выберите услугу или напишите вопрос своими словами». Для выбора услуги можно использовать кнопки; Telegram поддерживает кнопки и текстовые сообщения. При этом оставьте понятный путь для человека, который не нашёл подходящий вариант. Названия пунктов должны описывать задачи клиентов, а не внутренние отделы компании.
После выбора спросите: «Что хотите получить и что уже есть?» Затем уточните удобный способ связи, покажите собранную заявку и предложите исправить её или отправить. Не требуйте бюджет и срок, если без них можно начать разговор. Если эти сведения действительно нужны для распределения обращений, объясните это рядом с вопросом.
После сохранения обращения покажите подтверждение и понятный следующий шаг. Сообщение «Заявка принята» должно означать, что она действительно записана и доступна ответственному. Обещайте конкретное время ответа только тогда, когда команда может его соблюдать. Для нерабочего времени подготовьте отдельный текст.
Договоритесь, где менеджер будет вести диалог
Уведомление о новой заявке само по себе не решает задачу общения. До разработки выберите рабочий вариант: сотрудник отвечает из системы через бота либо связывается с клиентом отдельно по согласованному контакту. Покажите оба пути на прототипе и дайте тому, кто принимает заявки, пройти их самостоятельно.
В уведомлении нужны текст вопроса, выбранная услуга, доступный контакт и ссылка на запись обращения. Если предусмотрена ссылка на профиль клиента, проверьте её работу на тестовых аккаунтах; не делайте её единственным способом связи. Сотрудник должен понимать, кому он отвечает и видит ли клиент сообщение. При передаче между сотрудниками сохраняйте контекст, чтобы человеку не пришлось заново объяснять задачу.
Определите правила записи в CRM
Составьте небольшую таблицу соответствий: услуга попадает в направление, текст клиента — в описание, выбранный контакт — в поле связи. Для каждого нового обращения назначайте ответственного и статус, например «Ожидает первого ответа». Названия здесь условные: используйте этапы, по которым действительно работает ваша команда.
Отдельно опишите повторное обращение. Если клиент дополнил вопрос, сотруднику обычно полезнее увидеть продолжение существующей заявки, чем несколько не связанных записей. Правило объединения нужно спроектировать и проверить; оно не возникает только от подключения CRM. Предусмотрите также сбой передачи: обращение сохраняется, ошибка становится видна ответственному, а повторная попытка не создаёт дубль.
Проверьте сценарий до привлечения посетителей
Пройдите путь нового клиента с телефона: выбор услуги, свободный вопрос, исправление текста, отправка и ответ сотрудника. Затем проверьте неудобные ситуации: пустое сообщение, повторное нажатие, возвращение после перерыва и вопрос вне сценария. В каждом случае должно быть понятно, что делать дальше и как обратиться к человеку.
Проверяйте результат с двух сторон. Клиент видит подтверждение, а сотрудник — полную заявку с правильными данными. Откройте контакт из уведомления, отправьте тестовый ответ между своими аккаунтами и убедитесь, что он пришёл нужному получателю. Отдельно испытайте недоступность CRM: важен не только обычный путь, но и сохранность обращения при ошибке.
Посчитайте конверсию на конкретном примере
Условный пример, не прогноз: за выбранный период сценарий начали 80 уникальных пользователей, 24 отправили заявку, с 18 состоялся содержательный разговор. Конверсия из старта в заявку равна 24 / 80 × 100 = 30%. Доля заявок, дошедших до разговора, равна 18 / 24 × 100 = 75%. Эти показатели отвечают на разные вопросы: удобен ли сценарий и удаётся ли команде связаться с обратившимися.
Чтобы получить такие числа, заранее определите события и правила подсчёта. Повторный запуск одним человеком не должен случайно превращаться в нового посетителя. Факт разговора отмечайте по согласованному правилу в CRM: отправленное уведомление ещё не означает, что общение состоялось. Сравнивайте периоды с учётом источников посетителей и изменений предложения.
Если люди уходят на вопросе о бюджете, проверьте, нужен ли он на этом этапе. Если заявки приходят, но разговора нет, изучите контактные данные, время ответа и назначение ответственного. Меняйте по одному существенному элементу, чтобы понимать причину результата. Несколько обращений дают повод изучить диалоги, но ещё не доказывают устойчивый эффект.
Подготовьте задание на разработку
Для обсуждения проекта достаточно описать услугу, основное действие клиента, вопросы бота, способ передачи менеджеру и нужные поля CRM. Приложите несколько обезличенных примеров обращений. Добавьте критерий приёмки: заявка проходит весь путь, ответ доставляется клиенту, ошибки видны, а показатели можно посчитать.
В Дело Прёт можно обсудить разработку бота и связь с CRM. Напишите ниже, какие обращения вы получаете и где хотите на них отвечать: в Telegram, MAX или CRM. По этому описанию можно определить состав работ и обсудить решение. Начать разговор можно через форму или удобный мессенджер.