Кто отвечает за CRM в компании: обязанности руководителя, администратора и интегратора

Почему оплаченной лицензии и интегратора недостаточно

Маркетолог просит новое поле, руководитель продаж — ещё одну стадию, менеджеры — убрать обязательные значения. Интегратор получает три противоречивые заявки и спрашивает, какое правило правильное. Если в компании никто не уполномочен ответить, CRM постепенно отражает отдельные пожелания вместо общего порядка работы.

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

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

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

Какие решения должен принимать владелец CRM

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

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

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

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

Как разделить обязанности команды

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

Администратор CRM обслуживает настройки в пределах выданных полномочий, помогает пользователям и ведёт историю изменений. Интегратор проектирует и реализует техническое решение по согласованной задаче. Эти функции могут выполняться внешним специалистом или внутренней командой, но бизнес-правила всё равно должна утверждать компания.

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

Как составить короткую матрицу ответственности

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

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

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

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

Как собирать пожелания и определять приоритет

Для новой доработки требуйте описание рабочей ситуации. Кто сталкивается с проблемой, что делает сейчас, где возникает затруднение и какой результат нужен? Запрос «добавить пять полей» уже содержит предполагаемое решение, но ещё не объясняет задачу. Иногда нужные сведения есть в другой карточке или проблема возникает из-за старой инструкции.

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

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

Держите единый список задач. Личные сообщения разным разработчикам создают параллельные версии правил и скрытые расходы. В карточке задачи сохраняйте решение, основание, исполнителя и проверяющего. Отказ или перенос тоже стоит кратко объяснять, чтобы одно и то же пожелание не возвращалось каждый месяц без новых сведений.

Кто отвечает за качество клиентской базы

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

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

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

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

Как принимать изменения без спора о готовности

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

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

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

Почему владельцу CRM не обязательно иметь все технические права

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

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

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

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

Как организовать работу владельца CRM на практике

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

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

Через согласованный период проверьте, помогает ли распределение ролей. Интегратор получает единые требования? Менеджеры знают, куда сообщать о проблеме? Отчёты используют одинаковые определения? Уволившийся сотрудник не оставил за собой недоступные настройки? Ответы показывают, работает ли назначенная ответственность.

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