Один владелец — несколько компаний: как управлять ими через Telegram без смешивания данных

Один Telegram-аккаунт — не одна общая компания

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

Например, владелец управляет кофейней, мастерской и магазином. Их CRM, понятия «заказ» и «доход» и циклы обновления отличаются. Вопрос «сколько у нас просроченных обращений?» без указания компании оставляет риск смешать несопоставимые цифры либо раскрыть сведения сотруднику, который не имеет на них прав.

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

Как соотносятся компания, Telegram-бот и Mini App

В выбранной архитектуре AGENTUM каждой компании соответствует отдельный рабочий Telegram-бот и свой контекст Mini App. Один владелец может работать с несколькими организациями, но общий личный аккаунт не становится универсальным ключом к их данным. Разделение контекстов — не косметический элемент меню: оно должно сохраняться при обращениях к источникам на серверной стороне.

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

Многокомпанейная модель в AGENTUM реализована и развёрнута, но не все реальные Telegram E2E-сценарии создания последующих ботов, назначения сотрудников и активации проверены на живых пользовательских маршрутах. Это важно прямо указывать при внедрении, а не выдавать архитектурный контракт за гарантированное прохождение каждого шага.

Разрешения: кто вправе читать, предлагать и подтверждать

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

Внесите роли и права в простую матрицу; повторите эти проверки на сервере при каждом обращении к источнику. Отдельно определите, кто может сформировать предложение на изменение записи и кто подтверждает конкретную операцию. Аналитика, предложение и исполнение — разные состояния.

Следующая матрица — рекомендуемый пример для обсуждения с компанией, а не обещание, что каждый её пункт уже доступен в любом тарифе и подключении AGENTUM.

Сквозной кейс: два бизнеса одного владельца

Представим вымышленного владельца кофейни «Север» и ремонтной мастерской «Линия». Все цифры ниже придуманы для тренировки и не являются результатами внедрения AGENTUM. В тестовой таблице «Севера» за неделю — 12 обращений, три без ответственного; у «Линии» — восемь обращений и одно без следующего шага.

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

После перехода в отдельный контекст «Линии» тот же вопрос даёт данные только мастерской. Если сотрудник «Севера» или даже владелец в контексте бота А запрашивает приватную запись Б, система не должна раскрывать её. Отрицательный тест на отсутствие доступа здесь важнее красивой демонстрации найденного числа.

Для сравнения всей группы сперва согласуйте определения. В кофейне «заявка» может означать обращение с сайта, а в мастерской — зарегистрированный заказ на ремонт. Нельзя автоматически складывать разные показатели и объявлять наличие общего кросс-компанейного дашборда без проверки конкретной функции и прав.

Какие вопросы задавать AI, чтобы ответ проверялся

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

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

Формула «компания → период → показатель → источник → действие» помогает даже без AI. Её можно использовать в управленческом регламенте и обучении сотрудников. Слова «предложи три решения» полезнее неопределённого «сделай всё», потому что сохраняют за руководителем право проверить предпосылки и приоритеты.

Активация: просмотр интерфейса ещё не открывает данные

AGENTUM допускает ознакомление с рабочим интерфейсом до полноценной активации конкретной компании. Но видимая кнопка «Подключить источник» не означает, что пользователю уже разрешено записать токен и прочитать рабочие документы. Подключение должно учитывать состояние активации, роль и полномочие на конкретный источник.

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

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

Почему два правильных числа могут дать неправильное решение

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

Если CRM показывает 17 сделок на утро, а таблица — 15 на вчерашний вечер, не просите AI вывести среднее. Следует показать расхождение с датами и выяснить метод учёта. Разные источники могут быть по-своему точными, но относиться к разным периодам либо этапам процесса.

Отдельно отображайте техническое состояние: у компании А источник доступен, у Б связь истекла, у В источник ещё не активирован. Частичный успех отчёта нельзя превращать в сообщение, что «вся группа работает нормально». Это особенно важно, если руководитель принимает решение на ходу через Telegram.

Рекомендация, задача и фактическая запись — три разные вещи

«Назначьте ответственного» — совет. «Создан черновик задачи» — подготовленное предложение. «Задача записана, система подтвердила идентификатор и журнал» — результат исполнения. Эти статусы различаются как в обычном ПО, так и при работе с AI. Отсутствие такого различия создаёт иллюзию выполненного поручения.

Перед записью значимых данных покажите компанию, объект, старое и новое значение, автора запроса и последствия действия. Требуйте подтверждение именно этой операции. При доступе только на чтение AI не должен обещать изменить CRM или удалить строку. Если сеть оборвалась после записи, сначала выясните состояние системы, а не повторяйте запрос вслепую.

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

Отрицательный тест: как доказать отсутствие утечки между компаниями

Создайте две тестовые организации с обезличенными источниками. В первой — уникальную запись «ALFA-017», во второй — «BETA-023». Из рабочего бота первой компании запросите «ALFA-017», затем попробуйте получить «BETA-023». Для второго запроса ожидается отказ или отсутствие доступа — не поиск через другой контекст.

Повторите проверку из бота Б и под учётной записью сотрудника, имеющего роль только в А. Проверьте попытку перейти по чужой ссылке, узнать идентификатор записи и продолжить старый диалог после отзыва членства. Контекст должен проверяться при каждом новом запросе, а не только один раз при открытии Mini App.

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

12 проверок перед работой с несколькими компаниями

Заведите таблицу приёмки. Для каждого пункта укажите проверяющего, компанию, свидетельство, дату и статус PASS, REVISE или NOT CHECKED. Любой критический провал в изоляции или правах — причина остановить работу с реальными данными до исправления.

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

1. Компания имеет отдельного рабочего бота и контекст Mini App.
2. На сервере проверяются компания и членство пользователя.
3. Роль сотрудника не расширяет доступ к другим организациям.
4. Владелец видит актуальные разрешения и может их пересмотреть.
5. Неактивированная организация не подключает рабочие источники.
6. Чужая тестовая запись не появляется в ответе другого бота.
7. Доступ отозванного участника перестаёт действовать.
8. Ответ содержит источник, период и время актуальности.
9. Несовпадающие KPI не складываются без общей методики.
10. Режим чтения не выдаётся за возможность записи.
11. Операция подтверждается фактическим результатом целевой системы.
12. Результат каждой проверки документирован без чувствительных данных.

Пять частых вопросов о многокомпанейном управлении

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

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

Достаточно ли знать ссылку на чужой Mini App? Нет. Сервер должен повторно проверить пользователя и его право на указанную организацию. Проверяется это не внешним видом экрана, а попыткой запроса к запрещённой записи.

Можно ли начать без CRM? Да, с ознакомления, правил ролей и синтетической таблицы. Это не означает автоматический доступ к реальным данным: подключение требует активации и разрешений.

Может ли AI самостоятельно изменить чужие данные? Не должен. Действия ограничиваются ролью, разрешениями источника и требуемым подтверждением; невыполненное предложение нельзя объявлять успешной записью.

Итог: один владелец, прозрачные границы ответственности

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

Начните с одной компании и одного измеримого вопроса. Получите воспроизводимый ответ, проверьте источник и время, затем проведите отрицательные тесты доступа из другой компании. Только после этого расширяйте сценарий на новые организации и реальные данные.

AGENTUM предлагает модель управления через Telegram-ботов и Mini App с анализом разрешённых данных. Правильное обещание владельцу — контроль и понятный процесс принятия решений, а не волшебное объединение любых CRM и не гарантия автоматического исполнения всех поручений.