user10429766

- кто должен ответить и что считается «заявка принята»;

- исключения: звонок вместо бота, повторный клиент, отказ после цены.

Пока правда «в трёх чатах» — не выбирайте CRM. Сначала поток, потом инструмент.

Шаг 2. Четыре звена минимума

Рабочий минимум — не ИИ, а цепочка:

1. Канал — один основной вход (бот или форма с webhook).

2. Квалификация — 3–5 полей: имя, услуга/тема, срок, комментарий, контакт.

3. Учёт — строка в Google Sheets / Airtable или карточка в amo / Bitrix.

4. Человек — пуш ответственному + эскалация, если статус «новая» висит.

Приём и продажа — разные задачи. На приёме не закрываем сделку: не теряем контакт и даём контекст. Цены, спорные кейсы, жалобы — человеку.

Для ИП часто хватает: Telegram — таблица — пуш в тот же Telegram. CRM — когда поток стабилен и поля уже согласованы.

На пилоте мне хватает детерминированной логики:

- кнопки «Запись / Вопрос / Жалоба» в первом сообщении;

- обязательные имя + телефон или @username;

- таймаут: молчит 10 минут — черновик карточки и напоминание оператору;

- явный выход «позвать человека» без всей ветки;

- короткое подтверждение клиенту: «приняли, ответим в течение…».

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

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

Правило поля: зачем менеджеру это до первого контакта? Нет ответа — убираем или переносим после звонка.

Таблица ок, если:

- один ответственный или владелец сам ведёт заявку;

- до ~30–50 заявок в месяц и вы их реально смотрите;

- хватает статусов: новая / в работе / закрыта (иногда «отказ»);

- не нужны напоминания по этапам сделки.

CRM имеет смысл, если:

- двое и больше менеджеров, нужен владелец карточки;

- есть этапы: квалификация — КП — оплата — постпродаж;

- нужны «перезвонить завтра», «ждём документы»;

- руководитель смотрит воронку, а не только список новых строк.

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

1. «Умный агент» до стабильного приёма — бот вежливо отвечает, учёт остаётся ручным.

2. Пять каналов сразу — четыре типа сбоев одновременно. На пилоте один вход, остальные ведут сюда автоответом или ссылкой.

3. CRM «на вырост» при 15 заявках в месяц и одном менеджере.

4. Цены и обещания в автоответе без ревью.

5. Оплату до карточки заявки («деньги уже прошли, а в учёте пусто»).

6. Эскалацию на десять ролей — все перестают реагировать. Один ответственный, один резервный.

7. Жалобы и конфликты шаблоном — бот принимает текст и создаёт срочную карточку, отвечает человек.

Простой SLA на пилот:

- уведомление ответственному ≤ 2 минут после записи;

- первый ответ клиенту — в согласованный срок (например, 30 минут в рабочие часы);

- если «новая» висит 2 часа — второе уведомление или смена ответственного;

- ночью — автоответ с ожидаемым временем, заявка всё равно в учёте.

Текст пуша: откуда заявка, имя, услуга, ссылка на строку. Без ссылки менеджер снова ищет вручную.

Тест перед включением: отправьте тестовую заявку в пятницу в 22:00. Должны сработать автоответ клиенту, строка в учёте и уведомление (или отложенное правило, если так договорились). Нет хотя бы одного — не гоните трафик на бота.

### Типичные грабли

Симптом — Что проверить

«Клиент писал, мы не видели» — Нет единого канала-источника → один вход + редирект

Дубли в таблице — Ручной перенос из чатов → автозапись из канала

Ответ через сутки — Нет пуша ответственному → уведомление ≤ 2 мин

«Бот не понял» — Сразу NLP вместо правил → кнопки + поля + человек

Ответили в чате, в учёте пусто — Нет обязательного шага записи до/сразу после ответа

Разные статусы у всех — Нет списка полей → 3–5 полей на пилот

Пустые карточки в CRM — Интеграция до согласования полей → черновик карточки сначала

