Модель данных без технических слов: как описать карточки клиентов, сделок и заявок и их связи, чтобы команде было ясно с первого раза.
Почти в любой компании есть «карточки»: клиент, сделка, заявка, обращение, счет. Кажется, что всем и так понятно, что это значит. Но как только людей становится больше двух, это «понятно» начинает расползаться.
Один менеджер записывает клиента как компанию, другой как человека. Кто-то заводит новую карточку на каждую заявку, а кто-то хранит все в одной сделке. Поддержка смотрит на «заявку» как на проблему, продажи - как на шанс заработать. В итоге у каждого своя правда, и спор обычно всплывает в самый неудобный момент: когда нужно быстро принять решение или показать цифры.
Проблемы проявляются не сразу, а в работе:
Кому это мешает? Владельцу и руководителю - потому что сложно ответить на вопрос «сколько мы заработаем и почему». Продажам - потому что неудобно вести воронку и контролировать шаги. Поддержке - потому что трудно понять историю клиента. Аналитике - потому что цифры приходится «склеивать руками». Разработке - потому что каждое уточнение превращается в переделку.
Отсюда и задача: описать модель данных без технических слов так, чтобы на вопрос «где правда?» все давали один и тот же ответ. Не «примерно», а одинаково: в переписке, в отчетах и в системе.
Карточка - это папка с информацией про один конкретный объект, с которым вы работаете каждый день. Внутри основные факты (имя, контакты, сумма, срок), история действий и текущее состояние. Смысл карточки простой: команда должна находить в ней один и тот же ответ на вопрос «что это такое и что делать дальше?».
Чтобы понять, что считать отдельной карточкой, задайте себе тест: это «одно» или «много»? Если у объекта может быть несколько вариантов одновременно, чаще всего это разные карточки. Например, у одного клиента может быть несколько сделок. Значит «клиент» и «сделка» обычно живут отдельно.
Хорошая карточка узнается по трем признакам:
Важно не путать карточку с документом и событием. Документ - это вложение или артефакт (договор, счет, КП). Он может храниться в карточке, но сам по себе не всегда «живет» как объект с этапами. Событие - это факт действия во времени (звонок, встреча, письмо). Оно добавляет историю, но не заменяет карточку.
Пример. В отдел продаж пришло сообщение: «Хочу кондиционер в офис». Это может быть карточка «заявка» (обращение). Дальше появляется карточка «сделка» (конкретная продажа с суммой и этапами). А карточка «клиент» остается той же, даже если через месяц он откроет вторую сделку.
Чтобы собрать модель данных без технических слов, начните с трех карточек. Они помогают меньше спорить о терминах и одинаково понимать, что именно вы учитываете и зачем.
Клиент - это тот, кому вы продаете. Сразу договоритесь, клиент у вас - человек, компания или оба варианта. Частая путаница: менеджер записывает ООО как клиента, а бухгалтерии важен конкретный плательщик. Практичный подход: клиентом считать компанию, а внутри хранить контакты людей (ЛПР, бухгалтер, получатель). Если вы продаете физлицам, тогда клиентом будет человек, а поле «компания» может быть пустым.
Сделка - это договоренность о продаже, а не факт денег. Она отвечает на вопрос: «что именно мы обещали продать, на каких условиях, и на каком шаге это сейчас». Оплата может быть частичной, отложенной или не случиться вовсе, но сделка все равно нужна, чтобы видеть воронку и причины потерь.
Заявка - это входящий сигнал об интересе. В одной команде это форма на сайте, в другой - звонок, в третьей - сообщение в чате. Задача заявки - зафиксировать источник и повод обращения, чтобы не потерять контакт и быстро превратить сигнал в понятную следующую единицу работы (обычно в сделку).
Минимальный набор полей держите коротким:
Обязательными делайте поля, без которых карточка бесполезна. У клиента должен быть хотя бы один способ связи. У сделки - к какому клиенту она относится и на какой стадии. У заявки - откуда пришла и как с ней связаться. Если пришло сообщение «Хочу консультацию», но без контакта и источника, через день вы уже не вспомните, где искать человека и какой канал сработал.
Связь между карточками - это ответ на вопрос «к чему это относится?». Если у вас есть карточка «Сделка», важно сразу понимать, к какому клиенту она относится. Если есть «Заявка», хочется видеть, во что она превратилась: в сделку, в отказ или в повторный контакт позже.
Иногда встречается связь «один к одному». Это когда у объекта есть ровно одна «пара». Например, у клиента могут быть отдельные паспортные данные (если это нужно по процессу). Тогда у одного клиента - один набор паспортных данных, и эти данные не должны «переезжать» к другому клиенту.
Чаще в продажах работает «один ко многим». Один клиент может сделать много заявок, у него может быть много сделок, и даже несколько активных одновременно. Простой тест: можете ли вы представить клиента, который покупал у вас три раза? Если да, то связь «клиент -> много сделок» должна быть нормой.
Есть и «многие ко многим». Это когда у одной сделки может быть несколько услуг или товаров, и одна и та же услуга встречается в разных сделках. Например, вы продаете пакет: «аудит + настройка + поддержка». Тогда сделка относится сразу к нескольким услугам, а услуга относится ко многим сделкам.
Связь стоит делать обязательной, если без нее карточка теряет смысл. Сделка без клиента почти всегда бесполезна: непонятно, кому звонить, куда выставлять счет, как считать повторные покупки.
А вот пустая связь иногда нормальна. Заявка может прийти без понятного клиента: только телефон, только ник в мессенджере, или контакт еще не проверен. В таком случае заявка живет «сама по себе», пока вы не поймете, это новый клиент или уже существующий. Главное - заранее договориться, в какой момент вы обязаны «прикрепить» ее к клиенту, чтобы дальше не плодить дубликаты и не терять историю общения.
Статус - это не украшение карточки, а короткий ответ на два вопроса: что сейчас происходит и кто следующий отвечает. Если по статусу нельзя понять действие (позвонить, проверить оплату, назначить встречу), он бесполезен.
Лучше 5-7 статусов, которыми команда реально пользуется каждый день, чем 20, из которых половина забыта. Пример для сделки в продаже услуг:
Чтобы статусы работали, договоритесь о правилах переходов. Это условия в стиле: «мы не двигаем карточку дальше, пока не сделано X». Тогда данные не превращаются в кашу, а этапы не рисуются задним числом.
Примеры правил, которые обычно помогают:
Отдельно подумайте про историю изменений. Полезно знать не только текущий статус, но и когда он менялся, кто менял, и что именно поменяли. Это помогает разбирать провалы в процессе: например, «зависло на ожидании решения» не потому что клиент молчит, а потому что менеджер не поставил дату следующего контакта. Если вы делаете прототип процесса в TakProsto, удобно сохранять версии проекта через снимки и откат, чтобы не потерять рабочую логику при правках.
И не смешивайте статусы разных карточек. У заявки статусы про обработку обращения («получена», «уточняем», «передано в продажи»). У сделки - про переговоры и деньги. Одна заявка может породить несколько сделок, и это нормально: статус заявки может быть «закрыта», а одна из сделок по этому клиенту еще «в работе».
За час можно договориться о карточках так, чтобы продажи, поддержка и бухгалтерия говорили на одном языке. Нужна привязка к тому, как вы реально работаете.
1) Сформулируйте цель процесса одним предложением. Например: «Не терять обращения, доводить до оплаты и понимать, на каком шаге зависло».
2) Перечислите карточки, которые реально нужны. Обычно хватает 3-5. Пример для продаж: клиент, заявка, сделка, счет, задача. Если карточка не помогает принять решение или не нужна для контроля, ее можно не заводить.
3) Выпишите поля, по которым вы принимаете решения. Не «все, что можно заполнить», а то, что влияет на действия. Для заявки это могут быть: источник, продукт или услуга, срочность, бюджет «примерно», канал связи. Для сделки: сумма, дата плановой оплаты, ответственный. Для клиента: сегмент, город, реквизиты (если юрлицо).
4) Опишите связи одной фразой: кто к кому привязан. Говорите простыми предложениями: «Одна заявка относится к одному клиенту», «У клиента может быть несколько сделок», «У сделки может быть несколько счетов». Если есть спор, значит связь важная и ее надо зафиксировать.
5) Добавьте статусы и правила заполнения. Статусы показывают жизнь карточки: «новая», «в работе», «ожидаем ответ», «выиграно», «проиграно». Правила делают данные полезными: «Сумма сделки обязательна перед отправкой счета», «Причина отказа обязательна при проигрыше».
6) Проверьте на трех типовых ситуациях. Возьмите три коротких сценария и проверьте, хватает ли карточек, полей и связей:
Если в сценарии появляются вопросы вроде «где это хранить?» или «как понять, к чему относится?», значит вы нашли недостающую карточку, поле или правило. Результат часа работы - согласованный минимум, который потом легко перенести в любую систему.
Представьте компанию, которая продает услугу: настройку рекламы. Заявки приходят с сайта (форма) и по телефону. Руководителю важно видеть простую картину: сколько новых обращений было, сколько дошло до оплаты, и кто из менеджеров что сделал.
Сначала появляется заявка. В ней достаточно держать минимум: источник (сайт или телефон), что попросили, контакты, удобное время связи и комментарий менеджера. Дальше главный вопрос: это новый клиент или существующий? Если человек уже есть в базе, заявку прикрепляют к его карточке. Если нет - создают карточку клиента.
С дублями лучше договориться сразу. Если совпал телефон или email, не заводим нового клиента. Если есть сомнение (например, общий телефон компании), помечаем как «нужно уточнить» и даем ответственному 1-2 минуты на проверку перед звонком.
Когда заявка «созрела», она превращается в сделку. Критерий простой: есть понятный интерес и следующий шаг (назначен созвон, отправлено коммерческое, согласована цена). Решает обычно менеджер, а в спорных случаях - руководитель. Важно, чтобы сделка была одна на одну конкретную продажу, а не «вообще работа с клиентом».
Если у клиента несколько заявок одновременно (например, «реклама» и «сайт»), не смешивайте. Нормальная структура такая: один клиент, несколько заявок (каждая со своим источником и историей), и несколько сделок, если это разные продажи.
Оплату фиксируйте отдельным фактом: сумма, дата, способ, номер счета или чека. После оплаты сделка переходит в «оплачено/выполнено» по вашему правилу: кто-то закрывает после поступления денег, кто-то после оказания услуги. Главное - выбрать один вариант, иначе отчеты будут спорить сами с собой.
Повторная покупка выглядит так же: новый запрос создает новую заявку, она привязывается к тому же клиенту, и из нее появляется новая сделка. Тогда вы видите и конверсию по заявкам, и выручку по сделкам, и сколько раз клиент возвращался.
Карточки редко живут сами по себе. Вокруг них всегда есть события: комментарии, звонки, письма, встречи. Чтобы не искать историю по чатам и почте, заранее договоритесь, где это хранится.
Простое правило: событие записывается туда, где оно влияет на следующий шаг. Звонок про уточнение потребностей относится к сделке, а запрос на смену реквизитов - к клиенту. Если письмо про конкретную заявку на услугу, логичнее привязать его к заявке, чтобы исполнителям не пришлось открывать сделку и угадывать контекст.
С ответственностью тоже нужна ясность. В каждой карточке должен быть один владелец, который отвечает за результат, и при необходимости несколько ролей (например, менеджер, исполнитель, бухгалтер). Так не бывает ситуации, когда «все отвечают», а по факту - никто.
Чтобы команда понимала поля одинаково, заведите короткий словарь и не плодите варианты. Достаточно зафиксировать:
Источник особенно важен: без единого списка быстро появляется 30 вариантов вроде «сайт», «сайтик», «лендинг», «форма».
Договоритесь, какие поля можно править, а какие только дополнять. Например:
Если вы описываете процесс в TakProsto, удобно начать в planning mode: сначала словарь и правила, затем прототип карточек и проверки на обязательные поля.
Самая частая проблема: команда хочет «навести порядок», но делает карточки как анкету на 200 вопросов. В итоге карточки выглядят солидно, а живых данных нет.
Первая ловушка - добавить слишком много полей «на будущее». Начните с 5-10 полей, без которых вы реально не можете работать каждый день. Остальное добавляйте после пары недель практики, когда станет ясно, что именно мешает.
Вторая ошибка - смешать «заявку» и «сделку» в одну карточку. Заявка - это сигнал интереса (часто еще без цены и сроков), а сделка - конкретная попытка продать с этапами воронки. Если держать их вместе, пропадает момент «когда заявка стала сделкой», и воронка превращается в кашу.
Третья боль - дубли клиентов. Один и тот же человек может прийти с разных каналов, и без правил он станет «десятью разными клиентами». Договоритесь, что считается уникальным: телефон, email или ИНН, и кто имеет право объединять записи.
Четвертая - статусы, которые не совпадают с реальной работой. Когда статус «В работе» означает все подряд, люди начинают писать в комментариях «позвонил, жду, отправил КП», и отчеты становятся бесполезны. Сделайте статусы отражением действий, а не настроения.
Пятая - связи «наоборот». Например, когда сделка «держит» клиента как поле текста, а не как связанную карточку, потом сложно понять выручку по клиенту и повторные покупки. Простое правило: клиент один, а заявок и сделок у него может быть много.
Еще одна мелочь, которая ломает порядок, - разные форматы в полях. Суммы без валюты, даты «как кому удобно», телефоны с пробелами и без кода страны. Зафиксируйте формат сразу:
Если вы набрасываете прототип в TakProsto, удобно сначала утвердить эти правила в planning mode, а потом переносить в рабочие карточки. Так быстрее видно, что лишнее, и меньше переделок.
Перед внедрением CRM, таблицы или нового сервиса важно договориться о базовых вещах. Иначе вы купите инструмент, а внутри останется путаница: люди будут по-разному понимать, что такое «заявка», когда она становится «сделкой», и почему карточки дублируются.
Проверьте, что по каждой карточке есть определение в 1-2 строках. Например: «Заявка - это первое обращение, где мы еще не подтвердили потребность» и «Сделка - это подтвержденная возможность продажи с понятной суммой и сроком». Эти короткие фразы экономят часы споров.
Дальше выберите минимальный набор обязательных полей. Не делайте 30 полей «на будущее». Хороший тест: сможете ли вы принять решение по карточке, если заполнены только обязательные поля? Обычно хватает 5-8 штук: кто, что хочет, откуда пришел, ответственный, следующий шаг, дата.
Связи проговорите обычными фразами, без схем и терминов:
Статусы сделайте короткими: 5-7 на карточку обычно достаточно. Важнее не список, а правила переходов: кто переводит, по какому событию, что должно быть заполнено до перехода. Например: «Сделка не может стать "Выставлен счет", если не указана сумма и реквизиты».
Отдельно решите вопрос дублей. Что считается дублем: одинаковый телефон, email, ИНН, название компании? Кто разбирает конфликт и как быстро? Если это не определить заранее, дубли будут копиться и ломать отчеты.
Финальная проверка - прогоните модель на трех реальных кейсах команды. Возьмите свежие примеры: «заявка с сайта», «повторный клиент», «долгая сделка с паузой». Если на этих кейсах вы каждый раз понимаете, какую карточку создать и куда ее перевести, значит можно внедрять.
Когда вы уже договорились о карточках и связях, важно закрепить это так, чтобы команда не спорила заново через неделю. Обычно хватает одного документа на 1-2 страницы и одного человека, который отвечает за изменения.
Назначьте владельца процесса: он собирает правки, решает спорные места и следит, чтобы новая версия дошла до всех. Тогда модель данных без технических слов превращается в рабочее правило.
Дальше сделайте маленький прототип. Не пытайтесь сразу описать весь мир: возьмите 2-3 ключевые карточки (например, «Заявка», «Сделка», «Клиент») и одну-две связи между ними, которые дают пользу уже сегодня.
В первый прототип обычно достаточно включить: минимальные поля (телефон, источник, сумма, ответственный), 3-5 статусов на каждую карточку и одно правило, которое предотвращает хаос (например, сделка не закрывается без суммы и даты оплаты).
Проверьте прототип на реальных данных хотя бы неделю. Менеджеры заносят входящие заявки, превращают часть из них в сделки и фиксируют оплаты. По итогам недели обычно видно, какие поля лишние, каких статусов не хватает, и где люди обходят правила, потому что так быстрее.
Если хотите быстро превратить согласованные карточки в работающий инструмент, это можно собрать в TakProsto (takprosto.ai): описать сущности и связи простым языком в planning mode, а затем сделать веб или мобильное приложение и при необходимости выгрузить исходники.
После проверки решите, что автоматизировать первым, чтобы был заметный эффект за 1-2 недели: создание карточек из обращений, быстрые фильтры (по статусу, ответственному, сроку) и простые отчеты (конверсия, причины отказов, сумма оплат). Так вы двигаетесь небольшими шагами: описали, проверили, поправили, автоматизировали. Каждый шаг дает пользу, а не просто «красивую схему».
Начните с коротких определений в 1–2 фразы для каждой карточки и закрепите их как правило команды. Дальше проверьте определения на реальных кейсах: «новое обращение», «повторная покупка», «две продажи одному клиенту одновременно». Если в кейсе возникает вопрос «куда это записать», значит определение или границы карточек еще не договорены.
Карточка нужна, если у объекта есть владелец, понятный жизненный цикл и решения, которые вы по нему принимаете. Если это просто файл (договор, счет, КП), чаще всего ему достаточно быть вложением в карточку. Если это действие во времени (звонок, встреча, письмо), его лучше фиксировать как событие в истории, а не как отдельную «сущность», иначе вы получите лишние объекты и путаницу.
Договоритесь о главном: клиент — это компания, человек или оба варианта. Для B2B обычно удобно считать клиентом компанию, а людей хранить как контакты внутри (ЛПР, бухгалтер, получатель). Для B2C клиентом чаще является человек, а поле «компания» может оставаться пустым. Важно выбрать один стандарт и не менять его по отделам, иначе дубли и отчеты начнут расходиться.
Заявка — это входящий сигнал интереса, который важно не потерять и быстро обработать. Сделка — это уже конкретная попытка продажи с этапами, условиями и суммой (пусть даже примерной). Практичное правило: если появился понятный следующий шаг по продаже (созвон назначен, КП отправлено, цена обсуждается), это повод заводить сделку из заявки.
Сделку почти всегда делайте связанной с клиентом, иначе вы теряете смысл: кому продавали, кто покупал раньше, как считать повторные продажи. У заявки связь с клиентом может быть временно пустой, если пришел только ник или телефон и вы еще не уверены, новый это человек или существующий. Главное — заранее договориться, в какой момент привязка становится обязательной, например до перевода заявки в «передано в продажи» или до создания сделки.
Задайте единый признак уникальности и следуйте ему всегда. Чаще всего это телефон или email для физлиц, а для юрлиц — ИНН плюс название. Дополнительно определите, кто имеет право объединять записи и как быстро это нужно делать, иначе дубли будут накапливаться и ломать историю коммуникаций и аналитику.
Держите 5–7 статусов на карточку, которые прямо подсказывают действие и ответственность. Каждый переход подкрепляйте простым правилом заполнения: что должно быть указано, прежде чем двигаться дальше. Если статус не отвечает на вопрос «что делать сейчас и кто следующий», он будет жить только на бумаге и не поможет ни отчетам, ни управлению.
Начните с минимального набора обязательных полей, без которых карточка не работает в ежедневной практике. Для клиента это хотя бы один контакт и ответственный, для заявки — источник и способ связи, для сделки — клиент, стадия и сумма/валюта. Остальные поля добавляйте только после недели-двух реальной работы, когда станет понятно, чего именно не хватает для решений.
Оплату фиксируйте как отдельный факт с суммой, датой и способом, чтобы не путать «договорились» и «деньги пришли». Затем выберите единое правило закрытия сделки: закрываем по факту оплаты или по факту выполнения, но только один вариант для всей команды. Если смешивать, отчеты будут спорить между собой, а руководителю будет сложно понять реальную картину.
Зафиксируйте словарь терминов и правила в одном месте и назначьте владельца процесса, который утверждает изменения. В TakProsto это удобно делать через planning mode: сначала описать сущности, статусы и обязательные поля простым языком, а потом собрать прототип и проверить на реальных сценариях. Чтобы правки не ломали рабочую логику, используйте снимки и откат к стабильной версии.
