Kitabı oxu: «Боты без лишнего кода. Как создать чат-бота для бизнеса и личных задач»

Бот решает задачу, а не украшает бизнес

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

Через несколько минут звонит телефон, затем приходит сообщение о готовом велосипеде и вопрос о наличии камер. Павел в это время принимает велосипед у входа и записывает данные клиента. Позже Ирина открывает переписку и видит ответ Марины: «Завтра в десять подойдёт». Но успел ли кто-нибудь подтвердить время? В календаре имени Марины нет. Сообщение не пропало — оно затерялось среди других, а договорённость так и осталась между предложением и записью.

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

Сначала задача, потом инструмент

Разговор о боте часто начинается с вопроса: «Где его сделать?» Но конструктор не подскажет, что именно поручить автоматике. Если сначала не разобраться в процессе, бот быстро и одинаково ответит на ненужные клиенту вопросы, соберёт данные, которые никто не обработает, или подтвердит запись, которой на самом деле нет.

Чат-бот без кода — это настроенный сценарий общения в чате. Он задаёт вопросы, выдаёт подготовленные ответы, передаёт информацию или запускает действия по заданным правилам. Бота собирают из готовых блоков в визуальном конструкторе, а не программируют с нуля. Простой сценарий может выглядеть так: человек выбирает услугу, указывает удобный день, оставляет контакт, получает подтверждение или сообщение о следующем шаге.

Такой бот не обязательно использует искусственный интеллект. Меню с кнопками и понятными условиями — уже бот. И наоборот: если сотрудник вручную отправляет заготовленные сообщения, это ещё не полноценная автоматизация, хотя со стороны может казаться, что ответы приходят «системно». Для решения практической задачи важнее не название технологии, а то, кто или что выполняет следующий шаг.

В повторяющемся процессе обычно встречаются три вида работы.

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

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

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

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

Путь Марины — от первого вопроса до записи

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

Первый шаг — обращение. Марина спрашивает о стоимости и времени. Автоматизировать здесь можно только то, что мастерская знает заранее. Бот способен сообщить часы работы и адрес, назвать цену диагностики, если она установлена, и объяснить, что окончательная стоимость ремонта зависит от осмотра. Если стоимость меняется в зависимости от обстоятельств, не нужно прятать ответ за меню. Лучше сразу обозначить границу: «Диагностика стоит по действующему прайсу. Стоимость ремонта назовём после осмотра».

Такой ответ экономит время и не создаёт ложных обещаний. Клиенту проще решить, стоит ли продолжать, а мастерской не приходится разбирать по переписке каждую возможную неисправность.

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

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

Третий шаг — выбор времени. Здесь маршрут особенно уязвим. Ответ «завтра в десять подойдёт» означает, что клиенту удобно предложенное время, но ещё не обязательно, что мастерская внесла запись в расписание. В случае Марины именно это различие осталось неясным.

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

Для первого запуска Павел предлагает честную формулировку: «Вы отправили заявку на завтра, 10:00. Администратор проверит расписание и подтвердит запись сообщением». Ирина уточняет: клиенту нужно назвать срок ответа — например, в рабочее время в течение часа, если команда действительно может его соблюдать. Обещание «скоро ответим» не помогает планировать ни клиенту, ни сотруднику.

Четвёртый шаг — подтверждение. После проверки расписания клиенту нужно отправить короткое сообщение с датой, временем, видом услуги и адресом. Если запись пока предварительная, так и следует написать. Можно добавить возможность перенести или отменить визит, чтобы изменение не затерялось в переписке. Напоминание перед визитом полезно, только если в нём указаны верные дата и время и клиент понимает, как сообщить об изменении планов.

В итоге карта процесса «Спицы» выглядит так.

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

Уточнение услуги: выбрать категорию и собрать описание проблемы можно по повторяющемуся сценарию. Причину неисправности и объём ремонта определяет мастер.

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