Чеклист на завтра

• Записать каналы и где сейчас «правда» о заявке

• Выбрать один основной вход на 1–2 недели

• Согласовать 3–5 полей и трёх статусов

• Назначить ответственного на каждый день + резервного

• Собрать цепочку: канал — поля — строка — пуш со ссылкой

• Прогнать тестовую заявку (в т.ч. вне рабочих часов)

• Записать критерий пилота до настройки: N заявок, 100% в учёте, SLA пуша, лимит ручных правок, ноль потерянных по журналу канала

• Не масштабировать на второй канал и ИИ, пока критерий не выполнен

Это не серебряная пуля и не «система на весь бизнес». Это дисциплина записи: пока её нет, любой бот только маскирует потери.

У кого какой обход сработал на пилоте — таблица, CRM или гибрид? Напишите в комменты, особенно если ломалось на исключениях (звонок вместо бота, оплата без заявки).

- кто должен ответить и что считается «заявка принята»;

- исключения: звонок вместо бота, повторный клиент, отказ после цены.

Пока правда «в трёх чатах» — не выбирайте CRM. Сначала поток, потом инструмент.

Рабочий минимум — не ИИ, а цепочка:

1. Канал — один основной вход (бот или форма с webhook).

2. Квалификация — 3–5 полей: имя, услуга/тема, срок, комментарий, контакт.

3. Учёт — строка в Google Sheets / Airtable или карточка в amo / Bitrix.

4. Человек — пуш ответственному + эскалация, если статус «новая» висит.

Приём и продажа — разные задачи. На приёме не закрываем сделку: не теряем контакт и даём контекст. Цены, спорные кейсы, жалобы — человеку.

Для ИП часто хватает: Telegram — таблица — пуш в тот же Telegram. CRM — когда поток стабилен и поля уже согласованы.

На пилоте мне хватает детерминированной логики:

- кнопки «Запись / Вопрос / Жалоба» в первом сообщении;

- обязательные имя + телефон или @username;

- таймаут: молчит 10 минут — черновик карточки и напоминание оператору;

- явный выход «позвать человека» без всей ветки;

- короткое подтверждение клиенту: «приняли, ответим в течение…».

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

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

Правило поля: зачем менеджеру это до первого контакта? Нет ответа — убираем или переносим после звонка.

Шаг 4. Таблица или CRM — по числу рук, не по моде

Таблица ок, если:

- один ответственный или владелец сам ведёт заявку;

- до ~30–50 заявок в месяц и вы их реально смотрите;

- хватает статусов: новая / в работе / закрыта (иногда «отказ»);

- не нужны напоминания по этапам сделки.

CRM имеет смысл, если:

- двое и больше менеджеров, нужен владелец карточки;

- есть этапы: квалификация — КП — оплата — постпродаж;

- нужны «перезвонить завтра», «ждём документы»;

- руководитель смотрит воронку, а не только список новых строк.

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

Шаг 5. Что не трогать в первую очередь

1. «Умный агент» до стабильного приёма — бот вежливо отвечает, учёт остаётся ручным.

2. Пять каналов сразу — четыре типа сбоев одновременно. На пилоте один вход, остальные ведут сюда автоответом или ссылкой.

3. CRM «на вырост» при 15 заявках в месяц и одном менеджере.

4. Цены и обещания в автоответе без ревью.

5. Оплату до карточки заявки («деньги уже прошли, а в учёте пусто»).

6. Эскалацию на десять ролей — все перестают реагировать. Один ответственный, один резервный.

7. Жалобы и конфликты шаблоном — бот принимает текст и создаёт срочную карточку, отвечает человек.

Шаг 6. SLA и тест в пятницу вечером

Простой SLA на пилот:

- уведомление ответственному ≤ 2 минут после записи;

- первый ответ клиенту — в согласованный срок (например, 30 минут в рабочие часы);

- если «новая» висит 2 часа — второе уведомление или смена ответственного;

- ночью — автоответ с ожидаемым временем, заявка всё равно в учёте.

