CRM для агентства на VPS: отдельные проекты, файлы и доступ заказчиков

Заказчик должен видеть согласованный результат: макеты на утверждении, акт, отчёт за месяц. Он не должен видеть, как внутри агентства спорили о стоимости: «закладываем сто часов, но реально будет шестьдесят», «этот клиент всё равно не заметит». С этой границы и стоит начинать устройство агентской CRM. Не с выбора продукта, не с размера сервера, а с вопроса: кто, что и на каком основании имеет право увидеть.

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

Внутренняя CRM и клиентский кабинет — это два продукта в одном

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

В EspoCRM эта идея оформлена как отдельная сущность, портал. По документации EspoCRM о порталах, портальный пользователь обязательно связывается с Portal, а права задаются портальными ролями. Дополнительные Portal Roles объединяются с ролями портала. Практический смысл такой: у внешнего человека есть собственная точка входа и собственный набор прав, не пересекающийся с ролями сотрудников. Он не «менеджер с урезанными правами», а другой тип пользователя.

В OpenProject рамка иная. Там нет отдельного «кабинета клиента» как такового: внешний человек становится пользователем системы и получает роль в конкретных проектах. Эти подходы стоит сравнивать не по принципу «что лучше», а по принципу «что в вашем агентстве первично»: отношения с организацией или рабочие пространства проектов.

Account или Contact: к чему привязывать видимость

Центральный вопрос портала EspoCRM: на что опирается видимость данных. В документации описаны уровни доступа account и contact, которые связывают то, что видит пользователь, с соответствующими записями, и уровень own, при котором видны записи, созданные самим пользователем. Это три разные логики, и выбор между ними определяет всё остальное.

• Account: заказчик видит материалы, относящиеся к его организации. Подходит, когда с агентством работает команда клиента и коллеги должны видеть одно и то же: если маркетолог ушёл в отпуск, его заменяющий открывает те же материалы.
• Contact: человек видит только то, что связано лично с ним. Подходит, когда внутри организации-клиента нужно разделить, скажем, финансового директора, которому нужны акты, и пиар-менеджера, которому нужны тексты.
• Own: человек видит лишь созданное им самим. Это удобно для заявок и обращений: клиент завёл запрос и видит только свои запросы, но не чужие.

Здесь легко ошибиться, выбрав уровень по привычному названию. Например, в кастомной сущности «Отчёт по проекту» может появиться поле с именем «Клиент», и кажется, что этого достаточно. Но по документации для пользовательских типов сущностей нужны именно отношения с Account или Contact и их настройка для ACL; одного похожего имени поля недостаточно. Поле-«красивая подпись» ничего не ограничивает: система проверяет связь, а не смысл слова. Если отчёт связан с организацией текстовым полем, портал его либо не покажет, либо, при неудачной настройке прав, покажет не тем.

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

Что видит заказчик: аудитория у каждой записи своя

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

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

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

Один клиент и несколько проектов

Возьмём типовую ситуацию. Компания-заказчик ведёт у агентства три направления: сайт, контекстную рекламу и редизайн упаковки. Над каждым работает своя группа, и на стороне клиента тоже разные люди: разработчика ждёт ИТ-директор, рекламу согласует маркетолог.

В EspoCRM-модели это решается через Account и Contact. Организация одна, проекты связываются с ней, и все контакты клиента с уровнем account увидят все три направления. Если нужна дифференциация, часть записей привязывают к конкретному Contact, и тогда ИТ-директор видит релизы сайта, а маркетолог получает рекламные отчёты. Трудность в том, что проект как отдельное пространство здесь не существует: он лишь запись, связанная с организацией. Если проектов много, и у каждого своя аудитория, придётся продумать связи аккуратно, иначе правила превратятся в кружево исключений.

В OpenProject картина противоположная. По документации OpenProject о ролях и правах, проектная роль ограничена конкретным проектом, а один пользователь может иметь разные роли в разных проектах. Значит, ИТ-директор клиента добавляется в проект «Сайт» с ролью, допускающей комментирование, а в проект «Реклама» не добавляется вовсе. Пространство проекта и есть граница. Организация клиента в этой модели не является узлом прав: система видит не «компанию», а людей и проекты, в которых они состоят.

Отсюда сравнение, которое полезно держать в голове:

• EspoCRM-портал отвечает на вопрос «чьи это записи?» и привязывает видимость к организации или контакту.
• OpenProject отвечает на вопрос «в каком проекте этот человек и в какой роли?» и привязывает видимость к участию.

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

Подрядчик в разных проектах

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

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

В той же документации есть тонкость, которую стоит запомнить, потому что она работает против интуиции. Роль Non-member применяется к зарегистрированным пользователям, не входящим в состав проекта, но только если проект публичный. Иначе говоря, если сделать проект публичным ради удобства, например чтобы не добавлять каждого по отдельности, то все зарегистрированные пользователи системы, включая подрядчиков из соседних проектов, получат права роли Non-member. А Anonymous связан с публичным проектом и разрешённым доступом без входа. Практический вывод для агентства: внутренние проекты публичными не делать, а права Non-member и Anonymous держать минимальными, если публичный проект всё же понадобился, например для открытой дорожной карты продукта.

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

Сопровождение: сколько стоит граница в часах

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

В модели портала на каждого нового клиента нужно создать Account, связать контакты, создать портальных пользователей, привязать к Portal и проверить, что портальные роли дают ровно то, что нужно. Если типовых ролей две-три, это в основном рутинное заполнение, а не конструирование. Основные затраты возникают не при создании, а при исключениях: когда клиент просит показать отчёт только одному из двух менеджеров, приходится переходить с уровня account на contact и проверять пользовательские сущности на наличие реляционной связи.

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

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

Что при этом делает сервер

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

Если коротко прикинуть ресурсы, то VPS MAATRIX предлагает несколько уровней: от Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe до Djed с 16 vCPU, 32 ГБ RAM и 320 ГБ. Промежуточные Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) дают ступени роста. Эти цифры описывают ресурсы, а не обещание ёмкости: сколько клиентов выдержит конкретная установка, показывает только замер на ваших данных. Разумно начинать с запаса по оперативной памяти и месту на диске, а выбор следующей ступени делать по реальной картине использования.

Если CRM и проектная система живут на одном сервере, стоит учесть, что обе хотят память под базу данных. Для небольшого агентства удобнее разнести их по отдельным VPS: тогда обновление одной не задевает другую, а доступ администратора к ним различается. Это решение об организации работы, а не гарантия отказоустойчивости: отдельные серверы сами по себе не делают одно приложение надёжнее. Для файлового обмена в каталоге MAATRIX также упомянут Nextcloud с установкой, а точное наличие и операционная система уточняются в форме заказа. Доступ root даёт полный контроль над сервером, и вместе с ним приходит ответственность за его обновление и защиту, которую никакие роли приложения не заменят. Общие вопросы выбора сервера под студию разобраны в материале про VPS для веб-студии и агентства.

Когда сотрудничество закончилось

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

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

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

Короткий порядок для завершения сотрудничества:

1. Зафиксировать, какие материалы клиент должен получить на руки: итоговые файлы, отчёты, акты.
2. Передать их одним пакетом и убедиться, что клиент их получил, пока доступ ещё работает.
3. Отключить портальных пользователей или убрать участников из проектов.
4. Проверить публичность проекта и права Non-member и Anonymous.
5. Отметить в CRM, что внешний доступ закрыт, чтобы следующий сотрудник не искал это по журналам.

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

Как это выглядит с той стороны

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

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