Первые клиенты корпоративного сервиса часто похожи: одинаковые формы, близкие процессы, несколько сотрудников. Кажется, достаточно добавить к каждой записи название компании. Но затем бухгалтер работает сразу с двумя организациями, руководитель приглашает внешнего специалиста, а крупный клиент просит особый маршрут.
Многоклиентский SaaS — общий программный сервис для нескольких независимых организаций. Его задача не только обслужить всех на одной платформе, но и сохранить правильные границы данных, полномочий и настроек. Эти границы нужно обсуждать до разработки, потому что они влияют почти на каждую рабочую операцию.
Разделите человека, организацию и роль
Учётная запись отвечает на вопрос, кто вошёл в сервис. Организация определяет, чьи рабочие данные доступны. Роль описывает, что человек вправе делать внутри этой организации.
Один пользователь может входить в несколько компаний с разными полномочиями. Например, консультант в одной организации только читает отчёты, а в другой помогает вести справочник. Общий признак «администратор» без контекста компании здесь опасен.
Отдельно определите владельца организации. Кто создаёт рабочее пространство, приглашает сотрудников и передаёт свои полномочия? Что происходит при увольнении владельца или потере доступа? Эти вопросы относятся к продолжению работы клиента, а не к редким техническим исключениям.
Условный пример: сервис для проектных бюро
Представим вымышленный SaaS для подготовки заданий и согласования результатов. В нём работают бюро «Север» и «Вектор». Это пример для объяснения, не описание клиента ExtentLab.
В «Севере» сотрудник Анна руководит проектами. Во «Векторе» она привлечённый эксперт с доступом к одному заданию. Один адрес электронной почты не должен объединять рабочие пространства или переносить полномочия между ними.
Анна переключается в «Вектор» и видит только разрешённый проект. Прямая ссылка на задание «Севера» должна проверяться по её членству и правам, а не открываться потому, что она уже вошла в сервис.
Если Анну исключили из «Вектора», её доступ к «Северу» остаётся прежним. История выполненных действий сохраняет понятного автора, но удалённое членство больше не даёт права просматривать новые материалы.
Изоляция должна охватывать больше одного экрана
Изоляция означает, что одна организация не получает данные другой без предусмотренного основания. Проверять нужно не только основные списки, но и поиск, файлы, уведомления, отчёты, выгрузки и фоновые операции.
Особенно легко забыть вспомогательные части. Например, название чужого проекта появляется в поисковой подсказке, ссылка на файл работает после исключения сотрудника или общий отчёт объединяет показатели разных клиентов.
Способ хранения — общая база, отдельные разделы или отдельные базы — выбирается инженерами с учётом требований. Название архитектуры само по себе не доказывает правильную изоляцию. Для заказчика важны проверяемые сценарии и ограничения эксплуатации.
Отдельного решения требует доступ поддержки. Если сотрудник сервиса помогает клиенту, его полномочия, основание действий и история обращения должны быть определены. Не следует давать неограниченный доступ всем сотрудникам команды только ради удобства диагностики.
Согласуйте приглашения и внешних участников
Приглашение должно относиться к конкретной компании и роли. Укажите, кто вправе его отправить, как долго оно действует и что происходит при ошибке в адресе.
Внешний эксперт отличается от штатного сотрудника не названием карточки, а объёмом доступа. Он может видеть один проект, не иметь права приглашать других людей и терять доступ после завершения работы. Если такого ограничения нет в первой версии, нельзя обещать его клиентам устно.
Проверьте повторное приглашение, уже существующую учётную запись, смену роли и отзыв доступа во время активной работы. Для каждого случая нужен понятный результат без случайной потери рабочих данных.
Также договоритесь, кому принадлежат созданные документы. Удаление сотрудника не должно автоматически означать удаление всех результатов его работы.
Настройка или отдельная версия продукта
Первые корпоративные покупатели могут попросить разные названия статусов, обязательные поля и маршруты. Не каждое отличие стоит превращать в универсальный конструктор.
Разделите требования:
- общее поведение, полезное большинству клиентов;
- небольшая настройка с ограниченными допустимыми значениями;
- дополнительная возможность с понятным составом;
- индивидуальное изменение, несовместимое с общей моделью.
В вымышленном примере два бюро называют одинаковое состояние по-разному. Отображаемое название можно обсуждать как настройку. Но если одно бюро требует совсем другой порядок ответственности и расчёта результата, простого переименования недостаточно.
Любая настраиваемость увеличивает число сочетаний, которые нужно проверять. Сначала выясните, какое различие действительно связано с работой клиента, а какое повторяет привычку старой программы.
Что включить в первую версию
Для ограниченного запуска обычно важнее надёжная базовая модель, чем десятки ролей. Опишите несколько основных полномочий и реальные передачи ответственности.
Первая версия может включать создание организации, приглашение сотрудника, назначение согласованной роли, переключение рабочего пространства и отзыв доступа. Но состав определяется вашим процессом: если клиенты не должны пересекаться по пользователям, это тоже явное условие.
Заранее определите прекращение обслуживания компании. Требуются правила доступа к её результатам, выгрузки, хранения и завершения фоновых задач. Не обещайте мгновенное удаление всей информации, пока не определён состав данных и применимые ограничения.
Проверьте, что нагрузка одной организации не лишает остальных возможности работать в согласованных пределах. Это касается не только скорости, но и больших выгрузок, загрузок файлов и длительных расчётов.
Когда достаточно готовой платформы
Готовое решение подходит, если его модель организаций, ролей и настроек соответствует вашему продукту. Проверьте её на двух компаниях и одном общем консультанте, а не на единственном демонстрационном администраторе.
Уточните, можно ли получить данные клиента в пригодном формате, как ограничен доступ поддержки и как обновления влияют на индивидуальные настройки. Если обязательный сценарий требует постоянного ручного обхода, это существенный критерий выбора.
Собственная разработка имеет смысл, когда ценность продукта связана с особыми правилами совместной работы или готовая модель не выполняет обязательные ограничения. Но и тогда стандартные компоненты учётных записей и инфраструктуры можно оценивать отдельно.
Проверьте модель на двух организациях одновременно
Для испытаний подготовьте похожие названия проектов и одинаковые имена файлов в разных компаниях. Такие данные помогают обнаружить зависимость от случайного названия вместо правильной принадлежности.
Попросите одного участника работать в двух организациях, а другого — только в одной. Проверьте переключение контекста, прямые ссылки, сохранённые страницы и полученные уведомления. После отзыва членства повторите те же действия.
Не ограничивайтесь тем, что запрещённая кнопка исчезла. Доступ к данным и действиям должен проверяться на стороне системы. Отдельно испытайте разрешённые операции: общий запрет для всех не является правильной изоляцией.
Результаты свяжите с ролями и исходными условиями. Если позже добавляется новый отчёт или загрузка файлов, тот же набор граничных сценариев нужно учитывать в проверке изменения. Так модель организаций остаётся действующим правилом продукта, а не разовой настройкой при запуске.
Чеклист для разговора о B2B SaaS
- Определено, что считается отдельной организацией.
- Пользователь и его членство хранятся как разные понятия.
- Проверено участие одного человека в нескольких компаниях.
- Перечислены права владельца, сотрудника и внешнего участника.
- Поиск, файлы и отчёты соблюдают те же границы доступа.
- У поддержки есть понятный порядок помощи клиенту.
- Особые требования разделены на настройки и индивидуальные изменения.
- Согласован порядок ухода сотрудника и завершения обслуживания компании.
На встречу с ExtentLab полезно принести два различающихся примера организаций и по одному совместному сценарию. По ним можно обсуждать границы данных, первую версию и требования к проверке, не обещая клиентам возможности, которых ещё нет в продукте.