balkhaev.com Блог · AI-агенты и автоматизации

Коммерческие автоматизациичасть 1 из 8

Концепция: какие автоматизации окупаются

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

обновлено 8 мин чтенияautomationarchitecture

Коммерческие автоматизациичасть 1 из 8
  1. 01Концепция: какие автоматизации окупаются
  2. 02Фундамент: сервер, база и деплой по пушу
  3. 03Сердце системы: события, очередь и повторы
  4. 04Заменяем продажника: заявка, квалификация и менеджер за минуту
  5. 05Заменяем бухгалтера: оплаты, доступы и напоминания о долгах
  6. 06Заменяем поддержку: разбор входящих и черновики ответов
  7. 07Заменяем аналитика: утренняя сводка и тревоги
  8. 08Эксплуатация: мониторинг, бэкапы, секреты и стоимость

О чём цикл

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

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

  • сайт с формой заявки;
  • менеджеры, которые обрабатывают заявки и ведут клиентов в CRM;
  • приём оплат через платёжный сервис;
  • поддержка в почте и в Telegram;
  • руководитель, который хочет знать цифры.

Это может быть онлайн-школа, студия, SaaS или агентство. Конкретная отрасль неважна, процессы у всех похожи.

Где бизнес теряет деньги

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

Заявки ждут. Человек оставил заявку в 19:40, менеджер увидел её утром. За это время клиент успел написать конкурентам. Чем быстрее ответ, тем выше шанс продажи, и это одна из самых дешёвых в реализации и самых заметных по деньгам автоматизаций.

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

Ручная выдача. Клиент заплатил, а доступ к курсу, ключ или чек ему отправляет человек. Ночью и в выходные клиент ждёт.

Поддержка тонет в однотипных вопросах. Половина писем это «где мой доступ», «как сменить тариф», «пришлите закрывающие документы». Каждое занимает пару минут, но их сотни.

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

Как выбрать, что автоматизировать

На любую идею автоматизации можно посмотреть через четыре вопроса.

  1. Как часто это происходит? Процесс, который случается раз в квартал, автоматизировать почти никогда не выгодно. Десятки раз в день почти всегда выгодно.
  2. Сколько времени занимает у человека? Умножьте на частоту, получите часы в месяц.
  3. Сколько стоит задержка? Для заявки задержка стоит упущенной продажи. Для отчёта почти ничего.
  4. Сколько стоит ошибка? Если автоматика ошибётся, что будет? Неверно размеченное письмо исправит оператор. Двойное списание с карты клиента это жалоба и возврат.

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

Если разложить наши пять процессов по этим вопросам, получится порядок, в котором идёт цикл:

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

Что мы построим

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

Заменяем продажника. Заявка с сайта сразу попадает в систему. Модель достаёт из свободного текста, что человеку нужно, оценивает, насколько заявка горячая, и через минуту менеджер получает в Telegram карточку с кнопками «беру» и «спам», а в CRM появляется сделка. Если никто не взял заявку за 15 минут, бот напоминает.

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

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

Заменяем аналитика. Каждое утро в общий чат приходит сводка: заявки, оплаты, выручка, сравнение с прошлой неделей. Если что-то резко просело, например заявок с сайта за день ноль, тревога приходит сразу, а не в понедельник.

Готовый сервис или свой код

Для автоматизаций есть готовые инструменты: Zapier, Make, n8n. Они хороши, и для многих задач их достаточно. Честное сравнение:

No-code сервисы хороши, когда цепочка короткая (из формы в таблицу, из таблицы в почту), логика простая, а цена ошибки низкая. Их быстро собрать, и с ними справится не программист. n8n к тому же можно поднять на своём сервере.

Свой код выигрывает, когда:

  • в логике есть ветвления, состояния и ожидания: «напомнить через 15 минут, если никто не взял»;
  • речь идёт о деньгах, и нужно гарантировать, что действие выполнится ровно один раз;
  • нужны тесты и история изменений в git;
  • объём растёт, а платить за каждую операцию в облачном сервисе становится дорого;
  • внутри нужна модель, которая разбирает текст, с вашими промптами и проверками.

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

