Постройте лёгкую схему CRM, которая держит Contacts, Deals, Activities и права простыми, но при этом поддерживает надёжную отчётность и повседневные рабочие процессы.
Небольшой команде нужен CRM, который быстро отвечает на повседневные вопросы: с кем мы общаемся, что мы пытаемся закрыть, что произошло последнее, и что будет дальше. Это и есть главная задача лёгкой схемы CRM. Всё, что не помогает отвечать на эти вопросы, обычно — шум.
Маленьким командам редко нужна сложная иерархия аккаунтов, десятки кастомных объектов или запутанные модели скоринга. Им нужны чёткая ответственность, простая история контактов и понятный всем pipeline.
«Простота» рушится, когда всё держится на свободном тексте и дублирующихся данных. Если один человек пишет стадию сделки как "Negotiation", а другой — "negotiating", отчёты превращаются в гадание. Если активности хранятся в отдельных таблицах для звонков, встреч и заметок, у вас будет несколько полей даты и не будет надёжного значения «последний контакт».
Эта схема опирается на четыре основных объекта, которые покрывают большинство задач маленькой команды, не превращая систему в монстра:
Чистая отчётность означает, что вы надёжно видите сделки по стадиям за неделю, коэффициент конверсии между стадиями, среднее время на стадии, последнюю активность по сделке и открытые задачи каждого менеджера на сегодня. Эти отчёты должны остаться понятными, когда команда вырастет с 3 до 15 человек.
Если вы строите внутренний CRM в no-code инструменте типа AppMaster (appmaster.io), такой подход держит базу данных компактной и при этом даёт стабильные числа для дашбордов и еженедельных обзоров.
Лёгкая схема CRM работает, когда отвечает на один главный вопрос: где хранится этот факт? Если одна и та же «истина» может храниться в двух местах — она так и будет храниться в двух, и ваши отчёты поплывут.
Выберите небольшой набор объектов-источников правды и сделайте всё остальное указывающим на них. Для большинства малых команд это Contacts, Organizations (опционально), Deals и Activities. Когда нужна детализация — добавляйте новую таблицу, вместо того чтобы засорять одно текстовое поле смыслом и превращать его в «ящик для хлама».
Несколько правил помогут модели оставаться простой и гибкой:
Готовьтесь к «грязным» данным с первого дня, добавив несколько скучных, но важных полей: created_at, updated_at и простое external_id (или import_source + import_key) в основных таблицах. Это даст безопасный способ повторного импорта без создания дублей.
Конкретный пример: вы импортировали таблицу, где «Acme Inc.» в половине строк записано как «ACME». Если Organization.name редактируемо, а Organization.id стабилен, вы сможете позже объединить записи, не сломав существующие сделки и активности.
Лёгкая схема CRM начинается с одного решения: вы отслеживаете только людей или людей и компании? Если вы продаёте бизнесам, почти всегда стоит хранить и Contact (человека), и Organization (компанию). Если вы продаёте конечным пользователям, организации можно не отслеживать и хранить всё в Contacts.
Для B2B держите связь простой: каждый контакт принадлежит одной основной организации (nullable), а организация может иметь много контактов. Это покрывает большинство рабочих процессов маленькой команды без сложных аккаунт-иерархий.
Самый быстрый путь к грязным данным — требовать слишком много полей. Хорошая отправная точка:
id, имя (или first_name + last_name), created_atid, name, created_atВсё остальное (должность, сайт, адрес, отрасль, источник) можно сделать опциональным. Правила можно добавить позже, но сложно очистить базу, полную заполнителей вроде "N/A".
Соблазнительно требовать уникальность email. Это хорошо для B2C или если CRM одновременно используется как система логина. В маленьких B2B командах часто используются общие почтовые ящики (sales@, info@) и повторяющиеся номера телефонов. Жёсткие правила уникальности могут блокировать валидные записи.
Практичный компромисс:
Если нужны несколько email или телефонов, не добавляйте колонки email_2 или phone_3. Используйте отдельную таблицу (например, ContactMethod с полями type, value, is_primary). Отчёты останутся чистыми, а модель масштабируется естественно.
Пример: команда встречает Пэта, который меняет работу посреди квартала. С Contact, связанным с Organization, вы можете перевести Пэта в новую компанию, сохранить старые контактные методы для истории, и отчёты по компаниям будут считаться правильно.
Сделка — это единица прогноза: потенциальная покупка с понятным следующим шагом. Держите запись сделки компактной, а всё остальное — по ссылкам.
Начните с полей, которые поймёт любой в команде:
Для связей выберите одного основного контакта у сделки. Это упрощает отчётность (например, доход по контакту, win rate по сегменту). Если иногда нужно больше людей, добавьте таблицу deal_contacts, чтобы прикрепить дополнительных участников без превращения каждой сделки в сложную many-to-many модель. Большинству небольших команд хватает 1 основного контакта + опциональные участники.
Стадии — это то место, где CRM часто путаются. Не храните стадию в свободном тексте. Храните стадии как справочные данные, чтобы можно было переименовывать стадии без поломки отчётов. Минимальная таблица стадий может содержать:
stage_idpipeline_idstage_namestage_orderis_closed (или отдельные флаги для won и lost)Если команда мала, не разделяйте записи на «lead» и «deal», если вы действительно не управляете лидами по-другому. Простое правило: когда появляется реальная возможность для сделки — это deal. До этого держите запись как контакт со статусом «new» или «nurture». Это делает воронку читаемой и не засоряет числа наполовину созданными сделками.
Пример: двухчленная продажная команда ведёт «Acme Renewal» как сделку у Сэма, стадия «Proposal Sent», сумма 12,000, дата закрытия — следующий месяц. Основной контакт — покупатель, второй контакт добавлен как согласующее лицо по финансам. Отчёты остаются консистентными, потому что имена стадий и их порядок фиксированы.
Маленькой команде не нужны отдельные таблицы для звонков, писем, встреч и заметок. Одна модель Activity обычно достаточна и упрощает использование CRM и создание отчётов.
Создавайте одну запись на каждое событие (или планируемое событие). Добавьте простое поле type с небольшим фиксированным набором, например: call, email, meeting, note, task. Держите список коротким, чтобы люди выбирали одни и те же варианты.
Чтобы не было путаницы при связывании активностей, используйте простые правила:
На практике Activity может иметь contact_id (nullable) и deal_id (nullable), плюс опциональный owner_id (ответственный).
Храните и due_at, и completed_at. Они отвечают на разные вопросы. due_at показывает, что должно было произойти (план и нагрузка). completed_at показывает, что действительно случилось (исполнение и время цикла).
Статус можно вывести без отдельного поля: если completed_at заполнено — задача выполнена. Если нет — открыта. Это избегает дополнительных статусов, которые расходятся с реальностью.
Для текста активности держите одно поле для поиска, например summary или body. Избегайте лишней структуры в заметках на раннем этапе. Пример: «Call with Maya: confirmed budget, send proposal Friday.» Специальные поля добавляйте позже только при реальной необходимости.
Владение — это кто отвечает за следующий шаг. В лёгкой схеме CRM это обычно одно поле owner_user_id у сделки (и часто у контактов тоже).
Две трактовки «владельца» часто путают: назначение пользователю (конкретный человек) и назначение команде (группа). Если с самого начала всё делать командным, вы теряете ясность о том, кто должен действовать сегодня.
Рабочая настройка для большинства маленьких команд: всё видно всем, но каждая сделка имеет ровно одного владельца. Это облегчает сотрудничество и избавляет от краёв прав, когда нужно подменить коллегу.
Когда нужна более строгая видимость, делайте это одной переключаемой настройкой, а не сложной матрицей. Например, добавьте поле visibility у сделок и активностей со значениями public и private, где private значит «видно только владельцу (и администраторам)».
Команды или территории нужны, только если:
Владение влияет на отчёты. Если нужны аккуратные числа «по менеджеру», стройте отчёты по текущему owner_user_id у сделки. Если также нужны сводки по команде, добавьте owner_team_id (или выводите его из профиля владельца), но явно указывайте, какой источник является правдой.
Пример: два менеджера делят почтовый ящик. Новая сделка появляется без владельца (owner_user_id = null) и с owner_team_id = Sales. Когда Алекс её берёт, ставьте owner_user_id = Alex (оставьте команду как Sales). Ваша воронка остаётся читаемой, а суммарные показатели по команде — корректными.
Права работают лучше, когда разделены три идеи: роли (кто), ресурсы (что) и действия (что можно делать). Это — role-based access control (RBAC), и он остаётся понятным по мере роста команды.
Держите ресурсы близко к основным объектам: Contacts, Organizations, Deals, Activities и, возможно, Pipelines (если стадии можно редактировать). Определите небольшой и единый набор действий для всех: view, create, edit, delete, export.
Export стоит вынести отдельно. Многие команды нормально относятся к широкому просмотру, но хотят ограничить массовое скачивание данных.
Разрешения на уровне объектов — самое простое место для старта: «может ли эта роль редактировать сделки вообще?». Для большинства малых команд этого хватает на месяцы. Правила на уровне записей (по конкретной записи) — это то, где появляется сложность, поэтому добавляйте их только при реальной потребности.
Практичный первый шаг — правило владения: каждая запись имеет owner_user_id, и не‑админы могут редактировать только то, что им принадлежит. Если нужно чуть больше, добавьте team_id и разрешите просмотр на уровне команды, при этом оставив редактирование только владельцу.
Добавляйте их для случаев вроде:
Поддерживайте лёгкий, но реальный аудит: добавьте created_at, created_by, updated_at и updated_by в каждую основную таблицу. Если нужна более глубокая история, добавьте маленькую таблицу audit_log с полями: тип объекта, id записи, действие, кто, когда и короткий JSON изменённых полей.
Это проще всего, если воспринимать задачу как небольшой продукт: сперва определите данные, проверьте их на реальных записях, а потом делайте экраны.
Нарисуйте простую ERD на бумаге или доске. Держите мало таблиц, но чётко определите связи: контакт может принадлежать организации (опционально), сделка принадлежит pipeline и имеет владельца, активность может быть связана с контактом и/или сделкой.
Сделайте базу по порядку:
created_at, owner_id и ключевые имена обязательными; задайте дефолты для стадии и валюты, если используете суммы.owner_id, stage, due_at, created_at и внешние ключи, по которым вы фильтруете ежедневно.Прежде чем делать формы, выпишите 6–8 вопросов, которые команда задаёт каждую неделю. Например: «Сделки на стадии Negotiation по владельцу», «Просроченные активности», «Новые контакты в этом месяце», «Выручка по месяцам по закрытым сделкам». Если для ответа требуется запутанный join или много исключений — пофиксите схему сейчас.
Простой тест: добавьте 3 контакта в одну компанию, 2 сделки в разных стадиях и 6 активностей по ним (звонок, встреча, две задачи и две заметки). Проверьте, можете ли вы ответить, кто владеет, что дальше и что изменилось на прошлой неделе без домыслов.
Когда данные в порядке — делайте UI и автоматизацию в последнюю очередь. Так вы пойдёте быстрее и не придётся переписывать историю, чтобы отчёты совпадали с реальностью.
Грязные отчёты обычно начинаются с «быстрых правок», которые кажутся быстрее сегодня, но стоят вам каждую неделю. Лёгкая схема CRM работает лучше, когда у данных есть чёткие формы и несколько правил, которым команда действительно следует.
Распространённая ловушка — попытка засунуть всё в одну таблицу «customer». Звучит просто, пока не надо ответить на базовые вопросы вроде «Сколько сделок связано с одной компанией?» или «Какой человек сменил работу?» Разделяйте людей (contacts) и компании (organizations) и связывайте их.
Ещё один убийца отчётов — хранение стадий сделки в свободном тексте. Если один пишет «Negotiation», другой — «negotiating», ваш график по воронке уже неверен. Используйте фиксированный список стадий или таблицу стадий, чтобы каждая сделка ссылалась на один и тот же набор.
Избегайте упаковки нескольких значений в одно поле. Email через запятую или телефоны в одной колонке усложняют поиск, дедупликацию и экспорт. Если нужны множественные значения — храните их отдельными строками (например, по одному email на запись в дочерней таблице).
Активности становятся грязными, когда даты неясны. Одно поле «date» не скажет, было ли событие назначено на прошлую пятницу или завершено в прошлую пятницу. Разделяйте эти понятия, чтобы корректно строить отчёты по просрочке и по выполнению.
Вот краткий чеклист «спаси себя в будущем»:
due_at и completed_at раздельноПример: если команда логирует звонки как заметки и затем помечает их «сделано», редактируя то же поле, вы не сможете посчитать, сколько времени шли фолло‑апы. С раздельными полями такой отчёт прост.
Перед тем как строить экраны, автоматизации и дашборды, пройдитесь по проверке отчётов и правил. Лёгкая схема CRM остаётся лёгкой, если вы можете ответить на частые вопросы без костылей или одноразовых полей.
Пройдите эти проверки на реальных данных (даже 20 контактов и 10 сделок достаточно). Если вы упираетесь — скорее всего, не хватает поля, список picklist несогласован или связь слишком свободна.
Если на все пять вопросов ответ «да» — вы в хорошей форме. Если нет — исправьте схему, пока она ещё маленькая.
Практичный совет: определите стадии и типы активностей в одном месте (таблица или enum) и переиспользуйте их повсюду, чтобы каждый экран и процесс использовал одинаковые значения.
5‑членная агентство — хороший тест для лёгкой схемы CRM. Команда загружена, лиды приходят отовсюду, и никто не хочет подмазывать данные. Представьте: 1 админ, 2 продавца, 1 операционный лидер и 1 коллега только для чтения (основатель, который только смотрит цифры).
Поступает входящий запрос (форма или письмо): «Нужен редизайн сайта, бюджет $15k, срок 6 недель». Правило простое: создайте одну организацию (если это компания) и один контакт (человек). Затем создайте сделку, привязанную к организации, с контактом как основным контактным лицом.
Чтобы ускорить процесс, у них есть небольшой чеклист при приёме:
Активности предотвращают пропущенные звонки, потому что каждый следующий шаг становится датированным элементом, за который отвечает конкретный человек. Когда продажи провели discovery call, они логируют одну активность как meeting и сразу добавляют следующую: звонок через два дня. Если ops нужен набор данных для оценки работы, они создают задачу на той же сделке, чтобы всё отображалось в одном месте.
Роли остаются практичными: Admin редактирует всё и управляет настройками, Sales может создавать и обновлять контакты, сделки и свои активности, Ops обновляет поля, связанные с доставкой, и активности, а Read-only просматривает воронку и отчёты без прав на изменения.
Если вы хотите быстро превратить это в рабочий внутренний инструмент, AppMaster (appmaster.io) — простой вариант: вы можете смоделировать схему в Data Designer (PostgreSQL), добавить бизнес‑процессы в Business Process редакторе, собрать простой inbox лидов и страницу сделки, а затем задеплоить в AppMaster Cloud или в свою облачную среду, когда будете готовы делиться с командой.
What’s the simplest CRM schema a small team can start with?Начните с четырёх основных объектов: Contacts (люди), Organizations (опционально — компании), Deals (возможности) и Activities (единый журнал). Если на все вопросы команды можно ответить через эти объекты, вы останетесь быстрыми и не испортите отчёты.
Do I really need an Organizations table, or can I track people only?Используйте Organizations, если вы продаёте B2B и вам нужен отчёт по компаниям, или если у одного клиента может быть несколько контактов. Для B2C или когда вы работаете только с людьми, Organizations можно не добавлять и хранить всё в Contacts.
Why shouldn’t deal stages be a free-text field?Не храните стадии сделки в свободном тексте — из-за опечаток и разного написания дашборды приходят в негодность. Используйте фиксированный список (таблицу stages) и сохраняйте stage_id у сделки, чтобы при переименовании стадий история осталась корректной.
What fields should be required on Contacts, Organizations, and Deals?Требуйте минимально необходимое: id, имя и created_at для контактов и организаций, а для сделки — обязательные поля вроде стадии, владельца, суммы и даты закрытия. Слишком много обязательных полей приводит к мусорным значениям вроде «N/A».
How do I handle duplicate contacts and messy imports?Не блокируйте дубли целиком, если не уверены в рабочем процессе. Практика — разрешать дубли, но показывать предупреждение при совпадении по схожему email или телефону, и добавлять external_id (или ключи импорта), чтобы при повторном импорте не создавать лишних записей.
Should calls, meetings, notes, and tasks be separate tables?Лучше одна таблица Activities с полем type (call, email, meeting, note, task). Это делает «последний контакт», просроченные задачи и историю активности согласованной, потому что у всего один набор временных полей и одна структура.
Why do I need both due_at and completed_at on activities?Храните и due_at, и completed_at: due_at отвечает за планирование и отчёты по просрочке, completed_at — за исполнение и анализ времени выполнения. Совмещать их в одном поле — плохая идея для отчётов.
How should a Deal relate to Contacts (one or many)?По умолчанию — один основной контакт у сделки, чтобы отчёты были понятными и интерфейс — простым. Если иногда требуется несколько участников, добавьте таблицу deal_contacts для дополнительных контактов, а не делайте сложную many-to-many модель сразу.
What’s a practical ownership and visibility model for small teams?Хорошая отправная точка: всё видно всем, но у каждой сделки есть ровно один владелец, отвечающий за следующий шаг. Если нужна приватность позже, добавьте простое поле visibility со значениями public/private, вместо сложной матрицы прав.
What’s the fastest way to build and validate this schema in AppMaster?Сначала моделируйте таблицы, затем протестируйте на реальных данных перед созданием экранов. Если вы не можете легко ответить на типичные вопросы вроде «сделки по стадиям» или «просроченные задачи», исправьте схему, пока она ещё небольшая.
21 янв. 2026 г.
1 мин
20 янв. 2026 г.1 мин
20 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
