Автоматизация бизнес-процессов: карта для малого бизнеса

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

На наставничестве я слышу четыре типовых запроса, которые путают между собой:

Запрос «автоматизация процессов» в поиске тянет колледжи, производство и АСУТП — это другая аудитория. Для малого бизнеса я держу фокус на повторяющихся офисных цепочках: заявка, документ, напоминание, передача между людьми, учёт. Широкий вход «автоматизация бизнеса» полезен как напоминание, что рутина есть везде, но пилот всё равно один процесс за раз.

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

Карта процесса — одна страница, не презентация на двадцать слайдов. Я рисую as-is: как работает сейчас, до любого инструмента. Минимальный набор блоков:

1. 01

   Триггер — что запускает цепочку (сообщение клиента, оплата, дата в календаре, окончание смены).

2. 02

   Шаги — от пяти до пятнадцати действий по порядку, без идеализации («обычно делаем так»).

3. 03

   Ветки — ромбы: если да или нет, куда идёт поток (согласование, отказ, перенос).

4. 04

   Передачи — кто отдаёт кому: менеджер → бухгалтер, администратор → мастер.

5. 05

   Выход — что считается «готово» и где фиксируется результат.

6. 06

   Сбой — где уже были потери: дубли, забыли, клиент ушёл, документ не подписан.

Пример для салона красоты (упрощённо, как я вижу на разборах):

Триггер: клиент пишет в Telegram «хочу на стрижку в субботу»
→ администратор отвечает из личного чата (иногда с задержкой до обеда)
→ [ветка] запись / вопрос по цене / отказ
→ при записи: имя, услуга, мастер, слот → блокнот или Google Sheets
→ напоминание клиенту — вручную за день, если не забыли
→ выход: клиент пришёл / не пришёл (no-show)
→ сбой: ночное сообщение без ответа; двойная запись на один слот

Для студии дизайна или SMM-команды из трёх человек карта часто выглядит иначе — больше передач между ролями:

Триггер: заявка с сайта или DM «нужен логотип»
→ менеджер пересылает скрин в общий чат
→ [ветка] бриф полный / нужны уточнения / спам
→ при полном брифе: имя, бюджет, срок, ссылка на референсы → таблица «лиды»
→ дизайнер получает ссылку на строку вручную
→ выход: КП отправлено, сделка в работе или отказ
→ сбой: заявка зависла в чате без ответственного; КП ушло без фиксации в учёте

Для небольшого маркетингового агентства на пятерых я обычно начинаю с цепочки «лид → бриф → КП → счёт» — там чаще всего теряются деньги, а не в «красивом боте».

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

Полезные вопросы при заполнении карты:

• Где одно и то же вводят дважды в разные места?
• Какой шаг зависит от памяти конкретного человека?
• Что происходит, если ключевой сотрудник болеет?
• Есть ли письменное правило или «все знают»?

Карта живёт в Google Doc, Miro, бумаге — не важно. Важно, чтобы команда из двух–пяти человек узнала себя в схеме и спорила о шагах, а не о бренде CRM. Если после карты берёте в пилот вход заявок — сначала согласуйте поля и канал, потом инструмент.

Три критерия, на которые я опираюсь при выборе первого процесса (их же разбирают в материалах для предпринимателей про операционную рутину):

Плюс два практических фильтра с разборов:

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

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

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

Антипримеры для первого пилота:

• Согласование нестандартных договоров с юристом на каждую сделку.
• Креативная упаковка под каждого клиента без чеклиста.
• Полная автоматизация склада без учёта остатков.
• Внедрение ИИ в переписку до стабильного учёта — про границы ИИ писал отдельно.

После карты as-is я прогоняю процесс через пять вопросов да/нет. Ответы не «правильные» — они показывают, какой слой автоматизации достаточен на пилоте.

1. Повторяется не реже раза в неделю? Нет → не автоматизируем сейчас, фиксируем в регламенте. Да → дальше.

2. Шаги можно описать правилами без «на глаз»? Нет → сначала упростите сценарий или оставьте человека на ветках. Да → дальше.

3. Один ответственный или понятное правило назначения? Нет → назначьте владельца до инструмента. Да → дальше.

4. Нужна история по этапам и несколько исполнителей? Нет → таблица (Google Sheets, Airtable) + уведомления часто хватает. Да → смотрим CRM.

5. Нужна связка с оплатой, складом, внешним API или нестандартной логикой? Нет → бот + таблица или CRM-робот. Да → кастомный код или middleware (Make, Albato, свой скрипт) поверх согласованных полей.

Сводная таблица:

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

{
  "lead_id": "uuid",
  "created_at": "2026-08-02T14:30:00+03:00",
  "source": "telegram|site|phone",
  "client_name": "string",
  "contact": "phone_or_tg",
  "service_or_brief": "string",
  "budget_rub": "number|null",
  "deadline": "date|null",
  "assigned_to": "user_id",
  "status": "new|qualified|proposal_sent|won|lost",
  "notes": "string"
}

Если остаётесь на таблице, в Google Sheets для SLA «ответ в течение двух часов» я часто ставлю формулу в колонке «Просрочено?»:

=IF(AND(B2<>""; C2=""); IF(NOW()-A2>TIME(2;0;0); "ДА"; "нет"); "")

Где A2 — время создания строки, B2 — ответственный, C2 — время первого ответа. Красная заливка по условию ДА — уже половина пилота без кода.

Когда бот шлёт данные в n8n или Make, типичный webhook payload выглядит так:

