Представьте двух менеджеров: Анну и Бориса. У них один продукт, один общий чат и одна таблица, которая давно разрослась до сорока колонок. Анна ведёт студию дизайна, которая просила счёт на прошлой неделе. Борис ведёт интернет-магазин, ожидающий коммерческое предложение. Ни тот ни другой не может с уверенностью сказать, кто должен позвонить завтра клиенту, который написал обоим сразу. Новая CRM нужна не затем, чтобы появились красивые поля, а затем, чтобы на этот вопрос отвечала система, а не память и не переписка.
Ниже мы соберём в EspoCRM минимальную рабочую конструкцию для такой пары: несколько стадий сделки, понятного владельца у каждой записи, общую команду, разные клиенты и проверку того, что один менеджер не видит и не правит лишнего. В конце разберём, что именно нужно сохранять на VPS, чтобы вся эта аккуратность не исчезла вместе с диском.
Стадии сделки: начинаем с действий, а не с названий
Самая частая причина мёртвой воронки — стадии, придуманные на совещании и не совпадающие с тем, что менеджеры делают руками. «Квалификация», «Развитие потребности», «Согласование» звучат солидно, но если Анна не может сказать, чем «развитие» отличается от «квалификации», она поставит сделку туда, куда ей удобнее. Через месяц воронка превращается в декорацию.
Надёжнее идти от реальных действий. Возьмите одну сделку Анны и выпишите, что с ней происходит от первого контакта до оплаты: пришёл запрос, менеджер созвонился и выяснил задачу, отправил предложение, клиент вернулся с правками, выставлен счёт, пришла оплата. Каждое событие, после которого меняется то, что менеджер делает дальше, и есть граница стадии. Если после события следующее действие то же самое, отдельная стадия не нужна.
Для команды из двух-трёх человек обычно хватает пяти-шести стадий. Условный набор для услуг выглядит так:
- Новый запрос — клиент написал, разговора ещё не было. Следующее действие: связаться.
- Задача выяснена — состоялся разговор, понятно, что и в какие сроки нужно. Следующее действие: подготовить предложение.
- Предложение отправлено — ждём ответа. Следующее действие: напомнить в оговорённый день.
- Согласование — клиент вносит правки или спорит о цене. Следующее действие: ответить на конкретное возражение.
- Ждём оплату — счёт выставлен.
- Выиграна и Проиграна — закрытые итоги.
Проверка простая: у каждой стадии должно быть одно предложение вида «если сделка здесь, то менеджер должен сделать вот это». Если фраза получается расплывчатой, стадия лишняя. Хорошо, когда в конце концов в списке остаётся то, что менеджер мог бы объяснить стажёру за минуту.
Одна сделка, пять движений
Проиграйте путь сделки Анны целиком. Пришёл запрос от студии: Анна создаёт сделку, вписывает название клиента и сумму ориентировочно, ставит «Новый запрос». Через час она звонит, узнаёт, что нужен фирменный стиль к открытию в сентябре, и переводит сделку в «Задача выяснена», записывая в описании срок и бюджетную вилку. Отправив предложение, она двигает стадию и создаёт задачу «напомнить во вторник». Клиент просит скидку — стадия «Согласование». Пришёл ответ «да» — выставлен счёт, стадия «Ждём оплату».
Обратите внимание, что на каждом шаге меняются два факта: стадия и дата ближайшего действия. Именно пара «где мы» и «что дальше и когда» делает воронку полезной для руководителя. Список стадий без следующего шага показывает только прошлое, а следующий шаг без стадии ничего не говорит о масштабе работы. Этот принцип мы вернём в финале.
Владелец и команда: к кому прикреплена работа
В EspoCRM запись имеет ответственного пользователя и может быть привязана к одной или нескольким командам. Эти два поля и определяют, что значит «моя запись» и «запись нашей группы» для системы доступа. Если оставить их пустыми или заполнять по настроению, никакая роль не сработает так, как вы ожидаете: ограничение «только свои» опирается на ответственного, а ограничение «команда» — на команды записи.
Для нашего примера заведите команду «Продажи» и включите в неё Анну и Бориса. Руководитель может состоять в ней же или иметь отдельную роль, об этом ниже. Клиенты Анны получают ответственным Анну, клиенты Бориса — Бориса, а все записи привязаны к команде «Продажи». Получилось два измерения: у каждой записи есть конкретный человек и общая рамка, внутри которой коллеги могут при необходимости заглянуть друг к другу.
Привычка, которую стоит закрепить сразу: ответственный выбирается при создании записи, а не «потом разберёмся». Запись без владельца либо исчезнет из чужих списков, либо, наоборот, окажется видимой не тем, смотря по тому, как настроены роли. Лучше убрать эту неопределённость на входе: например, правило «каждая новая сделка при создании получает ответственного — того, кто принял запрос».
Уровни all, team, own, no на живых задачах
Роли в EspoCRM определяют для каждого типа записи действия create, read, edit, delete и stream, а для каждого действия — уровень доступа. Для чтения, изменения и удаления доступны значения all, team, own и no. Описание ролей перечисляет эти уровни; удобнее всего понять их на конкретных вопросах: «может ли Борис открыть сделку Анны» и «может ли он её изменить».
Уровни читаются так:
- all — действие доступно для любых записей этого типа.
- team — для записей, у которых есть общая с пользователем команда.
- own — для записей, где пользователь ответственный.
- no — действие недоступно.
Теперь применим к паре Анна и Борис. Все записи привязаны к команде «Продажи», ответственные разные. Рассмотрим три варианта роли «Менеджер» для сделок.
| Настройка read / edit | Борис открывает сделку Анны | Борис меняет стадию у сделки Анны | Для чего подходит |
|---|---|---|---|
| own / own | Нет, запись не видна в списках | Нет | Строгое разделение клиентов |
| team / own | Да, общая команда «Продажи» | Нет, ответственный не он | Видеть контекст коллеги, но не вмешиваться |
| team / team | Да | Да | Взаимозамена на время отпуска |
Для двух менеджеров с отдельными клиентами хорошая стартовая точка — вторая строка: читать по команде, править своё. Борис видит, что Анна уже общалась со студией, и не напишет клиенту параллельно, но не сдвинет стадию её сделки случайным кликом. Если вам важно, чтобы базы клиентов не просматривались друг другом вообще (например, у менеджеров разные заказчики и конфликт интересов), выбирайте own на чтение, и командная привязка перестанет открывать записи.
Отдельно подумайте про удаление. Уровень для delete логично держать строже, чем для edit: ошибочно изменённую стадию вернуть легко, а удалённую сделку придётся искать в резервной копии. Для менеджера нередко достаточно own или no, а удалять оставляют руководителю.
Что делать руководителю
Руководителю нужна воронка целиком, но не обязательно право менять чужие сделки. Роль с read на уровне all и edit на уровне own или team даёт обзор без вмешательства. Если руководитель сам ведёт часть клиентов, его собственные записи он правит как ответственный, а чужие только просматривает. Так отчёт по воронке строится на всей базе, а ответственность за конкретную сделку остаётся у конкретного менеджера.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации Россия, США, Франция и Великобритания. Оплата картой РФ и по СБП.
Две роли у одного человека: когда разрешающее побеждает
Ограничения в CRM ломаются не там, где их задали, а там, где наложились. Пользователь может получить роль напрямую и ещё роли через команды. Согласно описанию ролей EspoCRM, при нескольких ролях более разрешающее правило имеет приоритет, а командные роли применяются к членам команды. Из этого следует практическое последствие: если одна из ролей разрешает чтение всего, строгая «own» в другой роли ничего не ограничит.
Покажем на примере. Вы завели роль «Менеджер» со строгим own для сделок и назначили её Борису. Затем создали команду «Продажи», привязали к ней роль «Общий доступ» с read на уровне team и добавили в команду обоих менеджеров, чтобы они видели общих клиентов. Борис теперь имеет две роли. Для чтения сделок одна говорит own, другая team, и побеждает более широкая. Сделка Анны становится видимой Борису, хотя вы сознательно настраивали «Менеджера» строго. Ошибки в настройках нет: просто эффект суммы ролей отличается от каждого из слагаемых.
Из этого вытекает простое правило проектирования. Не давайте сразу и персональную, и командную роль на одни и те же сущности, если хотите, чтобы одна из них ограничивала. Либо вся логика доступа живёт в роли пользователя, а командам роли не назначаются, либо наоборот. Если нужна общая видимость для одних сущностей и строгая для других, разнесите их по разным ролям так, чтобы пересечений на одном типе записей не оставалось: клиентские сделки пусть решает одна роль, общие справочники — другая.
Проверка через Access: роль не доказательство
Наличие роли в карточке пользователя ещё ничего не говорит о том, что он реально может делать. Роль могла быть переопределена командной, пользователя могли добавить в команду на прошлой неделе, а часть прав вы меняли вручную. Поэтому после настройки проверяйте итог, а не намерение. В карточке пользователя в EspoCRM есть вкладка Access, где показаны эффективные разрешения, то есть то, что получилось после наложения всех ролей. Об этом говорит и страница про роли.
Рабочая процедура на нашем примере занимает несколько минут:
- Откройте карточку Бориса и перейдите на Access. Найдите строку сделок и посмотрите уровни read, edit, delete. Ожидаем team, own и no (или то, что вы задумали).
- Если видите all там, где ожидали team, ищите вторую роль: смотрите, в каких командах состоит Борис и какие роли привязаны к этим командам.
- Войдите под Борисом или откройте окно инкогнито с его учётной записью. Найдите в списке сделку Анны. Видна ли она? Откройте её. Попробуйте сменить стадию и сохранить.
- Повторите те же действия под Анной с записью Бориса, чтобы убедиться, что правило симметрично.
- Создайте тестовую сделку без ответственного и проверьте, кто её видит. Результат покажет, что произойдёт с забытыми записями.
Хорошая проверка — это не «роль назначена», а три наблюдаемых результата: Борис открыл чужую сделку или нет, Борис смог изменить её или нет, Борис нашёл её в поиске или нет. Если ожидание и результат совпали по всем трём, настройка работает. Повторять проверку стоит каждый раз, когда вы добавляете человека в команду или создаёте новую роль: ломается обычно именно эта точка.
Что сохранять, чтобы всё это пережило диск
Роли, команды, стадии, ваши клиентские записи и вложения живут не в одном месте. По документации по резервному копированию EspoCRM, полная копия состоит из файлов EspoCRM и дампа базы данных. База хранит сами записи и настройки доступа, файлы — загруженные вложения и пользовательские настройки приложения. Сохранив только одно, вы получите либо пустую оболочку, либо записи без прикреплённых документов. Копировать нужно обе части и желательно в один момент, чтобы они соответствовали друг другу.
Практический расклад на VPS такой. База выгружается дампом средствами используемой СУБД, каталог EspoCRM архивируется целиком вместе с каталогом данных. Обе части складываются в архив с датой в названии и уезжают с самого сервера: на другой VPS, в облачное хранилище или на рабочий компьютер. Копия, лежащая на том же диске, что и CRM, не спасёт от потери этого диска. Автоматические копии на уровне хостинга в тарифах не следует считать данностью: если вы на них рассчитываете, убедитесь в этом отдельно, а пока планируйте собственное расписание.
Как часто копировать — вопрос того, сколько работы вы готовы потерять. Для команды из двух менеджеров, которые ежедневно правят сделки, потеря суток означает, что придётся вспоминать, кому и что обещали вчера. Ночная копия обычно приемлема, а копия перед любым обновлением EspoCRM или массовым импортом — обязательна независимо от расписания.
Восстановление как отдельный навык
Копия, из которой ни разу не пробовали восстановиться, остаётся предположением. Документация подчёркивает, что восстановление затрагивает не только базу: нужно вернуть файлы, выставить права, загрузить дамп и проверить расписание cron, а для контейнерной и обычной установки инструкции разделены. Выбирайте ту, что соответствует вашей схеме, и не смешивайте шаги.
Cron в этом списке неслучайно. Он запускает фоновые задачи EspoCRM, и после переноса на новый сервер система может выглядеть живой, а напоминания и обработка очередей молчать. Это тот самый класс отложенных поломок, о которых мы писали в материале про то, что ломается в EspoCRM через полгода.
Тест восстановления можно провести за вечер на отдельном недорогом VPS. Разверните чистую установку, подставьте файлы и дамп, поправьте права, проверьте cron и войдите под обоими менеджерами. Затем повторите проверку из прошлого раздела: на вкладке Access у Бориса те же уровни, чужая сделка видна так, как задумано. Так вы подтверждаете сразу две вещи: копия содержит всё нужное, а права после переноса не изменились.
Какой VPS нужен небольшой команде
Для двух-пяти пользователей EspoCRM нагрузка невелика: веб-сервер, PHP, база данных и фоновые задачи. На VPS MAATRIX с NVMe, процессорами AMD EPYC и root-доступом можно начать с тарифа Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) или Uab (2 vCPU, 4 ГБ, 80 ГБ). Точное число пользователей без замера обещать нельзя: нагрузку определяют ваши импорты, вложения и объём истории. Практичный ориентир — запас по диску. Вложения и архивы копий растут быстрее, чем кажется, а копия, которая временно лежит на сервере перед отправкой, занимает место дважды. Если вы часто прикладываете к сделкам большие файлы, склоняйтесь к Uab и выше.
Root-доступ полезен именно в этой истории: вы сами настраиваете расписание дампов и cron, не завися от чужих ограничений. Место размещения — UK, US, RU или FR из публичного предложения — выбирайте по тому, где находятся ваши пользователи и какие требования к хранению данных клиентов у вас есть; доступность конкретной ОС и локации уточняйте в форме заказа.
Новая сделка без договорённостей в чате
Вернёмся к Анне и Борису. В понедельник приходит новый запрос от компании, которая написала на общую почту. Раньше он повис бы в чате с вопросом «кто возьмёт?». Теперь первый, кто увидел обращение, создаёт сделку в стадии «Новый запрос» и указывает себя ответственным, например Бориса. Запись привязана к команде «Продажи». Следующий шаг записан сразу: задача «связаться до 15:00» с датой.
Что происходит дальше без единого сообщения в чате. Анна открывает список сделок команды и видит новую запись с владельцем Борисом: звонить ей не нужно, но контекст доступен, если клиент вдруг напишет и ей. Изменить стадию она не может, потому что её роль даёт edit только на собственные записи. Руководитель видит ту же сделку в общей воронке и по задаче понимает, что завтра её ждут в стадии «Задача выяснена». Если Борис заболеет, руководитель переназначит ответственного, и сделка перейдёт в его список вместе с историей.
Вот и весь результат: у новой сделки есть владелец, у владельца есть следующий шаг со сроком, и всем остальным заранее известно, что именно они увидят. Эту видимость вы проверили на вкладке Access, а не предположили, и она сохранена в копии, из которой можно восстановить систему целиком. Договорённости в чате остаются для шуток и обсуждений, а не для вопроса «чья это работа».