Несколько брендов в одной CRM: от чьего имени отвечает агент

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

Бренд в CRM — это набор связанных решений: источник интереса, коммерческий отправитель, допустимый ассортимент, документы, номер телефона и подпись. Бренд не равен юрлицу. Перед первым ответом сотрудник проверяет основание: откуда пришёл клиент и что ему уже обещали. Если основание не найдено, профиль остаётся пустым и требует решения, а не подставляется по привычке.

Условная сцена: в CRM одна карточка клиента, два бренда и общий номер телефона. Клиент пришёл по рекламе бренда «А», но менеджер отвечает из шаблона бренда «Б». Формально всё работает: сообщение уходит, сделка создаётся. Вопрос в том, от чьего имени прозвучало обещание и кто его подтвердил.

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

Клиент пришёл по рекламе бренда «А», а отвечает менеджер бренда «Б»

Условный эпизод: человек заполняет форму на сайте бренда «А», указывает интерес к услуге и оставляет телефон. Заявка попадает в общую очередь, потому что продажи ведёт одна команда. Первым освобождается менеджер, у которого активен профиль бренда «Б». Он видит имя, телефон и текст заявки, но не видит, что обещал сайт «А». В ответе появляется приветствие от «Б», затем уточняющий вопрос и подпись с другим названием. Клиент замечает несоответствие раньше, чем менеджер открывает источник.

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

Если бренды разные, первый ответ должен явно снимать неопределённость. Не универсальное «добрый день, компания», а понятное представление: кто отвечает и почему разговор продолжается от этого имени. Формулировку утверждает уполномоченный сотрудник по внутренним правилам; здесь важно не юридическое заклинание, а отсутствие подмены. Клиент не должен догадываться, что бренд «А» и бренд «Б» — это одна команда, если компания не решила сообщать это в таком виде.

На странице агентской CRM «Цифра» можно посмотреть опубликованные возможности продукта и формат обсуждения задачи «разделить бренды в одном процессе». Описанное здесь — проектные требования к настройке и проверке, а не автоматически доступные функции 404ai; наличие конкретных интеграций, шаблонов и правил маршрутизации выясняют до запуска.

Бренд, юрлицо и коммерческий отправитель — три разные записи

Смешивать бренд с юрлицом удобно до первого серьёзного вопроса. Один юридический субъект может вести несколько брендов, один бренд может обслуживаться разными юрлицами, а коммерческий отправитель вообще может быть командой или сервисным центром. Если CRM хранит только название организации, то в письме появится юридическое имя, в звонке — привычное клиенту название, а в документах — третья формулировка. Формально каждая запись верна, вместе они создают путаницу.

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

Практический признак порядка: в карточке клиента видно, какой профиль бренда активен сейчас и на каком основании. Если основание не найдено, система не подставляет «ближайший» бренд, а оставляет поле пустым и требует решения сотрудника. Пустое поле честнее красивой ошибки. Оно задерживает один ответ, зато не создаёт обещание от имени, которое компания не собиралась использовать.

Рабочий объект «профиль бренда» и поля, без которых ответ не собрать

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

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

Общий телефон: очередь не должна решать бренд за клиента

Условный эпизод: номер принадлежит сервисной команде, которая принимает обращения по двум брендам. Клиент звонит и говорит: «Я по поводу заявки». Оператор видит входящий номер, но не видит, какой бренд упомянут. Если очередь автоматически подставляет бренд по номеру, разговор начинается с предположения. Если не подставляет, оператор обязан уточнить. Второй вариант скучнее, но честнее.

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

Пересланное письмо: первоначальный адресат важнее последнего отправителя

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

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

Проверка перед ответом: в карточке видно, что основание — пересланное письмо, а не текущий входящий адрес. Если основание не найдено, сотрудник не отвечает от имени первого попавшегося бренда. Он уточняет у клиента или у ответственного за профиль. Задержка здесь меньше, чем стоимость неверного обещания.

Один артикул под разными именами: сопоставление до предложения

Условный эпизод: один и тот же товар продаётся под двумя названиями. У бренда «А» он называется «Комплект базовый», у бренда «Б» — «Набор стартовый». Внутренний код один, но сотрудник видит разные карточки и может предложить не то название. Клиент получает документ с формулировкой, которую не видел в рекламе. Формально товар тот же, но обещание другое.

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

Внешний ориентир на разделение продукта и его представления — Microsoft: устройство каталога товаров. Этот материал полезен как описание общей идеи каталога, но он не доказывает наличие таких функций в 404ai и не заменяет проверку вашего контура.

Миграция сделки между брендами: меняется отправитель, не основание

Условный эпизод: клиент начал разговор с брендом «А», но компания решает передать сделку команде бренда «Б». Причина может быть рабочей: другой профиль компетенций, иная загрузка или решение уполномоченного сотрудника. Проблема не в самой передаче, а в том, что карточка меняет название, а история обещаний остаётся в старой переписке. Новый менеджер видит только последнее сообщение и отвечает так, будто предыдущего разговора не было.

