Кейс: Как я навела порядок в CRM с помощью BitrixGPT (и очистила базу от 28 000 мусорных записей)
За годы работы в нашей CRM накопилось огромное количество полей. В справочнике сделок было 524 поля, среди них есть дубли и пустые «черновики». Менеджеры путались, аналитику с первого раза не посмотреть (надо разбираться какое поле выводить), а карточка Сделки перегружена. О том, как я вычистила базу, написала в этой статье, скрины прилагаю.
⚠ Дисклеймер: Материал носит информационный характер, не является консультацией, рекламой или офертой. Для индивидуальных разъяснений обратитесь к профильным специалистам. Материал обработан с помощью ИИ. Контакты автора статьи для связи по вопросам автоматизации указаны в шапке профиля.
Сразу скажу — если вы посмотрите на наш портал и увидите 524 поля, не думайте, что мы «кривые» или не умеем настраивать CRM. Наоборот! Наш портал — живой и рабочий. Мы — интеграторы, и используем свой Битрикс24 не только для собственных задач, но и как полигон для тестов, экспериментов, показа клиентам и «проб и ошибок». Мы его используем максимально.
И знаете что? У многих наших клиентов, которые приходят к нам после нескольких внедрений (удачных или нет, во всю компанию или в какие-то конкретные отделы) или на сопровождение, картина такая же, а порой и «похлеще» (по 50 воронок в сделках, сотня в смарт-процессах, и в каждой — своя логика и автоматические сценарии). Это не плохие порталы — это зрелые, очень продвинутые системы с огромной автоматизацией.
Так что за 524 поля мне не стыдно. Как говорится - это "вариант нормы". Почему не навели порядок раньше? Да муторно это... сидеть и тратить время на выгребание вот этого всего....как представишь, так сразу хочется забыть, честно. Да и особо не мешало. Но с BitrixGPT, встроенном в наш портал Битрикс24 сама задача звучит как интересный эксперимент — неужели нейронка справится с этой задачкой? Как выяснилось — справилась.
Решение: Я решила использовать BitrixGPT для аудита. Ниже — подробный разбор того, как мы с нейросетью «перепахали» базу.
Шаг 1. Первичный аудит и поиск «жертв»
Я попросила ИИ проанализировать, какие из полей реально используются, а какие — просто мусор. Задача была не просто «почистить», а сделать это безболезненно для бизнеса.
Мой промпт для BitrixGPT:
Проанализируй все пользовательские поля в моем портале Битрикс24 — в сделках. Собери название поля, код, тип, список значений (если есть), в каких воронках используется. Найди группы дублирующихся полей. Важно: сравнивай не только по названиям, а по смыслу — что менеджеры туда пишут, для каких целей используют. Учитывай синонимы: «Отрасль», «Сфера деятельности», «Чем занимается» — это одно и то же. То же самое: «Сумма», «Бюджет», «Стоимость проекта» и т.п.
На скриншоте видно, как я поставила задачу: проанализировать 524 поля, найти дубли по названию и смыслу, и составить список кандидатов на удаление.
Шаг 2. Логика против «слепого» удаления (или как ИИ меня переубедил)
Первое, что сделал ИИ — это предложил не удалять всё подряд, а разделить на два типа:
- Пустые поля (где нет данных) — их можно убрать сразу.
- Дубли с данными — их нужно сначала слить или перенести, и только потом удалять.
Честно признаюсь: сначала я хотела пойти простым, и как мне азалось надежным путём — создать новые поля с пометкой «Новое_» и перенести туда данные из дублей, а старые просто удалить. Ну, типа, чтобы всё было чистенько и точно ничего не потерять.
Я даже написала ИИ команду:
На основе твоих рекомендаций создай новые поля для групп дублей. В названии обязательно ставь метку «Новое_». Выкати мне список созданных полей с их кодами. Не создавай поля для тех групп, где дублей нет — там поле уже одно и работает, трогать не нужно.
И вот тут BitrixGPT меня остановил. Он сказал: «Подожди, Юлия, так делать не надо». И объяснил, что если создавать новые поля, то придётся заново настраивать все воронки, отчёты и автоматизации под них. Это лишняя работа и лишний риск.
Он предложил другой путь: не плодить новые сущности, а грамотно мигрировать данные внутри существующих полей. То есть, если мы находим дубль, где одно поле пустое — просто удаляем его. Если в обоих есть данные — аккуратно переносим значения в целевое и только потом чистим старое.
Посмотрите на этот ответ нейросети — она не просто предложила удалить, а расписала алгоритм действий: «сначала мигрировать, потом удалять, ничего не теряем». Это именно тот подход, который нужен бизнесу. И главное — он избавил нас от лишней возни с новыми полями.
Шаг 3. Кейс с «Пакетами»
Мы начали с самого очевидного (для меня и нейросети) дубля: «Тип внедрения» (6520) и «Тип проекта» (3988). Это была классическая ошибка — два поля, которые заполнялись одинаково, но в разных местах.
ИИ посмотрел на них и сказал: «Смотри, “Тип проекта” — пустое, там нет ни одного значения. Значит, это просто дубль-призрак. Его можно смело удалять. А “Тип внедрения” переименуем в “Пакет услуг” — это и есть то, чем пользуются менеджеры».
Я дала команду удалить пустое и переименовать рабочее. ИИ отчитался о проделанной работе, четко указав, что «Тип проекта» был пустым, а все данные сохранены в «Пакете услуг».
Шаг 4. Глубокий анализ «Мероприятий»
Ещё нтересным оказался момент с полями «Был на мероприятии». У нас их было два: список (Да/Нет) и галочка. Галочка стояла почти на 28 000 сделках, а список заполнялся вручную только в 931.
Вот что делал BitrixGPT:
Ищу поля «Был на мероприятии» (список Да/Нет) и «Был на мероприятии» (галочка) в справочнике сделок. Изучаю сохранённый справочник полей сделок, чтобы найти оба поля «Был на мероприятии». Читаю инструкции по работе со сделками и справочниками полей, чтобы корректно выгрузить данные заполнения. Читаю правила ключевой выгрузки сделок, чтобы корректно получить заполнение обоих полей «Был на мероприятии» за все годы. Проверяю выгрузку сделок с нужными полями на одной странице. Анализирую распределение значений по обоим полям «Был на мероприятии» и пересечения.
Вот текст ответа BitrixGPT, который меня поразил своей логикой и глубиной (привожу цитату полностью):
Цитата из ответа BitrixGPT:
Проанализировала поля «Был на мероприятии» по всем сделкам и всем годам (33 501 сделка). Вот что показали данные.
Что это за два поля:
- «Был на мероприятии?» — тип: список. Значения: Да, пришел / Нет, не пришел. Заполнено в 931 сделке (2021–2026).
- «Был на мероприятии» — тип: галочка. Значения: стоит / не стоит. Проставлено на 28 131 сделке (2019–2026).
Что именно лежит в заполнении:Список «Был на мероприятии?» — 931 сделка:
- «Да, пришел» — 606 раз;
- «Нет, не пришел» — 341 раз.
Это и есть осмысленная аналитика посещаемости — 606 подтверждённых приходов.
Галочка «Был на мероприятии» — 28 131 сделка, но:
- галочка стоит (посетил) всего на 16 сделках;
- галочка не стоит на 28 115 сделках.
Пересечение (сделки, где заполнены оба поля — 931):
- Да, пришел + галочка не стоит — 574 сделки.
- Да, пришел + галочка стоит — 16 сделок.
- Нет, не пришел + галочка не стоит — 341 сделка.
Логических противоречий нет (нигде список «Нет» при стоящей галочке «посетил»).
Вывод аналитика:Галочка стоит на ~28 тыс. сделок в положении «не стоит» — это почти наверняка значение формы по умолчанию, а не осознанный признак «не пришёл». Реальную аналитику конверсии (пришёл/не пришёл) несёт именно список «Был на мероприятии?» — её менеджеры заполняют вручную (606 «Да»).
Переносить из галочки фактически нечего: её 16 «посетил» уже все присутствуют внутри списка как «Да, пришел». А 28 тыс. «не стоит» в «Нет, не пришел» превращать нельзя — это дефолт формы, а не отслеженное «не пришёл».
Рекомендация: оставить одно поле — список «Был на мероприятии?» как целевое; галочка «Был на мероприятии» — лишний дубль, удаляем.
Этот ответ — идеальный пример того, как нужно работать с данными. Нейросеть не просто удалила поле, она доказала на цифрах, почему галочка — это мусор (дефолт формы), и почему ее нельзя использовать как аналитику. Это сэкономило нам кучу времени и ошибок.
Хотя я думала иначе: что у нас основное поле - галочка. И без нейросетей мне надо было бы всё проверять самой.
Итог: Порядок без боли и лишних полей
Что мы сделали по факту? Мы прошлись по всем 524 полям, нашли группы дублей и убрали те, которые реально мешали работе (их оказалось около 10). Но самое важное — мы очистили данные от мусора. Вот что это дало:
- 28 000 «пустых» галочек больше не висят мёртвым грузом в сделках — они не мешают аналитике и не вводят менеджеров в заблуждение.
- 606 реальных «Да» остались в целевом поле — теперь по ним можно строить честные отчёты по посещаемости.
- Ни одного нового поля не создано — мы использовали существующие, так что все воронки, отчёты и автоматизации остались рабочими без переделок. Ничего не сломалось.
Почему это стоило делать через ИИ?
- Скорость: Анализ 33 501 сделки занял у нейросети минуты.
- Точность: Ни одна полезная цифра не потерялась (606 «Да» остались в целевом поле).
- Логика: ИИ объясняет решения, а не просто выполняет команды.
Теперь в CRM чисто, менеджеры не путаются, а аналитика посещаемости мероприятий работает на 100% (и другая аналитика тоже, кстати сейчас всё меньше обращаюсь к дашбордам - теперь пишу в нейронку и она дает мне готовые цифры и выводы).
Совет: Если у вас в CRM есть «мусор», не удаляйте его вслепую. Напишите в BitrixGPT и попросите проанализировать пересечения. Вы удивитесь, сколько логических ошибок он найдет. А может и нет. но точно порадуетесь тому, сколько рутины вас обошло стороной.
p.s. Математика простая: раньше мы это делали с помощью визуального анализа списка полей и сортировали поля, чтобы посмотреть, какие заполняются, какие нет, или выгружали в ексель, а потом умным сценарием (а его ж еще настроить надо) переносили из одного поля в другое. А теперь вообще никаких настроек делать не надо. Вот и считайте.