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

Один Telegram-акаунт не означає одну спільну компанію

Підприємець може користуватися одним особистим Telegram і водночас керувати кількома незалежними бізнесами. Однак особистий акаунт не перетворює продажі, завдання працівників та документи цих організацій на спільну базу. У кожного управлінського запиту має бути конкретна компанія, дозволені користувачі, визначене джерело та період спостереження. Зручний чат не замінює політики доступу.

Уявімо власника кав'ярні, майстерні та інтернет-магазину. У них різні CRM, визначення «замовлення» і «доходу», цикли оновлення. Запитання «Скільки в нас прострочених звернень?» без назви компанії ризикує змішати непорівнювані числа. Ще гірше, коли переконлива відповідь випадково відкриває відомості співробітнику, який не має права їх бачити.

Перед важливим запитом з'ясуйте чотири речі: компанію, особу та її роль, дозволене джерело, часовий проміжок. Якщо чогось бракує, помічник повинен попросити уточнення або чесно повідомити, що перевірених даних недостатньо. Припущення про контекст можуть бути швидкими, але вони небезпечні для реальних рішень.

Як пов'язані компанія, її Telegram-бот і Mini App

В обраній архітектурі AGENTUM кожній компанії відповідає окремий робочий Telegram-бот та власний контекст Mini App. Один власник може брати участь у кількох організаціях, однак його особистий акаунт не стає універсальним ключем до всіх даних. Поділ контекстів має діяти на сервері під час кожного звернення до джерела, а не лише в меню.

Тут є три різні рівні. Telegram визначає особу, що відкрила інтерфейс. Платформа перевіряє членство в організації, стан активації та роль. Нарешті, конкретне дозволене джерело надає лише ті поля, які користувач може запитувати. Знання посилання на чужого бота або наявність видимої кнопки не надає повноважень.

Багатокомпанійну модель AGENTUM реалізовано та розгорнуто на рівні архітектури. Водночас окремі живі Telegram E2E-сценарії — особливо створення наступного бота та призначення ролей — ще потребують підтвердження. Технічну модель не слід видавати за доказ, що кожен шлях реального клієнта вже пройдено.

Права доступу: хто може читати, пропонувати й затверджувати

До підключення робочої CRM власнику потрібен перелік учасників та дій, які дозволено кожній ролі. Працівнику, який переглядає власне завдання, не потрібен доступ до всіх фінансових документів групи. Керівнику для аналізу продажів зазвичай досить погоджених полів і періоду. Платформний адміністратор, який допомагає з активацією, не повинен автоматично отримувати право читати комерційні записи клієнта.

Застосовуйте принцип мінімальних прав і перевіряйте їх для кожного запиту до джерела. Окремо визначте, хто готує пропозицію змінити дані, а хто затверджує конкретну операцію. Аналітична рекомендація, дія на погодженні та фактично виконаний запис — різні стани. Матриця нижче є прикладом планування, а не гарантією доступності кожної функції в будь-якій конфігурації.

Зафіксуйте відповідального за джерело, особу, що погоджує, та журнал змін. Коли співробітник переходить в іншу команду або залишає компанію, відкличте доступ і проведіть повторний негативний тест. Неактивна кнопка в інтерфейсі ще не доводить, що сервер відмовить у забороненій дії.

Практичний приклад: два бізнеси одного власника

Уявімо вигаданого власника кав'ярні «Північ» і ремонтної майстерні «Лінія». Усі назви та цифри тут — штучні тестові дані, а не результати клієнтів AGENTUM. За тиждень у таблиці кав'ярні 12 звернень, три з них без відповідального. У майстерні вісім звернень, одне без наступного кроку.

У боті кав'ярні керівник запитує: «Покажи звернення без відповідального за останні сім завершених днів і назви джерело». Правильна відповідь містить лише три записи кав'ярні, період, назву дозволеної таблиці та час її оновлення. Вона не додає звернення майстерні тільки тому, що власник у двох підприємств один.

Далі власник свідомо переходить до контексту «Лінії» й ставить те саме запитання. Тепер відповідь повинна ґрунтуватися лише на дозволених даних майстерні. Якщо працівник кав'ярні або будь-хто в її контексті просить приватний запис іншого бізнесу, негативний тест має показати відмову. Доказ неможливості витоку не менш важливий за демонстрацію правильної кількості.

