CRM внедрили, а сотрудники всё равно работают в Excel. Когда действительно нужна своя система?

В компании есть CRM. Менеджеры ведут сделки, руководитель смотрит воронку. Но когда заказ доходит до расчёта, начинается другая жизнь. Кто-то открывает таблицу, переписывает туда данные из карточки, считает, отправляет результат на проверку в мессенджер, вносит правки и вручную собирает документ. В CRM возвращается одна строка: «Согласовано». Формально автоматизация есть. По факту самую рискованную часть работы выполняют человек, буфер обмена и память.

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

Снаружи всё выглядит одинаково: «Слишком много ручной работы». Но если проследить, что происходит с информацией на каждом шаге, за этой жалобой обычно стоят разные проблемы.
— Первая: данные есть в одном месте, а нужны в другом. Менеджер переписывает параметры заказа из CRM в таблицу. Это задача передачи данных, и нередко её решает штатная интеграция.
— Вторая: расчёт идёт по правилам, которые живут в сложной таблице или в голове опытного сотрудника. Здесь вопрос в расчётной логике: можно ли записать правила так, чтобы результат не зависел от того, кто считает.
— Третья: нужны проверка и исключения. Кто-то должен утвердить сумму или нестандартную позицию, и важно, кто что может менять на каком этапе. Это задача прав и состояний заказа.
— Четвёртая: после согласования меняется прайс, а согласованный документ пересчитываться не должен. Это задача фиксации утверждённого результата.
Решения у них разные. Первая задача чаще всего решается настройкой или связкой сервисов. Четвёртую стоит проверять отдельно, потому что возможности продуктов здесь заметно различаются.
Практический приём такой. Возьмите один реальный заказ и пройдите его от обращения до итогового документа, не по регламенту, а по фактическим действиям людей. Отметьте каждое место, где кто-то копирует, пересчитывает, перепроверяет или спрашивает разрешения, и подпишите, к какому из четырёх типов оно относится.
Если отметки относятся к одному типу, начните с самого простого инструмента, который решает эту задачу. Если типов несколько, это повод внимательно проверить сочетание требований, а не повод сразу идти к разработке: каждое из них вполне может закрываться вашей CRM.

1. Готовая CRM с настройками
Когда подходит: процесс укладывается в возможности вашей CRM: собственные сущности, статусы, роли, конструктор документов, готовые интеграции.
Что проверить: есть ли нужные функции в вашем продукте и тарифе и как они работают на реальном заказе.

2. Таблицы и стандартные инструменты
Когда подходят: небольшой объём, понятные правила, невысокая цена ошибки.
Что проверить: кто может менять данные, как ведутся версии, видна ли история изменений.

3. Low-code и интеграции
Когда подходят: нужен маршрут между существующими сервисами, свои формы, расчёты, документы.
Что проверить: ограничения платформы, надёжность связей, что будет при двойной передаче данных или недоступности сервиса.

4. Индивидуальная система
Когда подходит: собственная модель данных, сложные правила, роли, версии, исключения.
Что проверить: стоимость владения, документацию, тестирование, поддержку и передачу системы другому специалисту.

Это не лестница, по которой обязательно нужно подниматься. Часто получается гибрид: CRM остаётся для продаж, а отдельный модуль берёт на себя расчёт и согласование и возвращает результат в карточку сделки. «Своя система» не обязательно означает разработку с нуля.
Признаки того, что стоит внимательно проверить возможности стандартных инструментов, обычно такие. Результат должен быть воспроизводимым: через полгода вы должны получить тот же расчёт, даже если цены изменились. Права устроены сложнее, чем «видит всё» и «видит своё». Исключения повторяются так часто, что стали отдельной веткой процесса. Ошибка стоит дорого: неверная цифра ведёт не к правке ячейки, а к переделке договора или закупки.

Я бы отговорила от неё в трёх случаях.

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

Я делала систему «Электронный замер» для компании, которая выполняет выездные замеры и монтажно-отделочные работы. Возьму из неё один критерий выбора, а не весь проект.
Замерщик фиксирует зоны, размеры, проёмы, работы и материалы. Позиции считаются по разным правилам: по площади, по погонным метрам, поштучно, комплектами, есть нестандартные. Менеджер проверяет и утверждает результат. После этого расчёт должен остаться неизменным, даже если каталог материалов изменится. На выходе — три варианта PDF: два клиентских документа и один для монтажников.
В этом проекте задача выходила далеко за пределы хранения сделки и её суммы. Требовалось связать расчёты, разные роли, согласование и сохранение утверждённых значений. Поэтому я реализовала отдельный операционный контур с индивидуальной логикой, не создавая новую CRM.
Фиксацию я проверила отдельным тестом. Я изменила ставку в каталоге: новый расчёт получил обновлённую цену, а ранее утверждённый сохранил прежнюю сумму. При этом я не разрабатывала всю систему с нуля. Интерфейс собран на AppSheet с Google Sheets и Apps Script, есть ограниченный офлайн-ввод с последующей синхронизацией. Это ближе к low-code с индивидуальной логикой, чем к классической разработке. Внутренние проверки пройдены, система подготовлена к пользовательской приёмке. Данных об экономии времени или денег у меня нет, и придумывать их я не буду.

Стоимость лицензии CRM видна в счёте. Стоимость собственной системы складывается из нескольких составляющих: разработка, платформа или хостинг, поддержка, доработки при изменении правил, документация, обучение сотрудников. У low-code есть подписки и ограничения платформ, а интеграции могут требовать доработки при изменении внешних сервисов.
Отдельный риск — зависимость от одного специалиста. До старта выясните, у кого будут доступы и исходники, описана ли логика расчётов и сможет ли другой человек продолжить работу. Если ответ «только у разработчика», это тоже часть цены.
Автоматизация ускоряет всё подряд, включая ошибки. Если справочники содержат ошибки, а данные в источниках расходятся, система начнёт воспроизводить беспорядок быстрее. Заказная разработка не обязательно дешевле или надёжнее стандартного решения. Иногда выходит наоборот.

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

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

Разборы таких развилок я веду в Telegram: t.me/systemsmaya.