Twenty CRM на своём сервере: репетиция переноса клиентов с проектами и несколькими контактами

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

Вот с такой карточки и стоит начинать разговор о Twenty CRM на своём сервере. Установка, как правило, отвечает на вопрос «запустится ли система». Пилот отвечает на другой вопрос: «поместится ли в неё наша работа». Это разные вещи, и вторая гораздо дороже первой.

Разбираем карточку на детали

Первое, что нужно сделать, это не открывать интерфейс, а взять лист бумаги или таблицу и разложить карточку на сущности. Документация описывает модель данных Twenty через стандартные объекты: Companies, People, Opportunities, Tasks, Notes, а также пользовательские объекты (Twenty: Data Model). Для нашей студии первая раскладка выглядит почти очевидно:

Заметьте, что вся сложность спрятана в правом столбце. Стандартные объекты закрывают очевидное, а вот вопросы «что к чему относится» и составляют настоящую модель. Поэтому пилот начинается с этих вопросов, а не с красивой настройки интерфейса.

Проект: отдельный объект или поле

Самое частое искушение — не создавать объект «Проект», а завести в компании текстовое поле «Проекты» и перечислять их через запятую. На первый взгляд это быстро. На второй у проекта обнаруживаются собственные свойства: статус, дата старта, ответственный, бюджет, ссылка на репозиторий или рекламный кабинет. Если их негде хранить, их начинают дописывать в заметки, и структура снова превращается в текст.

Практический критерий простой. Если у сущности есть собственная жизнь (свой статус, свой ответственный, свои задачи), она заслуживает отдельного объекта. Если это лишь признак компании («отрасль», «источник»), достаточно поля. Для пилота создайте объект «Проект» и посмотрите, как он связывается с компанией и сделкой. Документация говорит, что пользовательские объекты в Twenty существуют, и что связи между объектами документированы, включая many-to-many. Это определяет вашу модель: вы вправе проектировать структуру, а не подгонять её под три стандартных объекта.

Типы полей: где таится разница между «похоже» и «то же самое»

В той же документации описаны различные типы полей, а также системные поля id, createdAt и updatedAt. Для пилота мало знать, что типы есть. Нужно сопоставить каждое поле старой карточки с типом в новой модели и честно записать, где соответствие неточное. Удобно делать это построчно, на одном экземпляре карточки:

• поле «Кто в агентстве главный по клиенту» в старой системе было выпадающим списком из имён сотрудников; в новой модели его нужно решить: это список значений или связь с отдельным объектом пользователя или участника команды;
• поле «Бюджет проекта» хранило число с пометкой валюты внутри текста; здесь придётся выбрать, как представить сумму и валюту, чтобы потом можно было фильтровать и считать;
• поле «Дата следующего контакта» было просто датой; проверьте, как оно участвует в напоминаниях и можно ли по нему строить рабочие списки;
• поле «Теги» содержало свободный набор слов; решите, нужен ли контролируемый набор значений или допустима свободная форма.

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

Один человек, две компании, три проекта

Теперь самое интересное. Реальные клиентские данные редко образуют аккуратное дерево. Бухгалтер работает с заказчиком и с его дочерней структурой. Маркетолог ведёт два проекта. Подрядчик участвует в проектах нескольких ваших заказчиков. Если ваша модель умеет только «у компании много людей, у человека одна компания», такие случаи придётся ломать или дублировать.

Здесь и пригодится то, что в документации указаны связи many-to-many (Twenty: Data Model). Но сказать «возможность есть» мало. Проверять нужно на конкретном примере из ваших данных. Сформулируйте для себя три контрольных случая:

1. Один человек связан с двумя проектами разных компаний. Проверьте, как это выглядит со стороны каждого проекта и со стороны человека: видно ли обе связи, не приходится ли дублировать карточку.
2. Один проект связан с несколькими людьми разных ролей. Проверьте, можно ли выразить роль человека именно в этом проекте, или роль живёт только в карточке самого человека.
3. Сделка связана и с компанией, и с проектом, и с контактным лицом. Проверьте, не теряется ли какая-то из трёх связей при просмотре сделки.

Второй случай обычно оказывается самым коварным. Связь «многие ко многим» сообщает, что человек и проект соединены, но не всегда сообщает, в какой роли. Если вам важно, что Анна — бухгалтер в одном проекте и лицо, принимающее решения, в другом, то нужна либо промежуточная сущность «Участие в проекте» с полем роли, либо иной способ хранить роль. Это уже не вопрос «есть ли функция», а вопрос проектирования, и решить его нужно до массового импорта, а не после.