Подтверждение: отправить детали записи и напоминание можно автоматически. Изменение срока ремонта или срочную проблему нужно передать человеку.

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

Что автоматизация снимает, а что добавляет

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

Если типовых вопросов много, бот или даже готовый ответ сокращает число таких переключений. Если в каждой заявке нужно собрать одни и те же сведения, автоматизированный сбор избавит от вопросов вроде «Какой у вас велосипед?», «В чём проблема?» и «Когда удобно приехать?». А автоматическое напоминание снижает риск, что заявка останется без ответа.

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

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

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

У Ирины есть причина не автоматизировать всё подряд. Если Марина пишет: «После падения колесо стало криво, можно доехать до вас?», быстрый ответ с кнопками не обязательно будет лучшим решением. Здесь важнее осторожность, а не скорость. Мастер может уточнить обстоятельства или посоветовать доставить велосипед другим способом. Бот способен обозначить границу своих возможностей и переключить диалог на сотрудника, но не должен вести себя так, будто осмотр уже состоялся.

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

Реплики, которые не создают ложных ожиданий

Павел выписывает короткие сообщения, которые пригодятся независимо от того, выберет мастерская бота или форму. Ирина оценивает их не по красоте, а по простому вопросу: что клиент поймёт после прочтения?

Для типового вопроса:

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

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

Для заявки без автоматического доступа к расписанию:

«Укажите желаемые день и время. Мы проверим расписание и напишем, удалось ли закрепить этот интервал. До подтверждения заявка не считается записью».

Для автоматической записи при синхронизированном расписании:

«Вы записаны на 14 июня, 10:00, на диагностику велосипеда. Если планы изменятся, ответьте на это сообщение, чтобы перенести или отменить визит».

Для нестандартного случая:

«По описанию нельзя надёжно определить причину неисправности. Передам сообщение мастеру. Если проблема связана с тормозами или повреждением рамы, не используйте велосипед до осмотра».

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

Павел предлагает добавить кнопку «Позвать сотрудника». Ирина спрашивает, кто будет отвечать на такие обращения. Это не мелочь интерфейса, а часть сценария. У кнопки должен быть ответственный — сотрудник, который увидит сообщение и знает, когда на него нужно ответить. Если такого человека нет, лучше честно указать порядок: «Оставьте сообщение, администратор ответит в рабочее время». Бот не должен создавать впечатление, что кто-то уже взялся за обращение.

Выбрать между ботом, формой и готовым ответом

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

Готовый ответ подходит, если вопрос повторяется, ответ не меняется и собирать сведения или запускать дальнейшие действия не нужно. Например, так можно сообщить адрес мастерской, часы работы, цену диагностики или объяснить, как подготовить велосипед к приёму. Такой ответ не запишет человека, зато избавит от десятков одинаковых объяснений.

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

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

Решение можно принять, ответив на три вопроса.

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

2. Нужно собрать один и тот же набор сведений? Начните с формы. Она особенно уместна, когда человек может заполнить всё за один раз, а дальше с заявкой работает сотрудник.

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

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

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

Короткая проверка перед запуском

Чтобы не начинать с конструктора, сформулируйте проблему одним предложением: «Когда происходит [событие], человеку или команде приходится [лишнее действие или сбой], из-за чего [конкретное последствие]». Для «Спицы» получится так: «Когда клиент пишет о ремонте, Ирина и Павел вручную уточняют одни и те же сведения и сверяют время в разных местах, поэтому заявки могут оставаться без подтверждения».

Затем опишите желаемый результат: «После первого обращения клиент должен понимать условия и либо получить подтверждённую запись, либо знать, что мастерская ещё проверяет время». Так станет ясно, что считается завершённой работой. «Бот отвечает быстрее» — расплывчатый результат. «Клиент отличает заявку от подтверждённой записи» — проверяемый.

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

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

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

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

Где теряется время и заявка

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