Текст пуша: откуда заявка, имя, услуга, ссылка на строку. Без ссылки менеджер снова ищет вручную.

Тест перед включением: отправьте тестовую заявку в пятницу в 22:00. Должны сработать автоответ клиенту, строка в учёте и уведомление (или отложенное правило, если так договорились). Нет хотя бы одного — не гоните трафик на бота.

### Типичные грабли

Симптом — Что проверить

«Клиент писал, мы не видели» — Нет единого канала-источника → один вход + редирект

Дубли в таблице — Ручной перенос из чатов → автозапись из канала

Ответ через сутки — Нет пуша ответственному → уведомление ≤ 2 мин

«Бот не понял» — Сразу NLP вместо правил → кнопки + поля + человек

Ответили в чате, в учёте пусто — Нет обязательного шага записи до/сразу после ответа

Разные статусы у всех — Нет списка полей → 3–5 полей на пилот

Пустые карточки в CRM — Интеграция до согласования полей → черновик карточки сначала

• Записать каналы и где сейчас «правда» о заявке

• Выбрать один основной вход на 1–2 недели

• Согласовать 3–5 полей и трёх статусов

• Назначить ответственного на каждый день + резервного

• Собрать цепочку: канал — поля — строка — пуш со ссылкой

• Прогнать тестовую заявку (в т.ч. вне рабочих часов)

• Записать критерий пилота до настройки: N заявок, 100% в учёте, SLA пуша, лимит ручных правок, ноль потерянных по журналу канала

• Не масштабировать на второй канал и ИИ, пока критерий не выполнен

Это не серебряная пуля и не «система на весь бизнес». Это дисциплина записи: пока её нет, любой бот только маскирует потери.

У кого какой обход сработал на пилоте — таблица, CRM или гибрид? Напишите в комменты, особенно если ломалось на исключениях (звонок вместо бота, оплата без заявки).

Альтернатива — AGENTS.md в корне или подпапке: plain markdown без frontmatter, удобен для Codex/Copilot и nested-правил. Nested AGENTS.md применяется к файлам в каталоге и ниже.

Legacy .cursorrules в корне — deprecated. Если ещё лежит — переношу содержимое в .mdc с alwaysApply: true и убираю дубль: при совпадении текста правки только в .cursorrules часто «не срабатывают».

Уровни коротко:

Уровень — Где — В git?

Team Rules — Dashboard Cursor — Нет

Project Rules — `.cursor/rules/*.mdc` — Да

User Rules — Customize → Rules — Нет

AGENTS.md — Корень / подпапки — Да

При конфликте приоритет: Team — Project — User.

Четыре режима Project Rules (2026):

Режим в UI — Frontmatter — Поведение

Always Apply — `alwaysApply: true` — В каждый Agent-чат

Apply to Specific Files — `globs: [...]`, `alwaysApply: false` — Когда файлы по glob уже в контексте чата

Apply Intelligently — `description: "..."`, без globs — Агент решает сам — для критичных запретов не полагаюсь

Apply Manually — без description/globs/alwaysApply — Только через `@Rule-name`

Нюанс Cursor 2.x: rule с globs подхватывается, когда файл по glob уже в контексте чата (@-mention или агент читает файл), а не просто открыт в табе редактора. Это объясняет половину тикетов «правило молчит».

В монорепо отдельная packages/api/.cursor/rules/ по сообщениям с форума часто не сканируется. Практический обход — AGENTS.md внутри пакета.

Не тащите готовый GitHub-пак «на все случаи». На старте хватает одного alwaysApply на 5–15 строк из вашего package.json.

Типовая раскладка:

project/

Базовый 00-project-overview.mdc:

description: Базовые соглашения проекта

Зональное правило — отдельно, одна тема на файл:

description: React/TSX в src/

Официальный ориентир: до ~500 строк на файл, одна тема — один файл. Длинный код лучше давать через @filename в rule, а не копипастой.

