Два бизнеса одного владельца можно вести в одной CRM, если разделять не базу, а доступ: клиент и его история общие, а заказы, проекты и воронки у каждого направления свои. Так устроена CRM для SHUMI — бренда женской одежды и креативного агентства SHUMI Agency, которую мы собрали с нуля за две недели.
Коротко
SHUMI — бренд женской одежды из России: 16 лет на рынке и место в ТОП-100 брендов женской одежды на Wildberries. Рядом с ним работает SHUMI Agency — креативное агентство того же владельца.
У двух бизнесов разная природа. Бренд ведёт заказы, производство и выдачу, агентство — проекты, клиентов и менеджеров. У каждого свои клиенты, заказы и сотрудники, но владелец один, и часть клиентов у двух бизнесов общая. Поэтому работать им нужно в одной операционной среде, а не в двух параллельных.
Мы свели оба бизнеса в одну систему. От старта до запуска прошло две недели.
До проекта у бренда и агентства всё шло параллельно, и информация ходила между людьми, а не через систему. Выглядело это так.
Такая схема держится на памяти сотрудников. Пока заказов немного, это незаметно. Когда их становится больше, статус нужно искать в переписке, а у клиента, который обращался и в бренд, и в агентство, нет единой истории.
Ошибка Закрывать такую ситуацию отдельной программой для каждого бизнеса. У SHUMI задача звучала иначе: нужна была не ещё одна программа, а одна система для двух бизнесов.
Задачу сформулировали тремя требованиями, и каждое можно проверить на готовой системе, а не на словах.
Такой список полезно составить до выбора инструмента. Он отвечает на три вопроса: что в компании общее, что разделено и куда приходит новое обращение. Если ответа на них нет, разработка превращается в бесконечные уточнения.
Мы построили CRM с нуля под процессы SHUMI: это не настройка готового сервиса, а операционная среда, собранная под то, как на самом деле работают бренд и агентство. В ней есть роли, единая база клиентов двух бизнесов и воронка заказа от касания до выдачи.
Когда в одну систему нужно уложить два разных процесса, готовый шаблон приходится подгонять сразу под оба. В статье про кастомную CRM этот случай назван среди признаков, что компания упёрлась в платформу: второе направление бизнеса в систему не помещается, и для него заводят отдельный аккаунт или вторую программу. Там же разобрано, когда готовой CRM достаточно и разработка только отодвинет порядок в продажах.
Совет Сначала опишите процессы, потом выбирайте инструмент. Если у вас одна-две воронки, стандартные роли и типовые документы, хватит настройки готовой платформы. Если направления живут по разным правилам, как у SHUMI, считайте разработку.
В основе два потока и одна система: у каждого бизнеса своя воронка и свои роли, а база клиентов общая. Разложено это так.
| Что сравниваем | SHUMI — бренд одежды | SHUMI Agency — агентство |
|---|---|---|
| Что ведут в системе | Заказы, производство, выдача | Проекты, клиенты, менеджеры |
| Какой поток | Свой поток клиентов и свои роли сотрудников | Свой поток заявок и своя воронка |
| Кто что видит | Сотрудник бренда видит заказы бренда | Менеджер агентства видит свои проекты |
| Что общее | Единая база клиентов и единая операционная среда | Единая база клиентов и единая операционная среда |
Права разделены по ролям: у сотрудников бренда и у менеджеров агентства они отдельные. Сотрудник бренда видит заказы бренда, менеджер агентства — свои проекты, а всё сразу видит только руководитель.
Для такой схемы надёжнее описывать доступ как сочетание роли и направления бизнеса, а не раздавать права по должностям. Как разграничивать права, вести журнал действий и защищать базу, разобрано в статье про права доступа в CRM.
Клиенты двух бизнесов собраны в единой базе: клиент виден в обоих бизнесах, и его история не теряется. Вместо двух разрозненных баз появилась единая карточка клиента.
Для владельца это ответ на простые вопросы: кто из клиентов связан сразу с обоими бизнесами и что с ним уже обсуждали. Раньше, чтобы это выяснить, пришлось бы сверять две базы вручную.
Каждый заказ идёт по своему пути — от касания до выдачи. Статусы теперь живут в системе, а не пересылаются скриншотами. Как выстроить этапы воронки, считать конверсию и не повторять типичные ошибки, разобрано в статье про воронку продаж в CRM.
Мы сделали для SHUMI новый сайт и связали его с CRM: каждая заявка сразу падает в нужную воронку, без ручного переноса и потерянных лидов.
Это замыкает схему. Если сайт отправляет обращения в почту или чат, внутри компании может быть сколько угодно хорошая система, но вход в неё остаётся ручным, и именно на входе заявки теряются. Здесь заявка с сайта и обращение из мессенджера попадают в одно и то же место: в воронку нужного бизнеса.
Какие каналы и системы обычно подключают к CRM и как проверять обмен данными, разобрано в статье про интеграции CRM.
Главный результат — одна операционная среда для двух бизнесов вместо скриншотов и чатов. Продажи SHUMI выросли в 5 раз.
В работе команды поменялись четыре вещи.
Важно Две недели — срок этого проекта. Для другого он складывается из числа процессов, ролей и интеграций, и называть его до разбора задачи мы не беремся.
Одна общая CRM нужна, когда у направлений общие клиенты или когда владельцу нужна цельная картина по всей группе; отдельные системы оправданы, когда пересечений нет. Решают не размер компании и не число сотрудников, а то, что связывает бизнесы.
| Ситуация | Что выбрать | Почему |
|---|---|---|
| Клиенты двух направлений пересекаются | Одна CRM | Единая карточка клиента хранит историю общения в обоих бизнесах, и её не нужно собирать вручную |
| Владельцу нужна картина по всей группе | Одна CRM | Руководитель видит все направления в одной системе, а не сводит отчёты из нескольких программ |
| Сотрудники должны видеть только своё направление | Одна CRM с ролями | Права по ролям закрывают чужие данные, отдельная система для этого не нужна |
| Направления не связаны ни клиентами, ни людьми, ни отчётностью | Две отдельные системы | Общая база ничего не даст, а настройка только усложнится |
Если сомневаетесь, начните с первой строки таблицы: общие клиенты — самый сильный довод в пользу единой системы. У SHUMI это тот самый случай: клиенты двух бизнесов были, а увидеть их в одной базе было нельзя.
Схема из кейса подходит владельцу, у которого несколько направлений: производство и услуги, магазин и сервис, два юридических лица с общими клиентами. Начинать стоит не с выбора программы, а с ответов на несколько вопросов.
Отдельно стоит посмотреть на места, где такие проекты обычно ломаются.
Мы начинаем с карты потоков: какие есть направления, кто с ними работает, куда приходят обращения и что должно быть общим. Из неё получаются роли, воронки и структура базы, а не наоборот. Затем строим систему под эти процессы и связываем с ней сайт, чтобы заявка попадала в воронку без ручного переноса, как в кейсе SHUMI.
Ориентиры по бюджету — на странице услуги CRM: собственная CRM под ваши процессы стоит от 12 000 $, внедрение на готовой платформе — от 3 000 $. Какой вариант нужен вам, видно после разбора процессов.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Собственная CRM под процессы компании, как у SHUMI, стоит от 12 000 $. Если процессы стандартные и хватит готовой платформы, внедрение начинается от 3 000 $. Обе цены указаны на странице услуги CRM; итог зависит от числа процессов, ролей и интеграций.
Нет: доступ разделён по ролям. Сотрудник бренда видит заказы бренда, менеджер агентства — свои проекты, а всё сразу видит только руководитель.
У SHUMI бизнесы тоже разные по природе: бренд ведёт заказы, производство и выдачу, агентство — проекты, клиентов и менеджеров. Поэтому у каждого свои роли и воронка, а общими остаются база клиентов и операционная среда.
Каждое обращение, с сайта или из мессенджера, сразу попадает в нужную воронку. У SHUMI новый сайт связан с CRM, поэтому заявки не переносят вручную и они не теряются.
У SHUMI от старта до запуска системы прошло две недели. Для другого проекта срок складывается из числа процессов, ролей и интеграций, поэтому его называют после разбора задачи, а не заранее.
Когда у вас одна-две воронки, стандартные роли и типовые документы. Тогда проще настроить готовую платформу: внедрение начинается от 3 000 $, а своя разработка — от 12 000 $. Если направления живут по разным правилам, как у SHUMI, считайте разработку.
С ответов на вопросы из чек-листа выше: какие данные общие, кто что видит и через какие каналы приходят обращения. Затем описывают путь заказа или проекта в каждом бизнесе — от первого касания до завершения.