Архитектура

Сайт Платёжка Почта / Telegram Расписание Приёмник событий (HTTP)проверяет подпись, сохраняет событие, отвечает 200 Postgresсобытия · очередь задач · состояние (лиды, счета) Воркерберёт задачу, выполняет, при сбое повторяет Telegram CRM Платёжка Модель (Claude)

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

Postgres. И база, и очередь. Для небольшого бизнеса отдельный брокер сообщений вроде RabbitMQ или Redis не нужен: Postgres умеет раздавать задачи воркерам без двойной обработки (FOR UPDATE SKIP LOCKED), и у нас на одну систему меньше, которую нужно поднимать, бэкапить и мониторить.

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

Расписание. Часть автоматизаций запускается не событием, а временем: утренняя сводка, проверка неоплаченных счетов. Расписание просто кладёт задачи в ту же очередь.

Принципы

  1. Сначала сохранить, потом обработать. Входящее событие записывается в базу до любой логики. Тогда сбой где угодно дальше не теряет данные, а событие можно переиграть.
  2. Каждое действие идемпотентно. Платёжки и мессенджеры присылают одно событие повторно, воркер может упасть посреди задачи. Повторное выполнение не должно выдать доступ дважды или списать деньги второй раз.
  3. Сбои это норма. Любой внешний API когда-нибудь ответит ошибкой или не ответит вовсе. Повторы с паузами и понятный статус «упало» встроены в ядро, а не дописываются потом.
  4. Человек там, где ошибка дорогая. Модель готовит черновик ответа клиенту, но отправляет человек. Возврат денег делает человек.
  5. Всё записано. Какое событие пришло, какие задачи породило, что ответили внешние сервисы. Без этого невозможно ответить на вопрос «почему клиенту не пришёл доступ».
  6. Дёшево и скучно. Один сервер, проверенные инструменты, минимум движущихся частей. Автоматизация, которую страшно трогать, хуже ручного процесса.

Инструменты

Здесь короткий обзор, подробности в следующих частях.

Задача Берём Почему Альтернативы
Язык и рантайм TypeScript, Bun быстрый старт, встроенные HTTP-сервер, клиент Postgres и тесты Node.js, Go, Python
Хостинг один VPS предсказуемая цена, нет ограничений на фоновые процессы и расписание PaaS (Render, Railway, Fly.io), serverless
Запуск Docker Compose весь сервис описан одним файлом в репозитории Coolify, Dokku, Kamal
HTTPS Caddy сам получает и продлевает сертификаты nginx и certbot, Traefik
База и очередь Postgres одна система для данных и очереди Redis, RabbitMQ, SQS
Деплой GitHub Actions деплой по пушу в main, тот же репозиторий GitLab CI, ручной деплой
Уведомления Telegram-бот бесплатно, мгновенно, есть кнопки Slack, почта
Понимание текста Claude API извлечение данных из заявок, разбор писем, черновики другие коммерческие модели

Про хостинг стоит сказать отдельно. Serverless-платформы удобны для сайтов, но автоматизациям нужны фоновые процессы, расписание и база рядом, и на serverless всё это приходится собирать из отдельных платных сервисов. VPS на пару ядер стоит несколько евро в месяц у любого крупного провайдера и с запасом тянет все автоматизации небольшой компании. Если команда не хочет заниматься сервером совсем, Docker Compose из следующей части без изменений запускается в Coolify или на PaaS.

Что дальше

В следующей части строим фундамент: арендуем сервер, настраиваем его, пишем первый сервис на Bun с базой и миграциями, упаковываем в Docker и настраиваем деплой по пушу в main. К концу части у нас будет работающий адрес с HTTPS, который принимает события и складывает их в базу.