Карточки в CRM пустые не потому, что менеджеры ленивы, а потому, что к системе не подведены источники данных. Телефон клиента уже есть в журнале звонков, адрес почты — в переписке, ИНН — в открытом реестре, факт оплаты — в учётной системе. Пока эти данные не связаны с карточкой, менеджер переписывает их руками из одного окна в другое, и на восьмой раз за день делает это плохо.
В модельном отделе продаж из 8 менеджеров с потоком 900 сделок в месяц ручной ввод занимает 6 минут на сделку. Это 90 часов в месяц — больше половины ставки одного сотрудника, который ничего не продаёт, а перекладывает данные. По полной стоимости часа менеджера в 700 ₽ (оклад, налоги, рабочее место, руководитель) получается 63 000 ₽ в месяц, или 756 000 ₽ в год.
Ниже — шесть источников, из которых поля заполняются без участия человека, честное разделение на то, что машина делает надёжно и что только предлагает, смета по каждому источнику отдельно и два порога по объёму, ниже которых автозаполнение не окупается. Все цены — ориентиры рынка на сентябрь 2026 года, все расчёты можно пересчитать на калькуляторе по числам из текста.
Шесть источников, из которых карточка заполняется сама
Источник — это не «интеграция вообще», а конкретный поток событий, у которого есть свой набор полей, своя надёжность и своя цена подключения. Их шесть, и они закрывают разные части карточки: контактные данные, канал обращения, деньги и юридические реквизиты. Ни один из них не заполняет карточку целиком, и в этом смысл: подключать надо те, которые закрывают ваши пустые поля, а не все подряд.
| Источник | Что попадает в карточку | Надёжность | Что нужно для подключения |
|---|---|---|---|
| Телефония | Номер, направление и длительность звонка, ответственный, ссылка на запись, расшифровка разговора | Высокая по номеру и факту звонка, средняя по содержанию разговора | Готовый коннектор оператора либо связка по API; привязка «сотрудник — внутренний номер — пользователь CRM» |
| Почта | Адрес отправителя, тема, текст письма, вложения, дата первого касания | Высокая по адресу и вложению, средняя по смыслу письма | Корпоративный домен, подключение ящиков, правило привязки письма к сделке |
| Мессенджеры | Профиль и внешний идентификатор, история переписки, вложения, канал обращения | Высокая по факту диалога, низкая по личности: ник не равен клиенту | Бот или прослойка канала, склейка диалога с контактом по телефону |
| Форма сайта | Метки кампании, страница обращения, время, устройство, согласие на обработку данных | Очень высокая: данные приходят машиной, а не человеком | Передача заявки по вебхуку, обязательный набор скрытых полей формы |
| Учётная система | Счёт, оплата, отгрузка, остаток по договору, номенклатура заказа | Высокая: это первичные документы, а не оценка | Обмен с 1С, МойСклад или Saby; событийный, а не файловый |
| Открытые реестры по ИНН | Полное наименование юрлица, адрес, руководитель, статус, основной вид деятельности | Высокая при верном ИНН и нулевая при неверном — ошибку не поймать глазами | Подключение сервиса проверки контрагентов, поле ИНН как ключ карточки |
У каждого источника есть своя граница надёжности, и её стоит проговорить до подписания договора. Телефония безошибочно отдаёт номер и факт разговора, но не отвечает за то, кто именно взял трубку на стороне клиента. Почта надёжна по адресу отправителя и вложению, но письмо, отправленное с личного ящика закупщика, не привяжется к сделке, заведённой на корпоративный домен. Мессенджеры дают самый ненадёжный ключ: ник не равен человеку, и без склейки по телефону вы получите второй контакт вместо истории. Форма сайта — единственный источник, где данные генерирует машина, а не человек, поэтому в ней ошибок меньше всего и именно она обычно даёт первый заметный результат.
Шестой источник обычно забывают, хотя он самый дешёвый. Один правильно введённый ИНН превращается в наименование, адрес, руководителя и статус юрлица без единого нажатия клавиши, и заодно даёт ключ склейки для всей базы юридических лиц. Но именно из-за ИНН чаще всего появляются задвоенные контрагенты: опечатка в одной цифре создаёт вторую карточку той же компании. Как это ловится и чинится, мы разобрали в статье про дубли клиентов в CRM — подключать реестр без правила нормализации не стоит.
Поля факта и поля суждения
Главная развилка проекта проходит не между источниками, а между двумя типами полей. Одни фиксируют произошедшее событие: был звонок, пришло письмо, поступила оплата. Другие содержат вывод человека о ситуации: на каком этапе сделка, почему клиент отказался, что делать дальше. Первые машина заполняет надёжно и без спроса. Вторые она в лучшем случае предлагает, а решение принимает менеджер.
Поле факта — то, у которого есть внешний источник истины: номер телефона в журнале АТС, сумма в счёте, дата отгрузки в накладной. Такое поле можно заполнять автоматически и перезаписывать без подтверждения. Поле суждения — то, значение которого существует только в голове сотрудника: этап сделки, причина отказа, следующий шаг. Автоматически его можно только предложить, а записать — после подтверждения человеком. Смешивание двух типов в одном контуре и есть главная причина, по которой автозаполнение приводит к красивым, но неверным отчётам.
| Поле | Тип | Кто заполняет | Что делать с ошибкой |
|---|---|---|---|
| Телефон, почта, канал обращения | Факт | Машина, без подтверждения | Перезаписывается при следующем событии автоматически |
| Наименование компании, ИНН, адрес | Факт | Машина по реестру | Правится только через смену ИНН, вручную поле закрыто |
| Сумма сделки, факт и дата оплаты | Факт | Машина из учётной системы | Учётная система — владелец поля, в CRM оно только читается |
| Ответственный менеджер | Факт | Машина по правилу распределения | Меняется руководителем, изменение пишется в журнал |
| Краткое содержание звонка или письма | Смешанное | Машина предлагает, менеджер правит | Хранить рядом с исходником: расшифровкой или письмом |
| Этап сделки | Суждение | Менеджер; машина только подсвечивает несоответствие | Автоперевод этапа по событию допустим на 2–3 переходах, не на всех |
| Причина отказа, следующий шаг и его дата | Суждение | Только менеджер | Машина напоминает о пустом поле, но не заполняет его |
Правило «пришла оплата — сделка перешла в статус „оплачено“» работает и полезно. Правило «менеджер позвонил — сделка перешла в „переговоры“» ломает всю воронку: этапы начинают двигаться от активности, а не от результата, и через квартал отчёт по конверсии показывает ровную красивую картину, не имеющую отношения к продажам. Безопасное количество автопереходов — два-три на всю воронку, и только те, у которых есть документ-основание: счёт, оплата, отгрузка, подписанный акт.
Сколько это стоит в часах: 8 менеджеров, 900 сделок в месяц
Считаем на модельном отделе: 8 менеджеров, 900 сделок в месяц, продажи идут по телефону, почте и через форму сайта, счета выставляются в 1С. Замер ручного ввода делается за неделю по секундомеру у трёх менеджеров, а не по ощущениям руководителя: в среднем получается 6 минут на сделку, из которых примерно две трети приходятся не на набор текста, а на переключение между окнами и поиск нужной строки.
Цифра 4,5 минуты — не обещание, а результат сложения по источникам из таблицы ниже. Её надо пересчитать на своих данных, потому что структура ввода у всех разная: в оптовой компании больше всего времени уходит на перенос позиций заказа из письма в счёт, а в услугах — на поиск клиента по номеру перед разговором. Замер до внедрения занимает неделю и стоит ноль рублей, а без него подрядчик и заказчик обсуждают не проект, а взаимные ощущения. Отдельная методика замера процесса до внедрения разобрана в материале о том, как измерить процесс до автоматизации.
Смета по источникам: почему подключают очередями
Общая цифра «автозаполнение стоит 420 000 ₽» бесполезна для решения. Полезна разбивка, потому что источники окупаются с разницей в десять раз, и правильный порядок подключения важнее общего бюджета. Экономия по источнику считается одинаково: минуты на сделку × 900 сделок × 700 ₽ ÷ 60, то есть каждая снятая минута на сделку стоит 10 500 ₽ в месяц.
| Источник | Снимает на сделку | Разово | Поддержка | Чистыми в месяц | Окупаемость |
|---|---|---|---|---|---|
| Сокращение полей и переразметка карточки | подготовка | 30 000 ₽ | — | — | обязательная первая работа |
| Телефония | 1,4 минуты | 60 000 ₽ | 3 000 ₽ | 11 700 ₽ | 5,1 месяца |
| Почта | 0,9 минуты | 45 000 ₽ | 2 500 ₽ | 6 950 ₽ | 6,5 месяца |
| Форма сайта и метки | 0,5 минуты | 35 000 ₽ | 1 500 ₽ | 3 750 ₽ | 9,3 месяца |
| Реестры по ИНН | 0,4 минуты | 40 000 ₽ | 2 000 ₽ | 2 200 ₽ | 18,2 месяца |
| Учётная система: счета, оплаты, отгрузки | 0,7 минуты | 120 000 ₽ | 4 000 ₽ | 3 350 ₽ | 35,8 месяца |
| Мессенджеры | 0,6 минуты | 90 000 ₽ | 5 000 ₽ | 1 300 ₽ | 69 месяцев |
| Итого | 4,5 минуты | 420 000 ₽ | 18 000 ₽ | 29 250 ₽ | 14,4 месяца |
Две нижние строки таблицы выглядят приговором, но означают другое. Обмен с учётной системой и подключение мессенджеров действительно не окупаются экономией на вводе — их покупают не за это. Обмен с 1С окупается тем, что менеджер видит оплату и остаток и перестаёт звонить в бухгалтерию, а клиент не получает счёт на позицию, которой нет; эту арифметику мы считали отдельно в статье про интеграцию CRM с 1С, там суточная задержка обмена стоит 84 900 ₽ в месяц. Мессенджеры окупаются скоростью первого ответа и тем, что переписка остаётся у компании, а не в телефоне уволившегося менеджера. Если считать их только по снятым минутам, вывод получится формально верным и по сути ложным.
Подставьте стоимость своей первой очереди и месячную эксплуатацию, а месячный эффект возьмите по методике выше: снятые минуты на сделку × число сделок × ставку часа ÷ 60. Стартовые значения — полный набор из шести источников: 420 000 ₽ разово и 18 000 ₽ в месяц.
Сколько стоит ручная работа в вашем процессе
Расчёт учитывает только время сотрудников. Возвращённые продажи, снятые ошибки и штрафы, скорость реакции — сверх этой модели. На диагностике считаем по вашим фактическим цифрам.
Цифры выше уже подставим. Расскажите в двух словах, что за процесс — и получите разбор.
Порядок внедрения: сначала выбросить поля, потом подключать каналы
Порядок здесь важнее содержания, и самая частая ошибка — начать с ИИ-разбора текста, потому что он выглядит эффектнее всего. В итоге модель аккуратно раскладывает по полям письма, половина из которых ведёт в поля, которые никто никогда не открывает. Правильная последовательность обратная: сначала уменьшить количество полей, потом подвести источники к тем, что остались, и только в конце добавлять разбор текста.
- 1Шаг 1. Сократить поля карточки, 1–2 недели
Взять список всех полей и для каждого найти живого человека, который его читает и в каком отчёте. Поля, у которых такого человека нет, скрываются. В типовой запущенной карточке из 34 полей остаётся 12–16, и это единственный шаг, который даёт эффект в тот же день и стоит только времени руководителя. Обязательных полей после сокращения должно остаться не больше семи — их и меряют дальше.
- 2Шаг 2. Подвести каналы входа, 2–4 недели
Телефония, почта, форма сайта: контакт, канал обращения, первое касание, метки кампании. На этом шаге закрывается самая дешёвая часть экономии и появляется главное — источник лида в каждой сделке, без которого не считается ни один отчёт по рекламе. Здесь же настраивается правило распределения, чтобы поле ответственного заполнялось само.
- 3Шаг 3. Подвести деньги и реквизиты, 3–6 недель
Обмен с учётной системой на счета, оплаты и отгрузки; подключение реестра по ИНН на реквизиты юрлиц. Это самая дорогая часть и единственная, где нужен отдельный разговор о владении данными: кто создаёт контрагента, кто меняет его реквизиты и куда уходит изменение. Без этого разговора вы получите два справочника контрагентов вместо одного.
- 4Шаг 4. Добавить разбор текста, 2–4 недели
Резюме звонка, краткое содержание письма, извлечение позиций заказа из переписки. Всё, что модель вытащила, попадает в карточку как черновик рядом с исходником и ждёт подтверждения менеджера — а не заменяет собой факт. Этот шаг делается последним, потому что до него не видно, какие именно поля стоит наполнять текстом.
Первый шаг стоит отдельного упоминания, потому что его почти всегда пропускают. Сокращение полей — единственная работа в этом списке, которая экономит время сразу и не требует ни одной интеграции. Тридцать обязательных полей в карточке — типичная ошибка настройки, из-за которой менеджеры заполняют форму мусором, лишь бы она закрылась, а система постепенно превращается в ту самую зомби-систему, за которую платят и которой не пользуются. Если это про вас, начинать надо с полей, а не с интеграций: контур автозаполнения поверх мёртвой карточки даст только более аккуратный мусор.
Сроки в ленте выше — рабочие, а не рекламные. Каналы входа занимают 2–4 недели не из-за сложности программирования, а из-за согласований: нужен доступ к почтовому домену, решение о том, какие номера куда звонят, и договорённость о правиле распределения заявок. Обмен с учётной системой почти всегда выходит за первоначальную оценку, потому что обнаруживается доработанная конфигурация или второе юрлицо. Закладывать на третий шаг менее шести недель при доработанной 1С — значит переносить срок в середине проекта.
152-ФЗ в контуре автозаполнения
Автозаполнение переносит персональные данные между системами и создаёт записи разговоров — то есть попадает под 152-ФЗ целиком, а не частично. Практических требований здесь пять, и все они дешёвые, если заложены на старте, и дорогие, если о них вспомнили после запуска.
- Запись разговоров. Абонент должен быть предупреждён о записи до её начала — это фраза в приветствии, а не строчка в политике на сайте. Срок хранения записей фиксируется явно (обычно 6–12 месяцев) вместе с ответом на вопрос, что происходит с файлами при расторжении договора с оператором связи: у части провайдеров они удаляются вместе с доступом.
- Где физически лежат данные. Базы с персональными данными граждан России должны находиться на серверах в России. Это касается и CRM, и хранилища записей, и той прослойки, через которую вы разбираете письма и сообщения. Модель, которой вы отдаёте текст на резюмирование, — тоже звено этого контура.
- Согласия и основания. Для клиента-заявителя основанием обычно служит исполнение договора, но рассылки, скоринг и обогащение из внешних сервисов требуют отдельного разговора с юристом. Момент получения согласия фиксируется вместе с обращением: время, канал, текст формулировки.
- Поручение обработки подрядчику. Если контур собирает и поддерживает подрядчик, у него появляется доступ к базе — значит, нужно поручение с перечнем данных, действий и сроков. Что в нём должно быть, мы разобрали в отдельной статье про поручение обработки данных подрядчику; оператором при этом остаётесь вы.
- Минимальные права. Автозаполнение обычно требует технического пользователя с широкими правами — и он живёт годами. Токен интеграции должен видеть ровно те объекты, которые ему нужны, а его действия — попадать в тот же журнал, что и действия людей. Общий принцип разобран в материале про минимальные права доступа.
Запись звонка отдаётся на распознавание, текст — на резюмирование модели, результат кладётся в карточку. В этой цепочке данные клиента проходят через два-три сервиса помимо CRM, и каждый из них должен находиться в российском контуре. Прямая оплата зарубежных API из России невозможна, а доступ через посредников означает, что вы не знаете, где физически обрабатывается разговор вашего клиента, — это ограничение, с которым надо считаться при проектировании, а не обходной путь. Практический вариант: российская платформа распознавания и модель в российском облаке либо на своём сервере, если требования к контуру жёстче обычных.
Как ломается автозаполнение и как замечать это раньше менеджеров
Автозаполнение ломается тихо. Ни один источник не выдаёт ошибку в лицо менеджеру: карточка просто остаётся пустой, а менеджер вписывает данные руками, потому что ему нужно работать, а не разбираться. Через месяц выясняется, что почтовый ящик отвалился в день смены пароля, а обмен с учётной системой встал после обновления конфигурации — и всё это время компания платила за контур, которого не было. Поэтому мониторинг закладывают вместе с интеграцией, а не после первого разбора.
| Что ломается | Как это выглядит для менеджера | Чем ловится |
|---|---|---|
| Пароль или токен ящика сменили | Письма перестали появляться в сделке, ошибки нигде нет | Контрольное письмо по расписанию: не разобрано за 15 минут — оповещение ответственному |
| Коннектор телефонии обновился у вендора | Карточка перестала всплывать до снятия трубки | Тестовый звонок раз в сутки с проверкой, что событие дошло до CRM |
| Обмен с учётной системой встал молча | Оплаты в карточке отстают на несколько дней | Сверка счётчиков: число оплат за сутки в CRM и в учёте должно совпадать |
| Упёрлись в лимит запросов к API | Часть событий доходит, часть теряется без закономерности | Журнал обмена с числом отказов и очередь с повторной отправкой |
| Изменилась форма на сайте | Заявки приходят без меток кампании, источник лида пустой | Проверка обязательных полей на входе и отказ с уведомлением вместо тихой потери |
Правило простое: у каждого источника должна быть проверка, которая идёт по расписанию и не зависит от того, заметил ли кто-то проблему. Как устроены такие проверки и что должно быть в протоколе приёмки, разобрано отдельно в статьях о том, как убедиться, что интеграция работает, и о мониторинге автоматизации. Стоит этот контур 25 000–40 000 ₽ в рамках проекта и входит в те самые 18 000 ₽ поддержки в месяц.
Как измерить результат: полнота карточки до и через 30 дней
Результат автозаполнения меряют не «удобством» и не количеством подключённых систем, а одной метрикой — полнотой карточки по обязательным полям. Считается она просто: берём все сделки, созданные за период, и для каждого обязательного поля смотрим долю сделок, где оно заполнено. Замер делается дважды: за 30 дней до запуска и за 30 дней после, на сопоставимом объёме.
| Обязательное поле | Заполнено до | Через 30 дней | Кто заполняет после запуска |
|---|---|---|---|
| Телефон | 94 % | 99 % | Телефония и форма сайта |
| Электронная почта | 29 % | 82 % | Почтовый ящик и форма сайта |
| Канал обращения | 18 % | 97 % | Источник события, машина |
| Компания и ИНН | 22 % | 76 % | Реестр по ИНН, ключ вводит менеджер |
| Сумма сделки | 44 % | 89 % | Учётная система: счёт и оплата |
| Ответственный | 71 % | 100 % | Правило распределения заявок |
| Следующий шаг и его дата | 12 % | 43 % | Только менеджер, машина напоминает |
| Средняя полнота по семи полям | 41 % | 84 % | — |
Вторая метрика честнее первой и обычно разочаровывает: доля сделок, где заполнены все семь полей сразу, растёт с 6 % до 38 %. Потолок здесь задаёт единственное поле, которое машина не заполняет: если следующий шаг проставлен у 43 % сделок, полностью заполненных карточек не может быть больше 43 %. Это и есть та часть работы, которую автозаполнение не решает, — её решают регламент и разбор очереди на планёрке, а не интеграция.
Если после запуска доля заполненных полей выросла на автоматических полях и не сдвинулась на ручных, это не саботаж, а сигнал: ручные поля либо не нужны, либо их некому читать. Прежде чем вводить контроль заполнения, стоит пройти по каждому оставшемуся ручному полю и спросить, в каком решении оно участвует. Обычно после такой проверки из семи обязательных полей остаётся пять, и полнота вырастает сама.
Карта раздела: какая статья закрывает каждый источник
Каждый источник — отдельный проект со своими граблями, ценой и сроком. Здесь только указатель, чтобы не пересказывать их дважды.
- Телефония: интеграция CRM с телефонией — три способа связки, кого можно называть в 2026 году и пять мест, где связка обычно разваливается. Если делаете сами — есть пошаговая инструкция на 14–20 часов работы.
- Почта: разбор входящих писем по типам с извлечением вложений разобран на странице решения обработка электронной почты.
- Мессенджеры: как собирается единое окно обращений из всех каналов и почему архитектуру надо проектировать под смену канала, а не под конкретный мессенджер.
- Форма сайта: как связать форму сайта с CRM и мессенджером — обязательный набор полей и резервный контур на случай недоступности системы.
- Учётная система: интеграция CRM с 1С — четыре способа обмена, таблица владения данными и цена суточной задержки.
- Реестры и чистота базы: дубли клиентов в CRM — правила нормализации до поиска и порядок склейки без потерь.
- Разбор текста: встроенный ИИ в CRM или заказной агент — что коробка умеет, а где начинается заказная работа.
- Деньги проекта целиком: сколько стоит внедрение CRM и из каких шести статей складывается смета.
Когда автозаполнение не окупится
Автозаполнение — не универсальное улучшение, а вложение с порогом. Порогов на самом деле два, и они считаются из тех же чисел. Каждая снятая минута на сделке стоит 700 ₽ ÷ 60 ≈ 11,7 ₽, значит 4,5 снятых минуты дают ровно 52,5 ₽ с каждой сделки.
Кроме порога по потоку есть четыре ситуации, в которых мы сами советуем не начинать. Первая: сделки рождаются не в каналах связи. Если продажи идут на выставках, объектах и личных встречах, а звонков и писем почти нет, подводить нечего — источников данных физически не существует, и деньги уйдут на интеграции, через которые не течёт ничего. Вторая: база в дублях. Автозаполнение на грязной базе не чинит её, а размножает — каждое входящее событие создаёт ещё одну карточку рядом с двумя существующими. Сначала нормализация и склейка, потом источники.
- Поля никто не читает. Если из 34 полей карточки в отчётах участвуют шесть, автозаполнение остальных двадцати восьми — это оплаченная работа по наполнению мусорного бака. Первый шаг здесь бесплатный и даёт больше, чем весь проект.
- Длинный проектный цикл. Тридцать сделок в год, каждая на несколько месяцев и с уникальным составом — экономия на вводе составит несколько часов в год. Здесь полезны не источники данных, а нормативный срок этапа и подсветка зависших сделок.
- Система меняется через квартал. Если решение о смене CRM уже принято, подключать источники к уходящей системе бессмысленно: коннекторы, правила и права не переносятся. Разумнее подождать и заложить автозаполнение в проект новой системы — это дешевле, чем делать работу дважды.
- Нет владельца процесса. Автозаполнение меняет правила ведения сделки, а не только техническую часть. Если никто в компании не может решить, что считается обязательным полем и кто отвечает за причину отказа, проект упрётся не в интеграции, а в отсутствие решения.
И последнее. Автозаполнение не превращает менеджера в продавца — оно возвращает ему 67,5 часа в месяц на восьмерых, то есть примерно по 8,4 часа на человека. Что произойдёт с этим временем, определяет не система, а руководитель: оно либо уходит в дополнительные касания и разбор зависших сделок, либо растворяется. Заранее решить, куда именно оно пойдёт, стоит ноль рублей и определяет, окупится ли вложение в 420 000 ₽.
Машина заполняет то, что уже произошло. Всё, что требует решения, остаётся за человеком — и именно это надо оставить ему в чистом виде.
