Коммерческие автоматизациичасть 1 из 8
- 01Концепция: какие автоматизации окупаются
- 02Фундамент: сервер, база и деплой по пушу
- 03Сердце системы: события, очередь и повторы
- 04Заменяем продажника: заявка, квалификация и менеджер за минуту
- 05Заменяем бухгалтера: оплаты, доступы и напоминания о долгах
- 06Заменяем поддержку: разбор входящих и черновики ответов
- 07Заменяем аналитика: утренняя сводка и тревоги
- 08Эксплуатация: мониторинг, бэкапы, секреты и стоимость
О чём цикл
Слово «автоматизация» обычно означает одно из двух. Либо цепочку в Zapier, которая пересылает заявку из формы в таблицу. Либо большой проект внедрения, который длится год. Нас интересует середина: небольшие программы, которые работают сами, экономят людям часы или возвращают деньги, и при этом не ломаются от первого же сбоя у внешнего сервиса.
Чтобы примеры были предметными, возьмём типичную небольшую компанию, которая продаёт услугу или подписку онлайн. У неё есть:
- сайт с формой заявки;
- менеджеры, которые обрабатывают заявки и ведут клиентов в CRM;
- приём оплат через платёжный сервис;
- поддержка в почте и в Telegram;
- руководитель, который хочет знать цифры.
Это может быть онлайн-школа, студия, SaaS или агентство. Конкретная отрасль неважна, процессы у всех похожи.
Где бизнес теряет деньги
Прежде чем что-то автоматизировать, полезно пройтись по процессам и для каждого спросить: где здесь утекают деньги или время. В нашей компании картина примерно такая.
Заявки ждут. Человек оставил заявку в 19:40, менеджер увидел её утром. За это время клиент успел написать конкурентам. Чем быстрее ответ, тем выше шанс продажи, и это одна из самых дешёвых в реализации и самых заметных по деньгам автоматизаций.
Оплаты теряются. Карта не прошла, подписка не продлилась, счёт выставлен и забыт. Каждый такой случай это выручка, которая уже почти была получена. Без автоматики их замечают, только когда клиент уходит.
Ручная выдача. Клиент заплатил, а доступ к курсу, ключ или чек ему отправляет человек. Ночью и в выходные клиент ждёт.
Поддержка тонет в однотипных вопросах. Половина писем это «где мой доступ», «как сменить тариф», «пришлите закрывающие документы». Каждое занимает пару минут, но их сотни.
Отчёты собирают руками. Каждый понедельник кто-то выгружает данные из CRM и платёжки и сводит их в таблицу. А просевшую конверсию замечают через месяц, когда уже поздно.
Как выбрать, что автоматизировать
На любую идею автоматизации можно посмотреть через четыре вопроса.
- Как часто это происходит? Процесс, который случается раз в квартал, автоматизировать почти никогда не выгодно. Десятки раз в день почти всегда выгодно.
- Сколько времени занимает у человека? Умножьте на частоту, получите часы в месяц.
- Сколько стоит задержка? Для заявки задержка стоит упущенной продажи. Для отчёта почти ничего.
- Сколько стоит ошибка? Если автоматика ошибётся, что будет? Неверно размеченное письмо исправит оператор. Двойное списание с карты клиента это жалоба и возврат.
Первые три вопроса говорят, сколько автоматизация принесёт. Четвёртый говорит, насколько аккуратно её нужно делать. Отсюда простое правило: начинать с процессов, которые частые, медленные и дорогие по задержке, а там, где ошибка дорогая, оставлять последнее слово человеку.
Если разложить наши пять процессов по этим вопросам, получится порядок, в котором идёт цикл:
| Процесс | Частота | Цена задержки | Цена ошибки | Что делаем |
|---|---|---|---|---|
| Заявки | каждый день | высокая | низкая | полностью автоматически |
| Оплаты и доступы | каждый день | высокая | высокая | автоматически, но с идемпотентностью и журналом |
| Неоплаченные счета | каждую неделю | средняя | средняя | автоматические напоминания |
| Поддержка | каждый день | средняя | средняя | модель готовит черновик, человек отправляет |
| Отчёты и тревоги | каждый день | низкая, пока всё хорошо | низкая | полностью автоматически |
Что мы построим
По одной автоматизации на каждую часть, все на общем фундаменте. Каждая забирает рутину у одной роли в компании.
Заменяем продажника. Заявка с сайта сразу попадает в систему. Модель достаёт из свободного текста, что человеку нужно, оценивает, насколько заявка горячая, и через минуту менеджер получает в Telegram карточку с кнопками «беру» и «спам», а в CRM появляется сделка. Если никто не взял заявку за 15 минут, бот напоминает.
Заменяем бухгалтера. Платёжный сервис присылает событие об оплате, и система сама выдаёт доступ и отправляет чек, ровно один раз, даже если событие пришло трижды. Неудавшиеся платежи и неоплаченные счета получают цепочку вежливых напоминаний, которая останавливается, как только клиент заплатил.
Заменяем поддержку. Входящие письма и сообщения разбираются по типам. На однотипные вопросы модель готовит черновик ответа по базе знаний, оператор правит и отправляет одной кнопкой. Сама модель клиенту ничего не отправляет.
Заменяем аналитика. Каждое утро в общий чат приходит сводка: заявки, оплаты, выручка, сравнение с прошлой неделей. Если что-то резко просело, например заявок с сайта за день ноль, тревога приходит сразу, а не в понедельник.
Готовый сервис или свой код
Для автоматизаций есть готовые инструменты: Zapier, Make, n8n. Они хороши, и для многих задач их достаточно. Честное сравнение:
No-code сервисы хороши, когда цепочка короткая (из формы в таблицу, из таблицы в почту), логика простая, а цена ошибки низкая. Их быстро собрать, и с ними справится не программист. n8n к тому же можно поднять на своём сервере.
Свой код выигрывает, когда:
- в логике есть ветвления, состояния и ожидания: «напомнить через 15 минут, если никто не взял»;
- речь идёт о деньгах, и нужно гарантировать, что действие выполнится ровно один раз;
- нужны тесты и история изменений в git;
- объём растёт, а платить за каждую операцию в облачном сервисе становится дорого;
- внутри нужна модель, которая разбирает текст, с вашими промптами и проверками.
В цикле мы пишем свой код, потому что все четыре автоматизации попадают хотя бы в один из этих пунктов. Но код получится небольшим: несколько сотен строк на TypeScript, без фреймворков.
Архитектура
Приёмник событий. Небольшой HTTP-сервер. Всё, что приходит снаружи (заявка с сайта, вебхук платёжки, сообщение боту), он проверяет, сохраняет в базу и сразу отвечает. Никакой бизнес-логики в момент приёма: если CRM в эту секунду недоступна, мы не должны потерять заявку.
Postgres. И база, и очередь. Для небольшого бизнеса отдельный брокер сообщений вроде RabbitMQ или Redis не нужен: Postgres умеет раздавать задачи воркерам без двойной обработки (FOR UPDATE SKIP LOCKED), и у нас на одну систему меньше, которую нужно поднимать, бэкапить и мониторить.
Воркер. Берёт задачи из очереди и выполняет: отправить сообщение, создать сделку, выдать доступ, спросить модель. Если внешний сервис ответил ошибкой, задача повторяется позже с растущей паузой. Если не получилось за несколько попыток, задача помечается как упавшая, и об этом приходит уведомление.
Расписание. Часть автоматизаций запускается не событием, а временем: утренняя сводка, проверка неоплаченных счетов. Расписание просто кладёт задачи в ту же очередь.
Принципы
- Сначала сохранить, потом обработать. Входящее событие записывается в базу до любой логики. Тогда сбой где угодно дальше не теряет данные, а событие можно переиграть.
- Каждое действие идемпотентно. Платёжки и мессенджеры присылают одно событие повторно, воркер может упасть посреди задачи. Повторное выполнение не должно выдать доступ дважды или списать деньги второй раз.
- Сбои это норма. Любой внешний API когда-нибудь ответит ошибкой или не ответит вовсе. Повторы с паузами и понятный статус «упало» встроены в ядро, а не дописываются потом.
- Человек там, где ошибка дорогая. Модель готовит черновик ответа клиенту, но отправляет человек. Возврат денег делает человек.
- Всё записано. Какое событие пришло, какие задачи породило, что ответили внешние сервисы. Без этого невозможно ответить на вопрос «почему клиенту не пришёл доступ».
- Дёшево и скучно. Один сервер, проверенные инструменты, минимум движущихся частей. Автоматизация, которую страшно трогать, хуже ручного процесса.
Инструменты
Здесь короткий обзор, подробности в следующих частях.
| Задача | Берём | Почему | Альтернативы |
|---|---|---|---|
| Язык и рантайм | 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, который принимает события и складывает их в базу.