Создать файл можно вручную, через Customize — Rules — Add Rule, command palette «New Cursor Rule» или /create-rule в Agent-чате.

Кейс с разбора: overview на 40 пунктов из чужого monorepo — агент «забывал» код, потому что в контексте почти не оставалось места для файлов. Сократили до 12 пунктов про свой репо — стало стабильнее. полного соблюдения rules никто не обещает.

Без проверки легко жить с молчащим frontmatter. Чеклист, который прохожу сам:

1. Customize — Rules — Project Rules — файл виден, режим совпадает с frontmatter.

2. Новый Agent-чат — не продолжение старого (там контекст уже зашумлён).

3. Спросить: «Какие project rules сейчас активны?»

4. Тестовая правка в зоне glob + @-mention файла под globs.

5. Тест запрета: попросить удалить папку или тронуть lockfile — агент должен остановиться и спросить.

6. После правки: «прогони тесты» — должны уйти команды из overview, не выдуманные.

7. Закоммитить .cursor/rules/ (и AGENTS.md, если есть), чтобы коллега в новом клоне получил те же rules.

Если glob-rule не срабатывает: расширение .mdc — закрывающий --- в YAML — путь glob — файл реально в контексте чата — нет ли конфликтующего .cursorrules.

Rules — Skills — Agent mode

Что это — Текст в `.mdc` / AGENTS.md — Навыки со SKILL.md и скриптами — Режим Agent Chat с правкой файлов

Когда — Каждый чат / по glob / @ — Когда агент вызывает skill — Когда вы в Agent и даёте задачу

Не заменяет — CI, linter, hooks — Rules (дополняет) — Rules (читает их)

Rule сам npm test не запускает — он подсказывает, что выполнить. Skills — отдельные процедуры. Agent mode — режим работы с инструментами, не «магический rule».

Механика та же: .mdc в корне с alwaysApply: true, в теле — стек (1С:Предприятие, версия платформы, где конфигурация), команды проверки (скрипт выгрузки/синтакс-проверки — явно), запреты (не трогать production-выгрузку без подтверждения).

Rules не сделают агента «1С-разработчиком из коробки». Но фиксация вроде «отвечай про процедуры в стиле BSL, не генерируй SQL вместо запросов 1С» снижает разброс так же, как в JS.

### Типичные грабли

Симптом — Что проверить

Правило «молчит» — `.md` вместо `.mdc`; битый YAML; нет закрывающего `---`

Glob не цепляется — Файл по glob в контексте чата, не только открыт в табе

Агент игнорит запрет — Apply Intelligently на критичный пункт → Always Apply или globs + тест

Агент «забывает» код — Два alwaysApply по 300+ строк — съели контекст; дроблю на темы

Противоречия в ответах — Дубль AGENTS.md и overview с разными правилами

Rules не влияют на Tab — Так и задумано — только Agent Chat

Скопированный пак с GitHub — Frontmatter чужой/битый; сократить до своего стека

Монорепо: rule в пакете не виден — Nested `.cursor/rules` ненадёжен; workaround — AGENTS.md в пакете

• Создать .cursor/rules/00-project-overview.mdc с alwaysApply: true

• Вписать свой стек и реальные npm run lint/test/build из package.json

• Добавить 2–3 запрета: .env/ключи API, lockfile, «спросить перед удалением»

• При необходимости — одно зональное правило с globs

• Убрать или смигрировать legacy .cursorrules

• Проверить в Customize — Rules: файл виден, режим верный

• Открыть новый Agent-чат и спросить активные project rules

• Прогнать тест запрета и «прогони тесты»

• Закоммитить .cursor/rules/ в git

У кого какой обход сработал на «молчащем» rule — YAML, glob в контексте или сокращение overview? Напишите в комменты, что именно починили.

На разборе ко мне почти не приходят с запросом «нужен GPT». Приходят с усталостью: администратор до ночи сидит в чате, заявки из Instagram копируют руками в таблицу, PDF летают в общий WhatsApp, а в учёте потом дубли.