Якщо потрібна загальна звітність групи бізнесів, спершу погодьте значення показників. У кав'ярні «звернення» може бути формою з сайту, у майстерні — вже прийнятим замовленням. Не можна складати різні події або обіцяти загальну аналітичну панель без підтвердження відповідної функції, джерел і прав конкретного власника.

Як ставити AI запитання, щоб відповідь можна було перевірити

Порівняйте «Що в нас із клієнтами?» і «Північ / останні сім завершених днів / звернення без відповідального / дозволена таблиця / перелічити записи й час оновлення, нічого не змінювати». У другому варіанті визначено бізнес, показник, рамки та потрібний результат. Такий запит можна відтворити й перевірити.

Просіть, щоб звіт містив: що знайдено, з якого дозволеного джерела, за який період, коли дані оновлювалися та яке рішення можливе. Важливі числа мають перевірятися за вихідними записами чи документованим правилом розрахунку. Якщо інтеграцію від'єднано, помічник не повинен вигадувати звіт. Пропозиція створити завдання ще не означає його виконання.

Короткий шаблон — компанія → період → показник → дозволене джерело → потрібна дія. Наприклад: «Лінія / учора / нові звернення / CRM / покажи винятки, лише читання» або «Північ / минулий тиждень / прострочені завдання / внутрішній реєстр / запропонуй пріоритети». Це дисциплінує управлінські запити навіть без AI.

Активація: побачити інтеграцію — не означає отримати доступ

AGENTUM може дозволяти ознайомлення з робочим простором до активації компанії. Але кнопка «Підключити джерело» не означає, що вже дозволено записувати токени та читати реальні документи. Процедура підключення має враховувати стан активації, роль користувача й право на конкретне джерело.

Почніть з одного чітко визначеного бізнес-запитання і синтетичної таблиці або спеціальної тестової папки. Визначте відповідального за дані та надайте мінімальні права. Перевірте як успішне читання, так і відмову в несанкціонованому доступі, перш ніж працювати з клієнтськими записами. Не розширюйте права просто для зручної демонстрації.

Не пересилайте в Telegram паролі, ключі інтеграцій, приватні токени й повні вивантаження клієнтів. Використовуйте передбачений механізм авторизації. Якщо організацію ще не активовано або власник джерела не погодив доступ, отримайте дозвіл замість повторних спроб обійти обмеження.

Чому два правильні числа можуть привести до помилкового рішення

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

Якщо CRM о дев'ятій ранку показує 17 угод, а таблиця за попередній вечір — 15, не просіть AI знайти «розумне середнє». Покажіть обидва значення з датами та визначеннями й доручіть відповідальній особі з'ясувати відмінність. Часто причина в різній актуальності, а не в тому, що одне джерело неправдиве.

Технічний стан інтеграцій також потрібно розділяти: в організації А джерело працює, у Б дозвіл минув, у В підключення ще не активоване. Частково успішна відповідь не повинна створювати враження, що звітність усіх компаній готова до використання.

Рекомендація, чернетка завдання та підтверджений запис — різні стани

«Призначте відповідального» — порада. «Підготовлено чернетку призначення» — пропозиція дії. «Завдання записано, цільова система підтвердила результат» — виконана операція. Користувач має бачити різницю між ними, а система — фіксувати стани окремо. Інакше власник може покладатися на доручення, яке ніхто не виконав.

Перед важливими змінами показуйте компанію, цільовий запис, попереднє й нове значення, автора запиту та можливі наслідки. За потреби вимагайте явного підтвердження саме цієї операції. Інтеграція лише для читання не може видаватися за засіб редагування. Якщо з'єднання обірвалося після спроби запису, спершу перевірте цільову систему, а не дублюйте зміну наосліп.

Внутрішній облік завдань і зовнішні CRM мають різні джерела істини. AGENTUM має спиратися на фактично підтримувані дії та дозволи обраної системи. Загальна обіцянка, що AI «керує всім бізнесом», не доводить виконання конкретної операції.

