Сергей Степанов – Zero-code. Продажа ботов и автоматизаций под ключ (страница 2)

Для каждого перехода задайте вопрос об исключении. Что происходит, если телефон отсутствует? Если клиент уже есть в CRM? Если услуга не оказывается в его районе? Если менеджер не работает сегодня? Необязательно автоматизировать каждое исключение, но должно быть понятно, кому оно передаётся.

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

Исходные показатели

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

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

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

Выбор первого улучшения

Условно компания получает 450 обращений в месяц. Копирование каждого занимает четыре минуты: 450 × 4 = 1800 минут, или 30 часов. При условной внутренней стоимости часа 600 рублей получается 18 000 рублей времени. Это оценка ресурса, а не автоматическая экономия денег: зарплата может остаться прежней.

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

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

Практическое задание

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

Если получить примеры невозможно, используйте вымышленные записи и прямо обозначьте учебный статус. Такая работа помогает освоить инструменты, но не даёт оснований утверждать, что реальному бизнесу уже рассчитан эффект. Для коммерческого проекта обследование всё равно потребуется.

Глава 3. Как превратить разговор в спецификацию

Граница между просьбой и обязательством

Клиент говорит: «Хочу, чтобы бот отвечал клиентам и всё заносил в CRM». В этой просьбе не определены виды вопросов, обязательные сведения, правила создания карточек и роль менеджера. Если начать сборку сразу, каждое уточнение будет восприниматься как исправление вашей ошибки.

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

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

Обязательные данные

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

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

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

Проверяемые критерии

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

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

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

Правила изменения объёма

После согласования клиент может попросить добавить запись в календарь. Это разумное развитие, но оно меняет исходный результат. Запишите запрос, оцените влияние на сроки и бюджет, предложите отдельный этап. Не спорьте о том, «маленькая» ли функция: оценивать нужно новые состояния и последствия ошибки.

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

Документирование решений

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

Для «ТехСервиса» можно записать: «Версия 1.2. Контакт подтверждается отдельной кнопкой. При отсутствии района заявка создаётся со статусом “Нужно уточнение”. Окончательная цена сообщается менеджером». Такая запись устраняет сразу несколько будущих споров.

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

Глава 4. Данные и события без глубокого программирования

Из чего состоит цепочка

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

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

Каждое выполнение должно иметь прослеживаемый идентификатор. Это технический номер, по которому связывают входное событие, запись в журнале и карточку CRM. Он нужен для поиска ошибок и защиты от повторов. Имя клиента для этой цели не подходит: имена повторяются и меняются.

Объекты и массивы

Объект хранит именованные поля. У заявки есть request_id, service_type и problem_text. Массив — упорядоченный набор элементов, например список вложений. Если вы ожидаете один объект, а сервис вернул массив, прямое сопоставление полей может не сработать.

В JSON, распространённом формате обмена, объект заключают в фигурные скобки, массив — в квадратные. Пример учебной записи: {"request_id":"R-104","service_type":"washer","problem_text":"Не сливает воду","confirmed":true}. Значение true является логическим признаком, а не текстом «да».

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