Я начинаю не с модели. Сначала — один процесс, пять строк карты и критерий с числом. Ниже — рабочий каркас, которым я пользуюсь на пилотах для малого бизнеса и самозанятых. Серебряной пули нет: если цепочка не описана, любая нейросеть останется демо после оплаты.

Частый кейс — салон. Владелец говорит: «Хочу ИИ, чтобы администратор не сидел в чате до ночи». На столе при этом пять задач сразу: запись, перенос заявок из Instagram, напоминания, отчёт владельцу, «сделайте как у соседа с ботом». Подрядчик отвечает презентацией. Через месяц бот в Telegram есть — а «заявка принята» так и не описали. Администратор снова копирует сообщения в таблицу руками.

Второй сценарий — опт с WhatsApp и 1С. Взяли подписку «ИИ для продаж», менеджеры шлют PDF в общий чат, бухгалтерия ловит дубли. Сбой тот же: сообщение теряется между мессенджером и учётом.

На первой сессии я спрашиваю не про модель, а про сбой:

- сколько заявок в неделю;

- кто отвечает;

- где фиксируется «сделано»;

- что происходит в выходные.

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

Симптом — Что обычно делают — Что нужно вместо

«ИИ везде» — Берут несколько подписок — Один процесс + измеримый критерий

Нет владельца процесса — «Пусть IT разберётся» — Именованный ответственный с правом остановить пилот

Нет срока проверки — «Оценим через квартал» — Проверка на реальных данных за ~10 рабочих дней

Сценарий расползается — Новые задачи каждую неделю — Scope пилота + список «потом»

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

С чего я реально начинал пилоты:

1. Заявка из Telegram — строка в таблице или карточка в CRM — уведомление ответственному.

2. Запись клиента — подтверждение слота — напоминание за сутки; отмена без звонка менеджеру.

3. Входящий счёт или акт — извлечение полей в черновик — ревью бухгалтером перед проводкой.

Не начинайте с «автоматизировать отдел продаж». Начните с участка, где уже видно поломку: потерянное сообщение, неподтверждённый слот, забытый перезвон, кривые суммы в 1С.

Пять строк, которые я прошу заполнить до выбора инструмента:

1. Триггер — что запускает (сообщение, форма, письмо, звонок с фиксацией).

2. Вход — обязательные поля (имя, услуга, бюджет, город, файл).

3. Действие — что должно произойти без человека (запись, уведомление, черновик).

4. Исключение — когда зовём живого (нет слота, спорная сумма, VIP).

5. Готово — как проверяем (запись есть, пинг ушёл за N минут, клиент получил текст).

Если пять строк не складываются — сначала карта процесса, не заказ «ИИ-агента». Агент уместен, когда цепочка уже стабильна и нужна вариативность с ревью. До этого чаще хватает связки «мессенджер — таблица — уведомление».

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

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

Пример для заявок из Telegram (салон, 15–25 записей в неделю):

- 20 реальных сообщений за две недели (не тестовые «привет» от сотрудников);

- каждое в таблице или CRM с меткой времени и источником;

- ответственный получает уведомление за 2 минуты в рабочие часы;

- не больше 2 ручных правок карточки на 10 заявок;

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

Пример для записи на услугу:

- клиент выбирает слот в боте или форме;

- подтверждение уходит автоматически с адресом и правилами отмены;

- напоминание за 24 часа; отмена одной кнопкой без звонка;

- администратор видит «сегодня / завтра» без ручного свода.

Срок около десяти рабочих дней выбран практично: видно, держит ли процесс нагрузку и исключения (отмена, перенос, «а можно другое время»). Цель не закрыта — упрощаем сценарий или возвращаемся к карте. Масштабировать рано.

Этап — Срок — Результат

Разбор — 1 сессия 60–90 мин — Карта процесса + черновик критерия

Пилот — ≈10 раб. дней — Рабочий контур на реальных данных

Решение — после пилота — Масштаб, доработка или остановка без «дожимания»