Негативні тести: як довести, що дані не витікають між компаніями

Створіть дві тестові організації без персональних записів. У першій розмістіть унікальний ідентифікатор «ALFA-017», у другій — «BETA-023». Із бота компанії А спочатку запросіть власний запис, потім спробуйте отримати «BETA-023». Другий запит повинен бути відхилений або не повернути дозволеного запису, а не виконати прихований пошук у чужих джерелах.

Повторіть тест з іншого бота та під обліковим записом працівника, який має членство лише в А. Перевірте пряме посилання на бота Б, відомий ідентифікатор і нове запитання в старому діалозі після відкликання ролі. Сервер має перевіряти поточну організацію та права при кожному відповідному запиті.

Потім від'єднайте дозволене джерело й повторіть раніше успішний запит. Помічник не повинен стверджувати, що отримав свіжі рядки. Збережіть знеособлений протокол: роль, компанія, джерело, очікувана та фактична відповіді, висновок перевіряльника. Доки такі тести не пройдено, не варто обіцяти повністю перевірену ізоляцію в будь-якій конфігурації.

Дванадцять перевірок перед управлінням кількома компаніями

Створіть аркуш приймання, де для кожного критерію зазначено відповідального, компанію, доказ, дату й один зі статусів PASS, REVISE чи NOT CHECKED. Критична помилка ізоляції, членства або прав запису — підстава не відкривати доступ до реальних даних до виправлення.

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

1. Кожна компанія має власний робочий бот і контекст Mini App.
2. Сервер перевіряє членство в компанії при відповідних запитах.
3. Роль працівника не відкриває доступ до іншої організації.
4. Власник може переглядати й змінювати надані права.
5. Неактивна компанія не підключає реальні джерела без дозволу.
6. Тестовий запис іншої компанії ніколи не з'являється у відповіді.
7. Відкликання членства припиняє подальший доступ.
8. Відповідь містить джерело, період і час актуальності.
9. Несумісні показники не додаються без спільного визначення.
10. Режим читання не видається за можливість змінювати записи.
11. Цільова система підтверджує кожну нібито виконану операцію.
12. Результат кожної перевірки документують без персональних даних.

П'ять частих запитань про керування кількома компаніями

Чи потрібен один бот для всіх компаній? Ні. Архітектура AGENTUM передбачає окремого бота й Mini App-контекст для кожної організації. Власник може брати участь у кількох. Перш ніж обіцяти другий бот клієнту, перевірте конкретний актуальний маршрут підключення.

Чи можлива спільна аналітика? Сформулювати запитання можна, але коректний звіт потребує явних прав до кожного джерела й узгоджених визначень KPI. Не припускайте, що універсальна панель доступна всім акаунтам.

Чи достатньо посилання на Mini App чужої компанії? Ні. Сервер має повторно перевірити користувача та право на цільову організацію. Доведіть це негативним тестом із забороненим записом, а не виглядом кнопки.

Чи можна почати без CRM? Так. Спочатку можна ознайомитися з простором, визначити ролі та перевірити синтетичну таблицю. Це не означає автоматичного права підключати робочі дані.

Чи може AI автоматично змінити дані іншої компанії? Не повинен без достатньої ролі, дозволеної функції джерела та необхідного підтвердження. Пропозиція дії не є доказом успішного запису.

Висновок: один власник, чіткі межі відповідальності

Корисна багатокомпанійна система — це не універсальний чат із необмеженими даними. Це зрозумілі межі організацій: свої джерела, визначення KPI, ролі, робочі контексти й незалежна перевірка дій. Один особистий Telegram-акаунт лише полегшує перехід між робочими просторами.

Почніть з однієї організації та одного вимірюваного запитання. Отримайте відтворювану відповідь, перевірте джерело й час оновлення, потім проведіть негативні тести з іншого контексту. Лише після цього розширюйте підхід на інші компанії та реальні дані.

AGENTUM розвиває модель керування бізнесом через Telegram-ботів і Mini App з аналізом дозволених джерел. Переконлива обіцянка власнику — відповідальні рішення на основі перевіреної інформації, а не чарівне об'єднання всіх CRM чи гарантія виконання кожного доручення.