Мульти-арендатор для сервисных сетей: одна установка, N брендов

Большинство CRM продают «мульти-компанию» как апгрейд. Платите больше - в углу появляется выпадающий список. А под капотом всё та же одна большая таблица с колонкой companyId, которую никто не обеспечивает на уровне сервиса. Это работает, пока не происходят две вещи одновременно: партнёр просит свой бренд, а аудит просит доказать изоляцию.

Что реально значит «мульти-арендатор»

Слоёв три, и настоящий мульти-арендаторный CRM обеспечивает все три.

1. Слой данных

В каждой строке стоит companyId. Каждый запрос фильтруется по нему. Каждое отношение его уважает. Это базовый минимум - но важна точка контроля: обеспечение должно быть на уровне сервиса, а не интерфейса. Скрытие через CSS - это не изоляция.

На практике это значит:

• Внешние ключи каскадятся в пределах одного арендатора
• Индексы всегда начинаются с (companyId, ...)
• Обработчики API определяют companyId из сессии и никогда не доверяют URL

2. Почтовый слой

Забытый. Если два арендатора делят почтовый сервер - они делят репутацию отправителя. Жалоба на спам у арендатора A бьёт по доставляемости арендатора B. Поэтому настоящий мульти-арендатор даёт каждому:

• Свой домен (например, @brand-a.com)
• Свой ключ DKIM
• Свою настройку SPF и DMARC
• При желании - свой график прогрева

3. ИИ-слой

Самый молодой и часто упускаемый. Если два арендатора делят контекстное окно языковой модели - они делят риск утечки. Настоящая мульти-арендаторная интеграция ИИ:

• Маршрутизирует запросы по companyId без общего состояния
• Использует ключи API, принадлежащие самому арендатору (тарификация на его стороне)
• Помечает каждую генерацию арендатором для аудита
• Не строит общий индекс эмбеддингов между арендаторами без явного согласия

Где это важно

Три конкретных кейса:

Холдинги агентств

Родительское агентство с тремя суб-брендами должно получить:

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

Большинство CRM заставляют выбирать: либо отдельные аккаунты (и нет сводной отчётности), либо общий аккаунт (и нет изоляции брендов). Настоящий мульти-арендатор даёт оба варианта одновременно.

Мульти-практик консалтинг

Консалтинг с инженерной, экологической и юридической практиками не хочет смешивать заявки. Инженерная практика квалифицирует по техническому соответствию; юридическая - по регуляторному риску. Одна фирма, разные фильтры.

Аккаунт на каждую практику с общей командой решает задачу.

Сети франчайзи

Франшиза, где каждая локация ведёт свою воронку, но отчитывается наверх корпорации. Локация владеет своими заявками (суверенитет данных). Корпорация видит сводные метрики (управляемость). Бренды разные, методики общие.

Что стоит сделать неправильно

Доработка мульти-арендаторности - вторая по сложности миграция в софте, после смены типа базы данных. Каждая общая таблица превращается в грабли. Каждый общий почтовый домен - в риск доставляемости. Каждый общий ИИ-контекст - в риск приватности.

Решение: стартовать мульти-арендаторным с первого дня, даже если арендатор у вас один.