Промежуточный объект как проверка зрелости модели

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

Этапы сделки и слово «стадия»

Сделки в Twenty живут в объекте Opportunities. Для пилота важно не перенести названия стадий, а понять, что эти стадии означали в старой системе. Часто в одном поле «Этап» смешаны разные вещи: состояние переговоров, состояние документов и состояние оплаты. «Договор на подписи» и «Ждём оплату» — это не продолжение друг друга, а параллельные процессы.

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

Собираем небольшой workflow

Когда структура данных выдержала первую проверку, пора смотреть, как система реагирует на события. Документация описывает workflow как набор из триггера, шагов и переменных (Twenty: Workflows). Триггеры документированы разные: изменение записей, ручной запуск, расписание и webhook. Среди действий названы операции с записями, HTTP-запросы, условия и задержки.

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

Разложим этот процесс на части:

• Триггер. Изменение записи сделки: поле стадии получило значение «Договор подписан».
• Условие. Проверить, что проект для этой сделки ещё не создан. Иначе повторное сохранение карточки породит дубль.
• Шаг с записью. Создать запись проекта и заполнить из сделки название, компанию и ответственного.
• Шаг с задачей. Создать задачу и привязать её к проекту.
• Переменные. Данные сделки (название, компания, ответственный) должны попасть в следующие шаги; именно ради этого в workflow есть переменные.

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

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

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

Тот же подход к рабочему дню разбирается в статье Twenty CRM хорош в демо — смотрим, как он держится в рабочем дне; здесь мы идём с другой стороны и проверяем модель данных на ваших записях.

Сопоставляем привычные действия с новой моделью

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

Для каждого действия заполните небольшую таблицу:

Колонку «Число шагов» заполняйте цифрами, полученными руками, а не оценкой. Это ваши данные пилота, и никто, кроме вас, их не измерит. Цифры в таблице выше намеренно не заполнены: они зависят от вашей модели и вашей команды.

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

Неудобство, которое не лечится полем

Теперь о главном. В любом пилоте рано или поздно обнаруживается неудобство иного рода. Не «не хватает поля», а «наша работа устроена не так, как предполагает эта модель». Простое добавление поля тут не поможет, потому что проблема не в данных, а в форме взаимодействия.

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

Что можно делать в такой ситуации? Есть несколько честных вариантов, и у каждого своя цена:

1. Изменить привычку. Если команда готова читать клиента по вкладкам, потеря небольшая. Но проверьте это не опросом, а наблюдением: дайте подготовиться к встрече по реальной карточке и посмотрите, что человек открывает и что пропускает.
2. Изменить модель. Возможно, часть информации правильнее хранить как заметки на уровне компании, а не раскладывать по проектам. Вы теряете структуру, но выигрываете в связности.
3. Дополнить процесс. Workflow может при ключевых событиях создавать заметку в общей ленте компании. Это дублирование, и его нужно держать под контролем, иначе лента превратится в шум.
4. Отложить перенос. Если неудобство затрагивает ежедневную работу всей команды и ни один из путей не устраивает, это законная причина не переносить клиентов сейчас.

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

Импорт малой выборки

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

• клиента с одним контактом и одним проектом, как базовый случай;
• клиента с несколькими контактами в разных ролях;
• клиента, у которого общий контакт с другим клиентом;
• клиента с несколькими проектами и открытой сделкой;
• клиента с «грязными» данными: дубли, пустые поля, странные форматы телефонов, составные названия;
• клиента с длинной историей заметок.

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

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

Где разместить пилотную установку

Пилот не требует тяжёлой инфраструктуры: нужен отдельный экземпляр, куда не страшно записать тестовые и копии рабочих данных, и доступ, который есть у нескольких участников команды. Для этого подходит обычный VPS с root-доступом, на котором вы сами устанавливаете и настраиваете сервис. У VPS MAATRIX заявлены NVMe-диски, процессоры AMD EPYC и root-доступ, в публичном предложении названы локации UK, US, RU и FR, а после оплаты картой РФ или через СБП виртуальный сервер создаётся автоматически за пару минут.

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

Один процесс, который решает судьбу переноса

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

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

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