При миграции нужно сохранять основание: старый бренд, новый бренд, причину, кто подтвердил переход и что клиенту уже сказали. Это не бюрократическая карточка ради карточки, а способ не потерять адресата предложения. Если клиенту обещали условия от «А», ответ от «Б» должен явно объяснять, что изменилось и на каком основании. Формулировку проверяет уполномоченный сотрудник по применимым документам.

Для связи заказа и строки полезно смотреть на порядок создания и обработки заказа в Microsoft: создание и обработка заказа. Это внешний ориентир, а не подтверждение функций в вашем контуре. Главное правило проще: миграция меняет активный профиль, но не стирает источник и историю подтверждений.

Чужой шаблон подписи: почему подпись — часть бренда, а не украшение

Условный эпизод: сотрудник обслуживает два бренда и держит один универсальный шаблон подписи. В нём название компании, общий телефон и фраза «будем рады помочь». При отправке от бренда «А» шаблон выглядит почти нормально, при отправке от «Б» — вводит в заблуждение. Клиент сохраняет письмо, а потом предъявляет его как обещание другого бренда. Спор идёт не о тексте, а о том, кто говорил.

Подпись — часть коммерческого профиля. В ней должны быть название, контакты и, если нужно, ссылка на применимые документы. Если сотрудник работает с двумя брендами, у него два подписанных профиля, а не один универсальный. Перед отправкой интерфейс показывает активный профиль и подпись. Смена профиля не должна происходить по домену получателя: получатель может быть общим для двух брендов.

Отдельная трудность — пересланные шаблоны. Сотрудник копирует удачное письмо коллеги, но забывает заменить подпись. Поэтому шаблон хранится не как свободный текст, а как запись, привязанная к профилю. Если сотрудник пытается отправить шаблон бренда «А» из профиля «Б», интерфейс показывает расхождение. Решение остаётся за сотрудником, но расхождение не остаётся незамеченным.

Права сотрудника: видимость бренда и подтверждение действия

Сотрудник может видеть оба бренда и при этом не иметь права говорить от имени любого из них в любой момент. Видимость и полномочие — разные вещи. В проектной модели полезно разделять: кто видит профиль, кто может подготовить ответ, кто подтверждает смену этапа, суммы или ответственного. Агентская CRM может подготовить карточку и сообщение, но изменение этапа, суммы или ответственного согласует сотрудник. Это не недоверие к агенту, а разделение ответственности за обещание.

Для проектирования прав полезен внешний ориентир — Microsoft: роли безопасности и полномочия. Он описывает общий подход к ролям и полномочиям, но не доказывает наличие готовой модели прав в 404ai. В вашем контуре нужно отдельно проверить, как ограничивается доступ к профилю бренда и кто утверждает изменения.

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

Интерфейс ответа: три проверки до отправки

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

Полезно показывать не абстрактный статус «бренд подтверждён», а конкретные значения: домен отправителя, номер телефона, имя подписи, версию шаблона. Сотрудник быстрее замечает несоответствие, когда видит телефон бренда «А» рядом с подписью бренда «Б». Если интерфейс скрывает детали за словом «профиль», ошибка возвращается.

Трудные исключения: совместная акция, суббренд и лид без источника

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

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

Отдельный случай — лид без источника. Клиент позвонил, не назвал бренд, не оставил заявку. Сотрудник фиксирует неопределённость и задаёт уточняющий вопрос. Если ответа нет, разговор продолжается от общего сервисного имени, если такое имя утверждено. Если нет — задача ждёт решения. Это медленнее, чем назначить бренд по привычке, но не создаёт ложного адресата.

Тесты согласованности: что проверить до запуска

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

После тестов полезно провести разбор одного ответа: открыть источник, профиль, подпись, товарное название и подтверждение. Если хотя бы одно звено не связано с остальными, схема ещё не готова. Это скучная проверка, но она дешевле, чем объяснение клиенту, почему письмо пришло от одного бренда, а счёт — от другого.

Практикум на другом примере: два бренда в одном чате

Условный пример: на общем сайте открыт чат, виджет оформлен нейтрально, а оператор отвечает сразу по двум направлениям. Клиент пишет: «Хочу уточнить условия по прошлому обращению». В истории чата нет названия бренда, но есть номер заявки. Оператор открывает заявку и видит, что она создана по странице бренда «А». Дальше он не выбирает бренд по виджету, а использует основание заявки.

Шаги практикума: зафиксировать источник, проверить активный профиль, открыть товарное название, выбрать подпись, прочитать ответ целиком. Если на любом шаге появляется второе название, ответ останавливается. Затем сотрудник либо исправляет профиль, либо уточняет у клиента, либо передаёт задачу ответственному за бренд. Результат практикума — не красивый ответ, а отсутствие подмены.

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

Что проверить первым шагом

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

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

Соседний вопрос разобран отдельно: Группа компаний в CRM: клиент один, юрлиц несколько. Здесь основной предмет — разделение коммерческого отправителя, знаний и оформления при общей платформе; не структура группы юрлиц.