Критерий пишу в прошедшем времени и с числом: «За 10 рабочих дней 18 из 20 заявок попали в CRM без ручного копирования». «Улучшим сервис» и «ускорим работу» — не критерий. Scope подписываем вместе с владельцем: что входит, что явно «после».

Перед оплатой «внедрения под ключ» я смотрю не на технологию, а на управляемость:

- письменное описание процесса: вход, выход, исключения, кто решает спорные кейсы;

- критерий пилота с цифрами и сроком;

- список систем и доступов для первого контура;

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

- поддержка после запуска: кто чинит, в какие сроки, что считается инцидентом.

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

На созвоне спрашиваю: кто владелец процесса после запуска? Сколько часов в неделю он готов тратить на первые две недели? Какие системы затронет первый контур? Что уже пробовали и почему бросили?

Часто на разборе выясняется: агент не нужен, нужна связка Telegram — Google Таблица — уведомление в тот же мессенджер. Бывает и наоборот: таблица на 200 заявок в месяц с тремя ролями уже не тянет — нужен backend и нормальные права.

Уровень — Когда хватит — Ограничения

Таблица + уведомления — До 30–50 заявок/мес, один ответственный — Дубликаты, ручной контроль качества

Конструктор бота (Telegram) — Один сценарий: заявка или запись — Сложная логика и несколько CRM — на пределе

n8n / Make + API — Несколько систем, расписания, вебхуки — Нужны API, мониторинг, человек на сбои

Код (бот + backend) — Нестандартная логика, роли, аудит — Выше старт, ниже хаос на объёме

Cursor и режим Agent у меня — инструмент разработки и ускорения правок, не замена описанного процесса.

Порядок, которого придерживаюсь:

1. Неделя ручного или полуручного контура — увидеть реальный поток.

2. Автоматизирую самый скучный шаг (уведомление, запись в таблицу).

3. Потом — исключения.

Так проще понять, где сбой: данные, интеграция или ожидания.

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

- Владелец отвечает на вопросы команды и принимает спорные случаи.

- В первый этап входит только согласованный сценарий; новые идеи — в отдельный список «потом».

- Каждую неделю смотрим живой поток и правим следующий цикл.

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

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

### Типичные грабли

Симптом — Что проверить

Бот есть, заявки всё равно копируют руками — Есть ли определение «заявка принята» и куда пишется факт

Взяли «ИИ для продаж», дубли в учёте — Где рвётся цепочка мессенджер → учёт, кто владелец

«Нам не понравилось качество ответов» — Был ли критерий с числом до старта

Три пилота сразу на двоих — Scope: один процесс, остальное в backlog

Таблица «не тянет» — Объём >30–50/мес, роли >1 → n8n/код, не ещё одна подписка

Агент «на всё» — Стабильна ли цепочка; нужна ли вариативность с ревью

Нужен ли сразу ИИ-агент? Не всегда. Если проблема — потерянные заявки в чате, часто хватит Telegram — таблица/CRM — уведомление. Агент добавляют, когда сценарий стабилен.

Можно ли без программиста? Для простых сценариев — да: конструктор бота, таблица, n8n с готовыми узлами. Несколько систем, роли и исключения — нужен настройщик с мониторингом.

Как понять, что сработало? Заявки не теряются, уведомления приходят, исключения идут по правилам. Не «модель ответила красиво».

Чеклист на завтра

• Выбрать один процесс, который уже болит (заявки / запись / учёт)

• Записать цепочку от события до результата и отметить, где ломается сейчас

• Заполнить пять строк: триггер — вход — действие — исключение — готово

• Назвать владельца процесса с правом остановить пилот

• Сформулировать критерий в прошедшем времени с числом и сроком ~10 раб. дней

• Список систем и доступов для первого контура

• План отката одной кнопкой + кто чинит после запуска

• Инструмент выбрать только после карты (часто хватит таблицы и уведомлений)

• Scope: что входит в пилот, что явно «потом»

• Через неделю ручного/полуручного контура — автоматизировать самый скучный шаг

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