Боты без лишнего кода: Как создать чат-бота для бизнеса и личных задач
- -
- 100%
- +
Для проверки задайте себе простой вопрос: откуда человек приходит к задаче? Если он видит услугу на сайте и хочет записаться, оставьте короткий путь к записи там же. Если постоянный клиент открывает ссылку из сообщения о заказе, ему может быть удобнее бот в привычном мессенджере. Если важно подробно объяснить ситуацию, а не выбрать один из вариантов, сохраните возможность написать специалисту или позвонить.
Матрица маршрутов
Сведите три перспективы в одну рабочую схему. Для каждой роли укажите не площадку, которую хочется подключить, а место, где человек действительно готов решать свою задачу.
Клиент до услуги. Задача — понять условия, выбрать услугу или время. Канал — страница сообщества ВКонтакте, Telegram или сайт, в зависимости от того, откуда пришел человек. Момент — когда он сравнивает варианты или готов записаться. Запасной путь — телефон, форма или обращение к сотруднику.
Клиент во время услуги. Задача — проверить статус, изменить запись или получить инструкцию. Канал — тот, где оформлена услуга, либо ссылка из подтверждения. Момент — после события, повлиявшего на статус, или по запросу клиента. Запасной путь — связь с ответственным сотрудником.
Клиент после услуги. Задача — найти документы и правила или сообщить о проблеме. Канал — сообщение, сайт или почта, в зависимости от вопроса. Момент — после завершения заказа или при возникновении проблемы. Запасной путь — телефон или передача обращения специалисту.
Сотрудник. Задача — получить полное обращение и продолжить работу. Канал — рабочая система, панель заявок или утвержденный внутренний канал. Момент — после отправки заявки или срабатывания правила передачи. Запасной путь — назначенный коллега или руководитель смены.
Владелец. Задача — контролировать результат и замечать сбои. Канал — сводные показатели и выборочная проверка сценариев. Момент — по расписанию и после заметных изменений в процессе. Запасной путь — ручной разбор обращений и корректировка правил.
Матрица не должна превращаться в обещание, что все маршруты заработают одновременно. Ее задача — выявить разрывы. Например, клиенту предлагают обратиться к специалисту, но не сообщают часы его работы; сотруднику отправляют заявку, но не указывают, откуда она пришла; владелец видит число начатых диалогов, но не знает, сколько людей получили нужный результат.
Проверьте каждую строку по пяти вопросам. Понятно ли, какую задачу решает человек? Доступен ли ему выбранный канал? Подходит ли момент контакта? Получит ли он ясное подтверждение? Есть ли запасной путь, если автоматический сценарий не подходит?
Доступность проверяется на сбоях
Удобный сценарий не требует от человека цифровой сноровки. Пользователь может не знать, что нужно нажать кнопку под сообщением, не понять термин или случайно закрыть окно. Это не его ошибка, а обстоятельство, которое интерфейс должен учитывать.
Вместо команды «Введите код услуги в установленном формате» объясните, где найти код, или предложите выбрать услугу из короткого списка. Вместо просьбы подробно описать проблему дайте выбрать несколько понятных признаков и добавить комментарий. Не заставляйте вводить номер телефона в международном формате, если достаточно выбрать страну и набрать привычный номер.
На каждом шаге показывайте, что уже известно и что нужно сделать дальше. Не спрашивайте то, на что человек только что ответил. Дайте возможность вернуться на предыдущий шаг, исправить ответ или начать заново. Кнопка «Связаться со специалистом» должна быть на виду, а не появляться после нескольких кругов меню.
Учитывайте обстоятельства, в которых человек открывает бота. Клиент может быть в дороге, пользоваться небольшим экраном, находиться в шумном месте или иметь нестабильное соединение. Длинные инструкции, большие блоки текста, обязательные голосовые сообщения или требование сразу приложить несколько файлов могут помешать ему выполнить задачу. Если объяснить проблему можно только голосом, человек, которому неудобно записывать или слушать такие сообщения, останется без подходящего маршрута.
Для регулярных действий выбирайте короткие и понятные шаги. При сложном выборе пояснения необходимы, но лучше разместить их рядом с соответствующим пунктом, а не выдавать длинную инструкцию в самом начале. Проверьте сценарий на реальном телефоне и попросите людей с разным опытом пройти его без подсказок автора. Если они ищут кнопку, не понимают формулировку или боятся нажать не туда, фраза «все и так очевидно» интерфейс не исправит.
Доступность означает и возможность отказаться от автоматического пути. Человек может не хотеть регистрироваться на новой площадке, не иметь нужного приложения или просто предпочитать телефон. Не считайте такой выбор сопротивлением цифровизации. Если альтернативный путь поддерживает процесс, покажите его до того, как клиент потратит время на неудачную попытку.
Когда сценарий должен уступить человеку
Автоматизация хорошо справляется с известными вариантами. Живой разговор нужен там, где приходится учитывать контекст, принимать нестандартное решение или поддерживать человека в напряженной ситуации.
Первый сигнал — сложный выбор. Если решение зависит от нескольких условий, которые нельзя надежно свести к короткому меню, бот может собрать исходные данные, но не должен изображать персональную консультацию. Например, у устройства может быть несколько неисправностей, а цена ремонта зависит от диагностики. Бот способен объяснить порядок действий и записать описание, но решение остается за специалистом.
Тревога и конфликт требуют другого темпа и тона. Жалобу на сорванный срок, спор об оплате или опасение за качество не стоит проводить через длинную цепочку стандартных вопросов. Бот может зафиксировать номер заказа и тему, сообщить, кому направлено обращение, и передать его человеку. Нейтрально подтвердить получение обращения уместно; обещать клиенту результат, чтобы автоматически его успокоить, — нет.
Нестандартный случай возникает, когда ни один пункт меню не подходит. Если в интерфейсе нет варианта «Другой вопрос», человек выберет что-нибудь наугад, и обращение может попасть не тому сотруднику. Предусмотрите возможность описать ситуацию своими словами и настройте передачу человеку, если система не распознала ответ или пользователь несколько раз возвращается к одному шагу.
Еще один сигнал — трудности с цифровым интерфейсом. Повторные ошибки, просьба связаться с человеком, незавершенный сценарий или долгая пауза после сложного вопроса не доказывают, что пользователь не способен разобраться. Но это признаки того, что автоматический путь не сработал. В такой ситуации нельзя снова и снова показывать те же инструкции.
Передача обращения человеку должна быть частью процесса. Сообщите, какие сведения будут ему переданы, и не заставляйте клиента повторять уже сообщенное. Обозначьте часы ответа и следующий шаг. Если сотрудник подключится не сразу, честно скажите, сколько придется ждать, а не обещайте мгновенную реакцию без оснований. В срочной ситуации, связанной с угрозой жизни или безопасности, обычный бизнес-бот не должен быть единственным источником помощи: направьте человека в соответствующие экстренные службы, в России — по номеру 112.
Выбор можно свести к нескольким развилкам.
Если запрос повторяется, ответ известен заранее, а ошибку легко исправить, автоматизируйте весь короткий маршрут.
Если запрос повторяется, но для решения не хватает данных, автоматизируйте сбор минимально необходимых сведений и передачу обращения сотруднику.
Если случай редкий, цена ошибки высока или решение зависит от личной оценки, оставьте человека главным, а боту поручите навигацию и подготовку обращения.
Если клиент не завершает сценарий или выбирает неподходящий пункт, не добавляйте еще один уровень меню. Проверьте формулировки и сделайте передачу человеку доступной раньше.
Практика: опишите один маршрут
Выберите одну повторяющуюся задачу: например, запись на услугу, проверку статуса ремонта или перенос доставки. Не пытайтесь сразу охватить весь процесс компании. Заполните матрицу на основе реальных обращений, а не предположений о том, как «обычно» ведут себя клиенты.
Сначала сформулируйте результат для клиента одним предложением: например, «клиент выбирает свободное время и получает подтверждение». Затем опишите, что нужно сотруднику: «запись с выбранной услугой, временем и контактом попадает в рабочее расписание». Наконец, укажите, что будет проверять владелец: например, долю завершенных записей и причины перехода к сотруднику.
Теперь определите точку входа. Клиент пишет в сообщество ВКонтакте, переходит по ссылке в Telegram, открывает сайт или звонит? Не выбирайте несколько каналов только ради охвата. Начните с того, где уже возникает задача и где компания сможет поддерживать информацию в актуальном состоянии.
Проверьте три возможных сбоя. Что увидит человек, если свободных интервалов нет? Что произойдет, если он передумает или укажет неверные данные? Куда попадет обращение, если ни один вариант не подходит? Если на какой-то вопрос ответ звучит как «разберемся вручную», назначьте ответственного и определите порядок действий до запуска.
Затем попросите человека, не участвовавшего в проектировании, пройти сценарий с телефона. Не подсказывайте, куда нажимать. Посмотрите, где он останавливается, что перечитывает и какого шага ждет. Такая проверка полезнее обсуждения кнопок в команде: авторы уже знают, что имели в виду, а пользователь видит только написанное на экране.
В результате должна получиться не карта всех будущих возможностей, а один проверяемый маршрут с ясной аудиторией, каналом, моментом контакта и запасным путем. Если клиент, сотрудник и владелец получают каждый свой результат, бот становится частью процесса, а не дополнительной вывеской. Если хотя бы одному из них приходится обходить сценарий вручную, не спешите добавлять функции: сначала найдите разрыв в маршруте.
Следующий шаг — ограничить запуск так, чтобы проверить его на реальных обращениях без долгого проекта и лишних функций. Начать стоит с небольшого маршрута, результат которого заметен клиенту, сотруднику и владельцу.
Маленький запуск вместо вечного проекта
Когда уже понятно, какую задачу решает проект, для кого он предназначен и в какой момент человек к нему обращается, возникает новая ловушка: функций становится больше, а их пользу никто не проверяет. В первую версию хочется включить всё сразу — запись, оплату, напоминания и ответы на любые вопросы. Но пока не ясно, помогает ли бот с главной задачей, каждая дополнительная функция увеличивает сроки, расходы и число причин отложить запуск.
Представьте мастерскую, где записаться на услугу можно сообщением, звонком или при личном визите. К вечеру на столе лежит целый список пожеланий: показать цены, подобрать услугу, проверить расписание, взять предоплату, напомнить о визите, предложить сопутствующие работы, собрать отзыв. А на проект есть один свободный вечер и ограниченный бюджет. Что оставить, если цель — не впечатлить демонстрацией, а проверить, станет ли записываться проще?
Пилот — это ограниченный запуск первой версии, который проверяет одну гипотезу за определённое время и в пределах доступных ресурсов. Он не обязан решать все задачи мастерской. Но должен доводить пользователя до понятного результата, а владельцу проекта — давать основания решить, что делать дальше.
Один результат вместо целого мира
Начните не со списка функций, а с того, чем должен закончиться путь пользователя. В нашем примере результат первой версии — не «бот ответил на приветствие» и не «клиент нажал кнопку». Мастерская должна получить заявку с данными, необходимыми для подтверждения записи, а пользователь — понять, что произойдёт дальше.
Для пилота достаточно одной точки, одного привычного канала и одного распространённого вида работ. Не нужно сразу переносить в бот весь каталог услуг. Выберите частую и относительно стандартную услугу, на которой можно проверить повторяющуюся проблему. Например, сотрудники тратят время, чтобы уточнить вид работы, удобное время и контакт клиента.
Минимальный полезный сценарий может выглядеть так:
1. Пользователь выбирает вид работы.
2. Указывает предпочтительный день или временной интервал.
3. Оставляет имя и контакт для ответа.
4. Получает сообщение о том, что заявка принята и её проверят.
5. Администратор получает сведения и подтверждает подходящее время или предлагает другое.
Если бот не подключён к актуальному расписанию мастерской, он не должен обещать, что запись уже подтверждена. Фраза «Вы записаны на вторник» может привести к сбою, если это время уже занято. Надёжнее написать: «Заявка принята. Администратор проверит расписание и подтвердит время». Это звучит скромнее, зато не обещает того, чего система пока не умеет.
На старте сотруднику остаются задачи, где нужно принять решение, а не просто собрать стандартные сведения: проверить свободное время, оценить нестандартную работу, ответить на вопрос вне короткого перечня, подтвердить перенос или отмену. Это не слабое место бота, а заранее продуманная граница между автоматизацией и работой человека.
Пользователь должен иметь возможность выйти из сценария, если его запрос не подходит ни под один из предложенных вариантов. Кнопка или понятная команда для связи с администратором — часть минимального сценария, а не функция «на потом». Если человек застрял, бот не упростил запись, а создал дополнительный барьер.
Упражнение: определить полезный финал
Запишите результат одним предложением по формуле: «После взаимодействия с ботом пользователь получает…, а сотрудник получает…».
Для мастерской формулировка может быть такой: «Пользователь отправляет заявку на распространённую услугу и знает, когда ждать подтверждения; администратор получает вид работы, предпочтительное время и контакт, не запрашивая эти сведения по отдельности».
Проверьте себя тремя вопросами. Можно ли однозначно понять, достигнут ли результат? Ясно ли, какую работу больше не придётся повторять вручную? Понимает ли пользователь, чем заявка отличается от подтверждённой записи? Если хотя бы на один вопрос нет ответа, сценарий пока описывает функцию, а не пользу.
Частая ошибка — считать результатом сам факт общения с ботом. Например, отчёт показывает, что пользователи открывали меню, но неизвестно, получили ли сотрудники пригодные заявки. Другая ошибка — обещать полноценную автоматическую запись, хотя бот только собирает пожелания. В таком случае сначала стоит пересмотреть формулировку результата, а не добавлять новые кнопки.
Что вычеркнуть без сожаления
На этапе проектирования функция кажется мелочью: добавить кнопку, ветку сценария или поле. Но для неё нужны текст, настройка, проверка, обработка ошибок и человек, который будет обновлять информацию. Поэтому у каждой функции первой версии должен быть строгий пропускной пункт: помогает ли она проверить главную гипотезу?
Если вы хотите узнать, уменьшится ли число уточнений при записи, интеграция с календарём может не понадобиться. Бот собирает предпочтительное время, а администратор подтверждает его вручную. Но если гипотеза в том, что пользователь сможет сам выбрать и сразу забронировать свободный слот, календарь уже не украшение, а необходимая часть проверки. Тогда стоит сократить пилот в другом месте — например, оставить одну услугу и одну точку.
Решение зависит от того, какое предположение вы проверяете, а не от общего правила «интеграции всегда потом». То же касается оплаты. Чтобы проверить, собирает ли бот полные заявки, предоплата не нужна. Если же вы проверяете сценарий «записаться и оплатить без участия администратора», оплата может стать его центральной частью. Но тогда придётся отдельно проверить платежный процесс и условия возврата.
В первой версии мастерской обычно можно отложить полный каталог услуг, программу лояльности, сбор отзывов, рекомендации дополнительных работ, сложные напоминания и ответы на широкий круг вопросов. Не потому, что они бесполезны, а потому, что не помогают проверить саму запись. Всё, что не нужно для основной гипотезы, может подождать следующего решения.
Не добавляйте свободный диалог только ради впечатления. Если пользователь выбирает один из трёх понятных вариантов, фиксированное меню обычно проще проверить и поддерживать. Свободный ввод нужен, если без него человек не может описать запрос. Для пилота достаточно собрать короткое описание и передать его администратору — не обязательно пытаться автоматически распознать все возможные виды работ.
Упражнение: провести ревизию функций
Возьмите каждое пожелание и закончите фразу: «Без этой функции мы не сможем проверить, …». Если продолжение звучит убедительно, функция может быть необходима. Если же получается «так будет современнее», «пользователям может понравиться» или «у конкурентов есть», перенесите её в список возможных улучшений.
Затем оцените цену исключения. Что произойдёт, если этой возможности не будет три недели? Если пользователь всё ещё сможет выполнить основную задачу через администратора, а гипотезу удастся проверить, функцию можно отложить. Но если без неё человек получит ложное подтверждение или не сможет завершить путь, исключать её нельзя.
Чтобы не раздувать проект, разделите функции на три группы: обязательные для безопасного и понятного сценария, необходимые для проверки основной гипотезы и желательные, но отложенные. В мастерской к первой группе относятся точное сообщение о статусе заявки и возможность связаться с сотрудником. Ко второй — поля, без которых нельзя оценить качество заявки. К третьей — оплата, отзывы и расширенный каталог, если пилот проверяет только сбор данных для записи.
Тексты, которые задают границы
Сценарий может быть коротким, но пользователю важно понимать, что происходит. Для первой версии достаточно нескольких точных формулировок.
После отправки заявки: «Заявка получена. Это ещё не подтверждение записи. Администратор проверит расписание и ответит в рабочее время».
Для нестандартного запроса: «Этот запрос требует уточнения. Передайте его администратору, чтобы согласовать детали».
О сроке ответа: «Администратор обычно отвечает в течение одного рабочего дня». Указывайте срок, который мастерская действительно готова соблюдать, а не тот, что выглядит привлекательнее.
Не обещайте круглосуточную помощь, мгновенный ответ или гарантированно свободное время, если за этими словами не стоит реальный процесс. Бот может быть доступен всегда, а сотрудник, который подтверждает запись, — только в рабочие часы. Пользователь должен понимать эту разницу.
Если форма собирает телефон или другие персональные данные, запрашивайте только то, что необходимо для записи. Заранее определите, кто увидит заявки, где они будут храниться и как долго понадобятся. При запуске в РФ порядок обработки данных должен соответствовать действующим требованиям. Не передавайте сведения в сервисы и хранилища, использование которых не проверил ответственный за проект.
Числа: ориентир, а не обещание
Фраза «бот должен экономить время» не помогает принять решение. Нужна измеримая цель, но она не гарантирует, что результат будет достигнут. Цель задаёт порог, по которому вы решите, есть ли основания продолжать.
Сначала зафиксируйте исходное положение. Просмотрите последние обращения и посчитайте, сколько из них сразу содержали нужные сведения, сколько раз приходилось задавать уточняющие вопросы и сколько времени занимала обработка. Если данных нет, несколько дней отмечайте эти показатели вручную до запуска. Иначе сравнение «до и после» будет основано на впечатлении.
Допустим, за две недели в мастерскую поступило 20 подходящих запросов. В семи заявках сразу были указаны все сведения, необходимые для подтверждения записи. Исходная доля полных заявок — 35 процентов. Это условный пример: реальные значения нужно взять из собственных обращений.
Цель пилота можно сформулировать так: «За три недели не менее 60 процентов отправленных через бота заявок на выбранную услугу содержат все сведения для подтверждения без дополнительного запроса». Для оценки результата заранее задайте минимальный объём наблюдений — например, не менее 20 отправленных заявок. Если поток обращений в мастерской небольшой, подстройте срок и порог под реальность, а не подгоняйте данные под красивый план.
Здесь важно различать три вещи. Цель — желаемое значение показателя. Наблюдение — фактические данные за выбранный период. Обещание — утверждение о будущем результате, которое нельзя выводить из самого факта постановки цели. Честнее сказать «проверим, достигнет ли доля полных заявок 60 процентов», чем обещать, что «бот сократит переписку на 60 процентов».
Основной показатель должен отвечать на вопрос, ради которого запускается пилот. Если гипотеза в том, что сотрудники станут реже задавать одни и те же вопросы, считайте долю заявок, обработанных без уточнений. Заранее определите знаменатель: это все отправленные заявки по выбранной услуге, а не все пользователи, открывшие бот. Отдельно отмечайте, сколько людей начали сценарий, но не завершили его. Этот показатель поможет найти проблему, но не заменит основной.
Добавьте защитный показатель, чтобы улучшение одной цифры не скрывало вред. Например, число потерянных или неправильно понятых заявок не должно расти. Если пользователи чаще отправляют неполные заявки, а администратор тратит на обработку больше времени, чем раньше, высокий процент нажатий на кнопку не означает успеха.
Карточка пилота
Зафиксируйте решение в одном месте до настройки бота. Карточку можно заполнить кратко, но ничего важного не пропускать.
Задача: уменьшить число повторных уточнений при записи на выбранную услугу.
Аудитория: люди, которые хотят записаться на эту услугу в одной мастерской.
Основной сценарий: выбор вида работы и предпочтительного времени, ввод контакта, передача заявки администратору и понятное сообщение о её статусе.
Срок: три недели наблюдения после проверки сценария. Если заявок не хватит, можно один раз продлить пилот на заранее установленный срок, например на две недели. Не продлевайте его только потому, что результат пока не тот.
Ресурс: один человек отвечает за настройку и проверку; администратор обрабатывает заявки в установленное рабочее время; на поддержку бота отводится, например, до 15 минут в день. Это ориентир, а не норматив. Установите свой лимит — такой, которого сможете придерживаться.
Бюджет: сумма, которую можно потратить без нового согласования. Учтите настройку, возможную плату за сервис, сообщения, интеграции и поддержку. Если пилот не укладывается в предел без подключения нескольких платных систем, пересмотрите сценарий и исключите функции, не нужные для проверки.
Показатель успеха: доля заявок, пригодных к подтверждению без дополнительного сбора обязательных сведений. Заранее укажите целевое значение и минимальное количество заявок.
Условие остановки: признаки, по которым пилот завершится, будет доработан один раз или прекратится.
Полезно указать и ответственных за повседневные задачи. Кто меняет перечень услуг? Кто видит новые заявки? Кто разбирается, если сообщение не дошло? Кто проверяет показатели в конце недели? Если на каждый вопрос ответ «кто-нибудь», пилот не ограничен на практике, даже если сценарий короткий.
Ограничения защищают проект от незаметного удорожания. Один канал вместо запуска сразу во всех каналах. Одна услуга и одна точка вместо полного каталога. Передача заявок администратору вместо сложной синхронизации расписания — если для проверки гипотезы она не нужна. Настройка на уже доступном конструкторе без найма разработчика — если возможностей конструктора хватает. Но «без кода» не значит «без ответственности»: за тексты, права доступа, проверку заявок и поддержку всё равно должны отвечать конкретные люди.
Условие, при котором проект можно остановить
Если не назначить дату пересмотра, пилот легко превратится в вечный проект. Каждую неделю найдётся причина продлить его ещё немного: добавить услугу, переписать приветствие, дождаться более активного периода. Поэтому решение о продолжении лучше записать до запуска, пока результат ещё не влияет на самооценку команды.
Предусмотрите три исхода. Продолжить — если набран минимальный объём данных, цель достигнута, защитный показатель не ухудшился, а обслуживание укладывается в установленный лимит. Один раз скорректировать — если люди начинают сценарий, но регулярно останавливаются на одном и том же шаге или администратору неудобно работать с полученными данными. Остановить — если при достаточной видимости ботом не пользуются, качество заявок не растёт, ручной работы становится не меньше или расходы превышают ожидаемую экономию.