Через полгода после запуска CRM менеджеры снова ищут контакты клиентов в блокнотах: обновление сломало интеграцию с телефонией, а подрядчик, который внедрял систему, давно переключился на другой проект. Так выглядит компания, где забыли про обслуживание CRM системы: карточки есть, но звонки в них не попадают, сделки зависают на старых стадиях, а отдел продаж постепенно возвращается к привычным таблицам. Потеря доступа к истории переписки и истории звонков в такой момент бьёт сильнее всего: новый менеджер, который принял сделку, не видит, о чём клиент договаривался с предыдущим контактом, и начинает разговор заново.
Внедрение CRM: это запуск, а не финал. Дальше систему нужно обновлять, лечить после сбоев, донастраивать под новые процессы и объяснять новым сотрудникам, как ей пользоваться. Все эти задачи вместе и называются обслуживанием CRM системы, и именно от них зависит, будет ли инструмент работать через год так же, как в день запуска, или превратится в мёртвый груз, которым никто не пользуется. Руководителю это заметно не сразу: отчёты по воронке продолжают строиться, цифры в них просто перестают отражать реальность.
Обслуживание CRM системы складывается из нескольких повторяющихся задач: обновления, бэкапы, доработки, поддержка пользователей и контроль качества через SLA. У каждой задачи свой ритм, и каждую можно отдать подрядчику или закрыть силами штатного сотрудника.
Что входит в обслуживание CRM системы после внедрения
Когда систему только запустили, кажется, что основная работа сделана: воронки настроены, карточки заведены, менеджеры прошли обучение. На практике это только старт. Дальше система живёт своей жизнью: меняются тарифы у провайдера телефонии, появляются новые сотрудники, отдел продаж просит добавить поле или стадию, а очередное обновление платформы может без предупреждения отключить рабочий сценарий. Чем больше в компании интеграций и автоматических сценариев, тем быстрее один забытый момент превращается в цепочку сбоев, которую сложно отследить по одному симптому.
Если коротко вспомнить, что такое CRM система простыми словами, это не программа ради программы, а рабочий процесс компании, перенесённый в интерфейс. Процесс со временем меняется, и система обязана меняться вместе с ним.
- Обновления. Установка новых версий платформы, модулей и интеграций, проверка, что после обновления ничего не отвалилось.
- Бэкапы. Резервное копирование данных по расписанию и проверка, что восстановление из копии работает не только в теории.
- Доработки. Новые поля, стадии, автоматизации и интеграции по запросам отделов.
- Поддержка пользователей. Ответы на вопросы сотрудников, разбор ошибок, обучение новых менеджеров.
- Мониторинг интеграций. Проверка, что телефония, почта, мессенджеры и маркетплейсы передают данные в CRM без потерь.
- Администрирование прав доступа. Настройка ролей при изменении структуры отдела или штата.
Каждая из этих задач существует отдельно от остальных, но страдает ровно тогда, когда в компании нет ответственного, который ведёт её на регулярной основе, а не от случая к случаю.
Обновления и совместимость
У облачных и коробочных CRM разная логика обновлений. Облако обновляется само, на стороне серверов разработчика: пользователь ничего не нажимает и не скачивает, систему просто обновляют, а о новых функциях сообщают уведомлением или письмом. Коробочную версию администратор обновляет вручную: создаёт бэкап, проверяет совместимость версии PHP и сервера, устанавливает обновление и затем проверяет, что ключевые сценарии работают. В обоих случаях ответственный должен знать дату следующего релиза заранее, а не узнавать о нём из жалоб пользователей.
Проблема в том, что любое обновление способно задеть кастомные автоматизации: вебхуки, сценарии роботов, интеграции с сайтом или складом. Перед обновлением коробочной версии разумно проверить изменения на тестовом контуре, а не на рабочей базе. Для облачной версии такой возможности нет: отказаться от обновления или отложить его нельзя, оно приходит всем пользователям сразу. Поэтому задача обслуживания смещается в сторону мониторинга: после каждого крупного релиза провайдера стоит пройти по ключевым сценариям руками и убедиться, что заявки создаются, уведомления уходят, а отчёты считаются верно. Список таких сценариев стоит держать под рукой письменно, а не держать в голове одного администратора.
Бэкапы: кто отвечает за сохранность данных
У облачной CRM есть инфраструктурный бэкап на стороне провайдера, но он защищает от аварии на сервере, а не от ошибки пользователя. Если сотрудник массово удалил сделки через импорт или ошибочный фильтр, восстановить именно эти записи штатными средствами провайдера часто нельзя, либо это платная и небыстрая процедура. Поэтому компании, которые относятся к данным серьёзно, настраивают собственное резервное копирование: выгрузку базы по расписанию в отдельное хранилище. Особенно уязвимы ситуации, когда одна и та же учётная запись имеет доступ к массовым операциям и к удалению сделок без подтверждения.
- Резервная копия снимается по расписанию, а не только перед крупными изменениями.
- Копия хранится отдельно от рабочей базы, в другом сервисе или облаке.
- Восстановление из бэкапа хотя бы раз проверено на практике, а не только по инструкции.
- Перед миграцией, массовым импортом или сменой интеграции снимается внеплановая копия.
Доработки: как CRM меняется вместе с бизнесом
Отдел продаж вырос и завёл отдельную воронку для корпоративных клиентов. Маркетинг запустил рассылки и просит передавать статус письма в карточку. Склад перешёл на новую систему учёта, и нужна новая интеграция. Это уже не поддержка в узком смысле, а развитие: CRM достраивается новыми полями, стадиями, автоматизациями и связями с другими сервисами. Запросы редко приходят по одному: обычно сразу несколько отделов просят правки в одну неделю, и без приоритизации список задач растёт быстрее, чем его успевают закрывать.
Граница между поддержкой и доработкой размыта, и именно здесь чаще всего возникают споры с подрядчиком: что входит в оплаченные часы обслуживания, а что считается отдельным проектом. Разумная практика: зафиксировать в договоре перечень типовых мелких правок, новое поле, правка шаблона, настройка уведомления, которые входят в ежемесячный пакет, а крупные доработки, новую интеграцию, перестройку воронки, оценивать отдельно и заранее.
Поддержка пользователей
Самая недооценённая часть обслуживания CRM системы: ответить сотруднику, почему сделка не переходит на следующую стадию, или объяснить новому менеджеру, как создать карточку. Без этой линии поддержки сотрудники быстро находят обходные пути: заводят параллельные таблицы, ведут клиентов в мессенджере, игнорируют поля, которые и так никто не проверяет. Через несколько месяцев в CRM остаются только формальные записи, а реальная работа идёт мимо системы. Разница между компанией, где в CRM работают каждый день, и компанией, где её открывают для вида, часто сводится именно к скорости ответа на такие простые вопросы.
Типичные запросы, которые закрывает линия поддержки:
- Почему автоматизация не сработала или сработала не вовремя.
- Как изменить поле, шаблон письма или вид карточки.
- Почему звонок или заявка не попали в CRM.
- Как завести нового сотрудника и настроить ему права.
- Как выгрузить отчёт в понятном отделу виде.
SLA: как закрепить скорость и качество поддержки
SLA, соглашение об уровне обслуживания, переводит ожидания от «подрядчик поможет, если что» в конкретные сроки. Без него спор о том, нормально ли ждать ответ на критичную поломку два дня, решается на эмоциях, а не по договору.
Рабочий SLA описывает три вещи: сколько времени проходит до первой реакции на обращение, сколько времени занимает устранение проблемы в зависимости от её критичности, и сколько часов поддержки включено в месяц без дополнительной оплаты.
| Приоритет | Пример ситуации | Что обычно фиксируют в SLA |
|---|---|---|
| Критичный | CRM полностью недоступна, заявки не создаются | Реакция в течение часа, работа до устранения |
| Высокий | Не работает ключевая интеграция или автоматизация | Реакция в течение рабочего дня |
| Стандартный | Правки полей, шаблонов, отчётов | Решение по плановому циклу задач, обычно в течение недели |
Чем точнее приоритеты описаны в договоре, тем проще измерить, выполняет ли подрядчик свои обязательства. И тем нагляднее видно, как качество обслуживания влияет на деньги: если критичный сбой чинят сутки, пока отдел продаж не может создать ни одной сделки, это напрямую бьёт по показателям, которые разбирает статья об эффективности CRM системы и её ROI.
Подрядчик или штатный специалист: как выбрать
Выбор между подрядчиком и штатным сотрудником: это не вопрос «что лучше», а вопрос, что выгоднее при вашем объёме задач и числе пользователей CRM. Выбор также зависит от того, насколько критичны для бизнеса простои: если недоступность CRM на несколько часов не останавливает продажи, разница между вариантами ощущается меньше.
| Критерий | Подрядчик | Штатный специалист |
|---|---|---|
| Стоимость при небольшом объёме задач | Платите за фактические часы | Полная ставка независимо от загрузки |
| Скорость реакции на срочное | Ограничена условиями SLA | Обычно быстрее, человек рядом |
| Широта экспертизы | Команда с разными специализациями | Зависит от опыта одного человека |
| Риск зависимости | Можно сменить подрядчика | Уход сотрудника останавливает обслуживание |
| Погружение в процессы компании | Поверхностнее, особенно в начале | Глубокое, человек внутри команды |
Компании с небольшим числом пользователей и стабильными процессами обычно обходятся подрядчиком: задач немного, и держать человека в штате ради них невыгодно. Там, где CRM работает для десятков сотрудников, доработки появляются каждую неделю, а простои обходятся дорого, разумнее завести отдельного сотрудника. Подробнее о том, чем занимается такой человек и когда момент для найма уже настал, рассказывает материал про то, кто такой специалист CRM системы и когда он нужен в штате.
Промежуточный вариант, который на практике используют многие компании: штатный сотрудник закрывает ежедневную поддержку пользователей и мелкие правки, а подрядчик подключается для сложных доработок и интеграций, которые случаются не каждый месяц.
Частые вопросы
Чем отличается обслуживание CRM от доработки?
Обслуживание поддерживает систему в рабочем состоянии: обновления, бэкапы, устранение сбоев, ответы пользователям. Доработка добавляет новые возможности: поля, воронки, интеграции, которых не было при внедрении. На практике эти задачи часто идут в одном пакете у подрядчика, но в договоре их стоит разделять, чтобы понимать, какие часы входят в ежемесячную плату, а какие оплачиваются отдельно.
Как часто нужно обновлять CRM систему?
Зависит от версии. Облачные CRM, например amoCRM и облачный Битрикс24, обновляются полностью автоматически на стороне серверов разработчика: пользователь не выбирает частоту и не может отложить обновление. Коробочную версию Битрикс24 администратор обновляет вручную: создаёт бэкап, проверяет совместимость сервера и устанавливает обновление. Разумная практика для коробки: крупные обновления не реже раза в квартал, чтобы не накапливать разрыв с текущей версией.
Нужен ли отдельный бэкап, если CRM работает в облаке?
Да. Облачный провайдер обычно отвечает за сохранность инфраструктуры, а не за данные, удалённые или испорченные по ошибке пользователя. Восстановление конкретных записей силами провайдера часто ограничено или платно. Собственный бэкап по расписанию, хранящийся отдельно от рабочей базы, закрывает именно этот риск и не зависит от регламентов конкретного сервиса.
Что должно быть прописано в SLA с подрядчиком по CRM?
Минимум три пункта: время первой реакции на обращение по каждому уровню критичности, срок устранения проблемы и количество часов поддержки, включённых в месячную плату. Без этих пунктов любой спор о скорости реакции решается не по договору, а по устной договорённости, которая легко забывается обеими сторонами уже через пару месяцев.
Можно ли совмещать подрядчика и штатного специалиста по CRM?
Да, и это распространённая модель. Штатный сотрудник закрывает ежедневные вопросы пользователей и мелкие правки, а подрядчик подключается для сложных доработок, интеграций и ситуаций, которые выходят за рамки компетенций одного человека. Такой вариант обходится дешевле полноценной команды в штате и быстрее подрядчика на разовые мелкие задачи.
С чего начать
Если обслуживание CRM системы в компании до сих пор держится на том, что кто-то разберётся, когда сломается, стоит привести его в порядок за несколько шагов. Эти шаги не требуют крупных бюджетов, но требуют, чтобы кто-то взял обслуживание под личную ответственность, а не оставлял его на усмотрение каждого отдела отдельно.
- Выписать, что из перечисленного выше, обновления, бэкапы, доработки, поддержка, сейчас закрывается хоть кем-то, а что не закрывается вообще.
- Настроить резервное копирование по расписанию, если его ещё нет, и один раз проверить восстановление на практике.
- Прописать SLA с текущим подрядчиком или зафиксировать похожие условия внутри компании, если обслуживанием занимается штатный сотрудник.
- Определить, оправдан ли штат отдельного специалиста при текущей нагрузке, или дешевле остаться на подрядчике.
Если разбираться с этим самостоятельно не хочется или не хватает времени, обслуживание и доработку CRM системы можно отдать на автоматизацию бизнес-процессов в агентстве, которое закроет обновления, бэкапы и доработки по согласованному SLA.