Утром в мастерской звонил телефон, у верстака ждал велосипед с погнутым колесом, а Павел, администратор, отвечал на сообщения между разговорами с клиентами у стойки. Ирина посмотрела на пустые окна в расписании и сказала:

— Нужно привлекать больше людей. Обращений должно стать больше.

Павел возразил осторожно:

— Я помню несколько случаев, когда люди спрашивали про ремонт, а потом мы не могли найти переписку.

Это звучало правдоподобно, но ещё не было доказательством. Ирина помнила клиентку, которая, кажется, ушла к конкурентам. Павел — сообщения, оставшиеся без ответа. Оба могли быть правы, но отдельные воспоминания не показывали, как часто случается сбой и насколько он мешает работе мастерской.

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

Версии, которые звучат убедительно

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

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

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

«Бот автоматически устранит ошибки». Он может собирать сведения в одном формате и не забывать задать обязательный вопрос. Но если мастерская не знает, какие данные нужны для записи, или расписание ведётся в нескольких местах, бот ускорит передачу неверной информации. Автоматизация ускоряет процесс, но сама по себе не исправляет плохие правила.

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

Следы вместо воспоминаний

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

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

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

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

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

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

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

Два разных времени

При разборе Павел заметил, что фраза «долго отвечали» скрывает два разных показателя.

Первый — ожидание клиента: сколько прошло от первого сообщения до содержательного ответа. Второй — рабочее время сотрудника: сколько минут Павел потратил на ответ, уточнения, запись и исправления. Между ними может быть большая разница. Павел мог потратить три минуты на короткий ответ, но отправить его через час, потому что сначала закончил разговор у стойки. Или быстро отреагировать на сообщение, а затем ещё десять минут искать расписание и переносить данные.

В журнал можно заносить оба показателя. Ожидание видно по временным отметкам в канале. Рабочее время на первом этапе достаточно оценивать приблизительно: две минуты на ответ, три — на уточнение, ещё две — на внесение записи. Если действие трудно измерить точно, лучше указать диапазон, чем делать вид, будто известна каждая секунда.

Отдельно учитывайте часы работы. Если клиент написал в 17:42, а мастерская закрылась в 18:00 и ответила в 09:14 следующего дня, календарное ожидание составило пятнадцать часов тридцать две минуты. Но в рабочее время попали только тридцать две минуты: восемнадцать до закрытия и четырнадцать после открытия. Клиенту важно календарное ожидание, а для оценки нагрузки на администратора полезно знать и рабочее. Не подменяйте одно другим.

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

Цена пропуска и ошибки

Павел предположил, что пропущенный звонок, вероятно, лишил мастерскую заказа. Аналитик предложил разделить три утверждения.

«Обращение не найдено» — наблюдаемый факт, если записи действительно нет.

«Клиент не записался» — тоже факт, если это удалось проверить, например по расписанию и переписке.

«Клиент не записался именно из-за нашей задержки» — уже вывод о причине. Он убедительнее, если человек прямо говорит об этом, но не позволяет автоматически объяснить все случаи отсутствия ответа.

Чтобы оценить цену ошибки, сначала полезно измерить её последствия в том, что можно подтвердить. Сколько раз пришлось перезвонить? Сколько минут ушло на исправление? Заняли ли неподходящий слот? Клиент приехал не в тот день? Механик ждал велосипед, который так и не привезли? Такая проверка показывает цену сбоя, даже если потерянную продажу невозможно доказать.

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

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

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

Узкое место — не то же самое, что удобный сценарий

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

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

Высокая частота сама по себе не делает задачу подходящей для бота. Если люди часто спрашивают, сколько точно продлится ремонт велосипеда, а срок зависит от диагностики и очереди, бот не должен придумывать ответ ради скорости. Он может объяснить, какие сведения нужны, собрать их и передать сотруднику. А на вопрос со стабильным ответом — например, где находится мастерская или как записаться на диагностику, — бот может ответить сразу.

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

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

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

Как провести собственную проверку