Кто изменил данные в CRM: как разбирать ошибки и спорные ситуации

Что именно изменилось в сделке?

Можно ли установить, кто изменил сумму сделки, если сотрудники помнят разговор по-разному? Разбор начинается с конкретной карточки и события: в истории Битрикс24 ищут запись о правке, затем выясняют, какое действие её вызвало. Имя в строке сужает поиск, но само по себе ещё не позволяет отличить ручную правку от автоматического действия.

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

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

Сначала определяют факт ошибки. Несовпадение воспоминаний — повод найти сведения, а не назначить виновного.

Три истории отвечают на разные вопросы

Изменение суммы относится к элементу CRM, перенос срока подготовки договора — к задаче, а вход сотрудника — к доступу в Битрикс24, поэтому сведения собирают из разных мест по вопросу, который сейчас разбирают. Вход рядом по времени с правкой ещё не объясняет способ изменения поля.

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

Историю задачи ищут в её чате или боковом разделе «История задачи». Там фиксируются ключевые действия с поручением, включая срок и статус, по описанию новых задач Битрикс24. Перенос срока может объяснить более позднюю подготовку документа, но вопрос о сумме сделки требует записи о другом объекте.

Для входов предусмотрен «Журнал событий» в настройках безопасности. Доступ к нему получает администратор, а сама функция есть не на всех тарифах, согласно документации журнала. Сведения о сотруднике, времени и IP-адресе относятся к входу. Их используют, когда нужно разбирать доступ, а не вместо записи о поле CRM.

История поручения не равна истории продажи. Если спор касается обеих, руководитель описывает их как два связанных события, чтобы не искать один универсальный журнал.

Нужной записи не видно

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

Фильтр «ID» в истории CRM выделяет конкретный элемент по уникальному номеру из адреса карточки, как объясняет справка Битрикс24. Он полезен при изменившемся названии: дальше выбирают период, в котором можно увидеть событие вместе с ближайшими изменениями той же продажи.

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

Доступ к истории регулируется отдельно: в блоке «История» право «Чтение» показывает или скрывает соответствующие разделы. Это описано в ролевой модели CRM. Кроме того, сотрудник видит историю доступных ему элементов. Если менеджер не находит событие, администратор разбирает его права и при необходимости смотрит запись сам, а не выдаёт всей команде широкие полномочия.

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

Отсутствие строки нужно описать точно. Руководитель получает ответ, какие источники просмотрены и чего в них не удалось найти, а не уверенное обвинение на основе пустого экрана.

Имя в строке и реальный способ изменения

Имя пользователя помогает найти нужный участок работы, но не описывает этот участок целиком: данные могут менять роботы, бизнес-процессы и подключённые сервисы. После обнаружения события сначала выясняют источник правки. Уже затем обсуждают ответственность за действие или настройку.

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

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

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

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

История не откатывает сделку

Удаление записи из истории не возвращает прежнее значение, о чём Битрикс24 предупреждает в инструкции истории CRM. Администратор может убрать строку, но сама правка остаётся в карточке. Очистка списка одновременно уничтожит сведения, которые ещё могли помочь выяснить причину.

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

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

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

Как остановить повтор ошибки

Если после ручной правки поле снова получает неправильное значение, разбирают источник записи: запрет менеджеру редактировать всё подряд может мешать работе и при этом оставить роботу возможность вернуть прежний вариант. Иначе человек и автоматизация будут по очереди исправлять одну карточку.

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

По справке Битрикс24 активные роботы и бизнес-процессы продолжают работать с настройками на момент запуска, поэтому исправление шаблона для будущих продаж рассматривают отдельно от уже запущенной работы в текущей сделке. Исполнитель объясняет, как устранить проблему в обоих состояниях.

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

Исправленная карточка — только часть результата. Команда также получает понятное правило, кто меняет данные и по какому основанию.

Задание на разбор спорной правки

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

• Карточка. Ссылка на элемент и название спорного поля, чтобы исполнитель работал с той же продажей.
• Изменение. Текущее значение, ожидаемый вариант и момент, когда расхождение заметили.
• Основание. Документ или договорённость, по которым выбирается верное значение.
• Найденная запись. Время, автор и описание события либо точная запись о том, что поиск пока не дал результата.
• Возможные источники. Действия менеджера и автоматические сценарии, которые могли затронуть поле. Предположения отмечены отдельно от фактов.
• Ожидаемый итог. Исправить текущую продажу, объяснить причину и показать, что повторный переход больше не создаёт ошибку.

Подробный список событий легко принять за полную картину всех действий, если исполнитель не объяснит, какие сведения ему доступны. В задании на доработку Битрикс24 полезно запросить границы вывода: какие события доступны в вашем тарифе, что сохранялось раньше и какие записи позволили назвать причину. Когда часть сведений найти не удалось, исполнитель перечисляет просмотренные источники. Оставшиеся предположения он отмечает отдельно.

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