Составлено 11.10.2026. Опирается на разбор 11-svyazka-uchastok-chat-fajl.md и обзор рынка 20-rynok-sistem.md. Выбор коробки предложен, но не утверждён — пока это предложение.
Разбор связки дал один вывод, и он определяет всю архитектуру:
> Решение существует как реплика в чате. Таблица узнаёт о нём, только если человек вспомнит перенести. Девять участков из девяти устроены так.
Отсюда два следствия, которые обычно путают:
1. Одной коробкой это не чинится. Завести место, где след остаётся, недостаточно — переносить в него по-прежнему будет некому. Так уже было: таблицы есть, их 56, и половина болей именно про то, что в них не попадает.
2. Одними агентами тоже не чинится. Агенту нужно место, куда положить след, и правила, по которым он его кладёт. Без коробки агент превращается в ещё один чат.
Поэтому эффект даёт связка: коробка держит состояние, агент ставит след сам, читая тот же чат, где решение прозвучало.
Коробка с минимальными настройками. Предлагается Битрикс24 (облако, Стандартный): свои сущности заводятся настройкой через смарт-процессы, есть официальный MCP-сервер.
Что заводим на старте — восемь сущностей, не больше:
| Сущность | Зачем | Закрывает узел |
|---|---|---|
| Контрагент | подрядчики, площадки, артисты — одним списком вместо трёх таблиц с годами в названии | 7 |
| Единица работ | выезд, макет, мастер-файл: что сделано, когда, кем, по какой ставке | 8 |
| Счёт на оплату | единый реестр с вложенным файлом и состоянием «пришёл → подтверждён → оплачен» | 6 |
| Договор | состояние документа одним полем вместо шести листов | — |
| Акт | форма и состояние подписания, видимое команде | 6 |
| Событие (концерт/проект) | одна карточка вместо шести чатов | 5 |
| Песня / релиз | путь от аранжировки до площадки, включая авторство | 9 |
| На утверждение | очередь того, что ждёт решения Антона | 1–4 |
Что не заводим в MVP: бухгалтерию, складской учёт мерча, кадры, CRM продаж. Это Delivery.
Не самостоятельная система, а правила, по которым агент разговаривает с коробкой:
Агенты живут в тех же чатах, где идёт работа. Они не решают — они готовят решение и фиксируют принятое. Пять ролей на MVP:
| Агент | Что делает | Где работает |
|---|---|---|
| Приёмщик | видит в чате счёт, чек, заявку, файл — заводит запись в коробке и отвечает, что завёл | «Заявки/оплаты», «ЧЕКИ», «Документы ИП», финансовый чат |
| Учётчик работ | подрядчик написал «сделал» — отмечает единицу работ в день сдачи, а не через три месяца | чаты подрядчиков |
| Счетовод периода | расчётный период наступил — приносит готовую сумму по каждому подрядчику: что сделано, по какой ставке, к оплате | финансовый чат |
| Секретарь утверждений | ведёт очередь того, что ждёт «ок» Антона, по всем четырём чатам сразу | «Утверждение материала», «LAB GIG», SMM, Eventvision |
| Сверщик | ищет несостыковки: счёт без договора, работа без ставки, релиз без очистки прав | поверх коробки, отчёт в пульт |
Шестой появляется сам собой и уже работает — разборщик материалов: берёт из чата запись, голосовое, документ и превращает в структурированный текст. Он у нас есть.
Агент не принимает решений. Антон по-прежнему утверждает материал, Татьяна по-прежнему подтверждает оплату, Алина по-прежнему согласует условия. Меняется одно: решение, которое они приняли, перестаёт существовать только в виде реплики.
Это стоит сказать команде прямо на первой встрече: ни одна из девяти точек принятия решения не уходит к машине. Уходит ручной перенос.
| Большое внедрение | Наш путь | |
|---|---|---|
| Что ставим | полный контур учёта | восемь сущностей и пять агентов |
| Кто переносит данные в систему | люди, по регламенту | агент, из того же чата |
| Когда виден эффект | после перехода всей команды | на первом же счёте и первой единице работ |
| Что делать, если не пошло | переучивать команду | поправить правило агента |
| Риск | команда не перешла, система стоит пустая | ограничен одним участком |
Команда уже один раз не перешла в систему — это известно из обследования. Второй раз просить их изменить привычки не нужно: они продолжают писать в те же чаты.
1. Расширение периметра сущностей — мерч, роялти, кадры, субаренда.
2. Новые агенты на тех же дата-сервисах — каждый следующий дешевле предыдущего, потому что слой доступа уже есть.
3. Переезд в коробочную версию на свой сервер, если вырастут требования к данным.
4. Аналитика поверх учёта — когда в системе накопится год, появится чем мерить.
| Что | Как проверяем | Чем грозит провал |
|---|---|---|
| MCP коробки на нашем сценарии | читаем и пишем смарт-процесс от имени сотрудника | агентский слой дороже на интеграцию |
| Лимиты REST | агент ходит часто; упираемся или нет | нужен кеш в дата-сервисах |
| Импорт из Google Таблиц | на реальных файлах канвы | перенос данных руками |
| Чтение чатов | бот в чатах клиента уже работает | — проверено, работает |
Первые три — две недели работы архитектора и разработчика. Это и есть первый этап MVP: пока они не проверены, срок и цена остального — оценка, а не обязательство.
1. Коробка. Битрикс24 или Планфикс — решение CTO. От него зависят сроки и цена.
2. Где живут файлы. Остаёмся на Яндекс.Диске и ссылаемся из коробки, или переносим в её хранилище. Влияет на Г-25 («файл из чата попадает в архив без скачивания»).
3. Max. Бухгалтер и Валентин не в Telegram. Агент в Max — отдельная работа; в MVP их участок закрываем через людей или выносим в Delivery.