{
  "event": "lead.created",
  "channel": "telegram",
  "payload": {
    "chat_id": 123456789,
    "username": "client_handle",
    "text": "Нужен сайт-визитка до конца месяца",
    "fields": {
      "service": "landing",
      "budget": "до 80к"
    }
  }
}

Я не меняю стек ради модного бота, если команда пять лет живёт в Bitrix. Сначала контур и поля; платформа вторична. Если уже есть таблица, с которой все работают каждый день — не обязательно «переезжать» в CRM на первой неделе. Достаточно автоматизировать запись и уведомление в ту же таблицу. Про вход из Telegram отдельно — чат-бот для бизнеса и интеграция Telegram с CRM.

Ошибка, которую вижу после чтения кейсов на vc.ru: покупают ERP «на вырост», пока не описан один процесс as-is. Карта на одной странице дешевле любой лицензии и снимает половину споров в команде.

Автоматизация бизнес-процессов малого бизнеса — не синоним «убрать людей». Есть зоны, куда я не веду пилот, пока нет дисциплины записи.

1. «Всё сразу». Пять процессов, три интеграции, новая CRM и чат-бот в один релиз — не пилот, а аврал. Один процесс, один критерий успеха.

2. Хаотичный процесс без владельца. Если каждый делает по-своему, автоматизация закрепит хаос. Сначала согласованный as-is и именованный ответственный.

3. Высокая цена ошибки без ревью. Автосписания, массовые рассылки с персональными данными, публикация цен без контекста — только с проверкой человека на пилоте.

4. Уникальные кейсы вместо повторяющихся 80%. Бот, который «понимает всё», на старте проигрывает кнопкам и короткому пути к оператору.

5. Промышленная и учебная семантика. Регламенты цеха, SCADA, дипломные схемы — не цель этой статьи. Офис, продажи, сервис, учёт.

6. ИИ до учёта. Пока нет стабильной записи и уведомлений, языковая модель только ускорит ответы без карточки в учёте.

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

Если узнаёте два и больше пункта — наставничество начинается с сужения, не с покупки лицензии.

На пилотах автоматизации для салонов, студий и агентств я вижу одни и те же сбои. Ниже — не абстрактные советы, а симптом в работе и конкретный фикс.

У салона на разборе был типичный кейс: администратор отвечала из личного Telegram, запись вела в блокноте. Бот поставили «для статуса», но напоминания остались ручными — no-show не снизились. Фикс: бот пишет в ту же Google-таблицу, откуда печатают расписание; напоминание — триггер из таблицы за 24 часа. Один источник правды, не два.

У агентства на пятерых менеджеров лиды падали в общий чат. CRM купили, но карточки не заводили — «долго». Фикс: бот в Telegram с четырьмя полями → строка в таблице → уведомление ответственному по очереди (round-robin в простой формуле или вручную на пилоте). CRM подключили только после двух недель без потерь в журнале.

Если в таблице больше трёх строк с одним и тем же симптомом за пилот — меняем сценарий, а не добавляем второй сервис.

Пилот — короткий прогон на реальном потоке с заранее записанным критерием. Без цифр это демо, которое не включают в работу.

Пример критерия для процесса заявок (адаптируйте под свой):

• 15–25 срабатываний триггера за две недели.
• 100% событий попадают в учёт с меткой времени.
• Уведомление ответственному — в согласованный SLA (например, до 2 минут).
• Не более одной ручной правки на пять операций.
• Ноль потерянных обращений по журналу канала.

Для студии, где вход — форма на сайте и DM в Instagram, я записываю отдельно: сколько заявок пришло в обход учёта (цель — ноль к концу второй недели).

Чеклист перед стартом пилота:

1. 01

   Карта as-is согласована с исполнителем, который делает процесс каждый день.

2. 02

   Именованный ответственный на каждый день недели.

3. 03

   Резервный, если основной недоступен.

4. 04

   Тестовый прогон проходит до записи в учёте.

5. 05

   Тестовое уведомление доходит в Telegram или почту.

6. 06

   Понятно, кто правит ошибочную запись.

7. 07

   Зафиксирован текст для клиента при задержке (если процесс клиентский).

8. 08

   Журнал исключений заведён в той же таблице или в отдельном листе.

Хороший стресс-тест: запустить сценарий в нерабочее время (пятница вечер). Должны сработать запись, уведомление или отложенное правило и понятный автоответ клиенту, если цепочка наружная.

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

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

Платный или бесплатный вход в работу — не покупка «системы автоматизации бизнеса» по каталогу. Я подключаюсь на наставничестве, когда:

• процессов несколько, а приоритет спорный;
• ветки в карте расходятся у владельца и исполнителей;
• уже пробовали CRM или бота, но учёт всё равно ручной;
• нужен нейтральный взгляд до оплаты разработчику или интегратору;
• команда хочет один документ: as-is, критерий пилота, рекомендация «таблица / бот / CRM / код».

На разборе я прошу brief в Telegram: название процесса, как часто повторяется, кто участвует, где последний раз что-то сломалось. Без этого созвон превращается в обзор рынка SaaS.

По теме в блоге:

• Автоматизация заявок — первый процесс, который чаще всего берут в пилот.
• Чат-бот для бизнеса — когда хватает входа из мессенджера и короткой анкеты.
• Внедрение ИИ в бизнес — куда подключать ИИ после стабильного контура, не вместо карты.

Cursor, правила в редакторе и MCP для разработчика — отдельный слой. Для владельца салона, агентства или небольшого магазина первый шаг остаётся бумажной картой и одним пилотом, а не настройкой IDE. Когда процесс описан и нужен свой скрипт или интеграция — тогда имеет смысл смотреть Cursor Rules и репозиторий с пилотом, а не наоборот.