Read the book: «Zero-code. Продажа ботов и автоматизаций под ключ»
Zero-Code: Продажа ботов и автоматизаций под ключ
Сергей Степанов
Введение
Владелец небольшой сервисной компании получает заявки из мессенджера, с сайта и по телефону. Часть обращений сотрудники переносят в CRM вручную. Иногда карточка появляется без номера телефона, иногда один запрос превращается в две сделки, иногда клиенту обещают перезвонить и забывают. Компания может купить ещё один сервис, но сама покупка не определит, кто должен обработать заявку и что считать успешным результатом.
ИИ-интегратор решает эту задачу на стыке процессов и технологий. Он выясняет, как компания работает, собирает связи между системами, ограничивает действия нейросети, проверяет сбои и передаёт заказчику решение, которым сотрудники смогут пользоваться. Для многих проектов не требуется глубокое знание Python. Однако придётся понимать структуру данных, права доступа, последовательность операций и ответственность за изменения.
Эта книга предназначена для IT-энтузиастов, веб-разработчиков и фрилансеров, которые хотят продавать такие решения малому бизнесу. Если вы уже умеете создавать сайты, полезным следующим шагом станет подключение заявок к CRM. Если начинаете с нуля, сначала потребуется освоить несколько технических понятий. Они вводятся по мере необходимости и сразу применяются в учебных задачах.
Название Zero-Code обозначает способ сборки основной логики через визуальные инструменты. Оно не обещает, что любая интеграция обойдётся без формул, запросов к API и помощи разработчика. Иногда небольшая программная доработка проще и надёжнее десятка обходных действий. Профессиональная работа предполагает умение замечать эту границу.
Проекты стоимостью от 30 000 до 150 000 рублей рассматриваются как возможные коммерческие предложения разного состава. Эти суммы не являются установленными рыночными тарифами или обещанием заработка. На стоимость влияют обследование процесса, количество систем, сложность согласований, требования к надёжности и условия поддержки. Все финансовые примеры в книге условные: их задача — показать расчёт, а не выдать прогноз дохода.
Технические примеры сверены с документацией платформ при подготовке книги в октябре 2026 года. Они описывают учебные настройки и ожидаемые результаты; фактический запуск требует доступных аккаунтов и проверки в вашей среде. Названия элементов интерфейса, тарифы и доступность отдельных интеграций могут меняться. Поэтому инструкции объясняют назначение настроек и признаки правильного результата. До покупки подписки проверяйте, что нужные функции доступны в конкретном аккаунте и регионе.
Через книгу проходит учебная компания «ТехСервис», которая принимает заявки на ремонт бытовой техники. Компания вымышленная. Её бот собирает контакт, уточняет проблему, передаёт обращение менеджеру и сохраняет сведения в CRM. Дополнительные примеры показывают, как тот же подход применять к заказам, внутренним запросам и работе с документами. Разработка ведётся на тестовых данных: реальные сведения клиентов подключаются только после согласования доступа и правил обработки.
Результатом обучения должна стать не коллекция красивых схем, а готовность выполнить ограниченный проект: описать его границы, собрать рабочую цепочку, подтвердить результат тестами, назначить цену и передать систему заказчику. Два первых проекта дают конкретные маршруты Make и n8n. Затем вы добавите анкету, CRM и нейросетевую обработку, а заполненный комплект рабочих документов поможет определить состав коммерческого заказа.
Глава 1. Что покупает заказчик
Автоматизация как завершённая работа
В учебном «ТехСервисе» менеджер переписывает из Telegram в CRM имя, телефон, вид техники и описание неисправности. На одно обращение условно уходит четыре минуты. Бот, который только красиво отвечает на вопросы, не убирает эту работу. Чтобы решить исходную задачу, нужно получить необходимые сведения, проверить их и создать связанную карточку обращения.
Разница между демонстрацией и услугой возникает в момент, когда решение включают в реальную работу. На демонстрации можно вручную отправить идеальное сообщение и показать созданную сделку. В эксплуатации человек пришлёт фотографию вместо текста, дважды нажмёт кнопку, изменит номер телефона или напишет после полуночи. Заказчик покупает обработку оговорённых ситуаций, а также понятный порядок действий для остальных.
Опишите результат через изменение процесса. Формулировка «умный бот с нейросетью» ничего не сообщает о границах. Формулировка «после подтверждения контакта бот создаёт обращение в CRM и уведомляет дежурного менеджера» позволяет обсудить данные, срок и проверку. Нейросеть может быть частью решения, но не заменяет описания результата.
Четыре зоны ответственности
Сначала интегратор исследует процесс: получает примеры заявок, узнаёт роли сотрудников, выясняет исключения. Затем проектирует решение: выбирает систему хранения, правила маршрутизации и точки человеческого контроля. После этого собирает и проверяет цепочку. Наконец, организует передачу и поддержку: объясняет сотрудникам, где искать ошибки и как восстановить работу.
Новичок часто оценивает только время сборки. Допустим, соединение трёх модулей заняло два часа. Но ещё потребовались встречи, доступ к CRM, согласование полей, исправление дублей и обучение администратора. Эти работы входят в проект, даже если не видны на полотне автоматизации. Их нужно учитывать в сроках и цене.
У исполнителя и клиента разные полномочия. Интегратор предлагает схему, но не решает самостоятельно, когда компания обязана вернуть деньги или какую скидку дать спорному клиенту. Такие правила утверждает уполномоченный представитель бизнеса. Если правило не определено, автоматизация должна передать вопрос сотруднику, а не придумать решение.
Как выбрать первую специализацию
Удобнее начинать с повторяющейся задачи в одной группе компаний. Например, принимать заявки для ремонтных служб, связывать формы сайтов с CRM для небольших агентств или формировать внутренние уведомления для учебных центров. Это позволяет глубже понять одинаковые ограничения и быстрее подготовить полезную демонстрацию.
Специализация не требует отвергать все остальные запросы. Она нужна для первого понятного предложения. «Подключаю заявки с вашего сайта к действующей CRM» легче проверить и купить, чем «автоматизирую бизнес любыми нейросетями». При этом выбранная услуга должна быть вам технически доступна: не обещайте голосового администратора, если пока собрали лишь текстовую форму.
Оцените задачу по трём признакам: повторяемость, доступность данных и ограниченность последствий ошибки. Перенос заявки обычно проще первого проекта по автоматическому возврату платежей. Сводка для менеджера безопаснее автономного изменения коммерческих условий. Такой порядок уменьшает стоимость обучения на реальном заказе.
Когда проект лучше не брать
Откажитесь от фиксированной цены до обследования, если клиент не может показать исходные данные, не назначает ответственного сотрудника или требует гарантировать рост продаж. Автоматизация влияет на отдельные этапы. Продажи зависят также от спроса, цены, качества услуги и работы менеджеров.
Отказ может быть частичным. Вместо полной перестройки предложите ограниченную диагностику: разобрать один канал заявок, описать проблемы и подготовить спецификацию. Если доступы или правила так и не появятся, у вас останется оплаченная завершённая работа, а у клиента — основание для следующего решения.
Для первой услуги запишите одним предложением: какой процесс меняется, что запускает автоматизацию, какой результат видит сотрудник и где требуется его подтверждение. Пока это предложение не получается конкретным, к выбору платформы переходить рано.
Глава 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 — отказ, а пустой телефон — незаполненное поле. Если проверять всё одним условием «значение есть», вы смешаете разные ситуации.
Сопоставление полей
Mapping, или сопоставление, связывает выход одного шага с входом другого. В поле телефона CRM выбирают значение подтверждённого контакта, а не произвольное последнее сообщение. Для названия сделки можно использовать шаблон с категорией и номером заявки.
Проверяйте путь к полю на конкретном событии. В сообщении Telegram текст и контакт находятся в разных структурах. У нажатия кнопки структура снова другая. Поэтому цепочка должна сначала определить тип события и лишь затем читать соответствующие значения.
Ошибки сопоставления часто не вызывают технического отказа. CRM успешно принимает строку с неправильным содержимым. Чтобы заметить проблему, сравнивайте исходное сообщение и полученную карточку, а не только зелёную отметку выполнения модуля.
HTTP
и
API
API — набор правил, по которым одна программа обращается к другой. Визуальный коннектор использует API внутри себя. Если нужного действия нет в готовом модуле, можно настроить HTTP-запрос вручную, не создавая отдельное приложение.
В запросе задают метод, адрес, авторизацию, заголовки и тело. GET обычно читает сведения, POST часто создаёт объект или запускает действие, PATCH обычно изменяет часть объекта. Конкретный смысл определяется документацией сервиса: нельзя выбирать метод только по привычке.
Код ответа помогает понять результат. 401 обычно связан с авторизацией, 403 — с правами, 429 — с ограничением частоты. При этом успешный HTTP-ответ ещё не гарантирует бизнес-успех: некоторые API возвращают описание ошибки внутри тела ответа. Проверяйте оба уровня.
Чтение незнакомого ответа
Возьмите тестовый ответ и найдите три вещи: где расположен полезный объект, где его идентификатор и как сервис сообщает об ошибке. Затем сопоставьте только необходимые поля. Попытка перенести всю структуру сразу увеличивает риск перепутать вложенные значения.
Если поле отсутствует, выясните, это нормальная ситуация или дефект. Например, у нового контакта может не быть email. Для создания заявки это допустимо, если email не обязателен. Но отсутствие идентификатора после операции создания означает, что результат ещё не подтверждён.
