Как посмотреть историю изменений в сделке Битрикс24

Два места, где Битрикс24 показывает историю сделки

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

Ответ у Битрикс24 есть, но лежит он в двух разных интерфейсах. Они устроены по-разному и закрывают разные задачи, поэтому начинать стоит с понимания, куда именно идти.

Первый вариант, это вкладка «История» внутри самой карточки сделки. Она отвечает на вопрос, что происходило конкретно с этим элементом. Каждая запись содержит дату события, автора, тип события и описание того, что именно произошло.

Второй вариант, это общий раздел истории в CRM. Путь до него: CRM → Ещё → История. Сквозной журнал сразу по всем элементам CRM: лидам, контактам, компаниям, сделкам. Он отвечает на другой вопрос, что вообще творилось в CRM за период, и умеет фильтроваться по нескольким параметрам одновременно.

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

Как посмотреть историю изменений в конкретной сделке

Самый частый сценарий: сделка одна, вопрос точечный. Порядок действий такой.

Откройте раздел CRM и перейдите в «Сделки». Если у вас несколько направлений (воронок), убедитесь, что смотрите в нужное. Сделка могла быть перенесена между воронками, и в списке текущей вы её просто не увидите.
Найдите нужную сделку в списке и кликните по её названию. Откроется карточка: поля в левой части, таймлайн в правой.
В верхней части карточки найдите строку вкладок и переключитесь на вкладку «История».
Просмотрите записи. По каждой видно дату, автора изменения, тип события и описание. Это и есть ответ на вопрос, кто изменил сделку.

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

Важный нюанс для тех, кто ищет смену стадии. Записи о движении по воронке видны и в таймлайне справа: он хранит историю коммуникации с клиентом, созданные документы, комментарии сотрудников и записи об изменении стадий. Но таймлайн устроен как лента общения, а не как журнал. Он удобен, когда нужно восстановить контекст переговоров, и неудобен, когда нужно быстро найти одно изменение поля среди сотни писем и звонков.

Общий журнал: CRM → Ещё → История

Второй инструмент нужен, когда вы не знаете заранее, в какой сделке искать. Раздел открывается из левого меню CRM через пункт «Ещё» → «История».

Выглядит он как список событий по всей CRM в обратном хронологическом порядке. Сам по себе, без фильтров, он мало что даёт: на живом портале это тысячи строк за неделю. Ценность появляется, когда вы начинаете сужать выборку.

Фильтровать историю можно по нескольким параметрам:

по ID элемента, если известен конкретный элемент CRM;
по типу элемента CRM: лиды, контакты, компании, сделки;
по типу изменения: пользовательские изменения, письма, просмотр, экспорт;
по автору, то есть сотруднику, который совершил действие;
по дате: конкретный день, месяц или произвольный диапазон;
по описанию, то есть поиском по ключевым словам в тексте события.

Комбинация «автор плюс диапазон дат» закрывает большинство разбирательств. Сотрудник уволился и перед уходом что-то натворил в CRM: ставите его автором, выбираете последнюю неделю работы и смотрите весь список действий. Никакого перебора карточек.

Фильтр по типу изменения полезен по другой причине. Среди пунктов есть просмотр и экспорт, то есть история фиксирует не только правки, но и то, что карточку открывали и что данные выгружали. Для компаний, где база клиентов остаётся главным активом, это первое, куда стоит заглянуть при подозрении на слив контактов.

Как найти историю одной сделки в общем журнале

Иногда удобнее не открывать карточку, а отфильтровать общий журнал по конкретной сделке. Например, когда нужно сравнить несколько элементов подряд. Для этого понадобится ID.

Найти ID проще всего в адресной строке браузера. Откройте карточку сделки и посмотрите на URL: он имеет вид /crm/deal/details/1234/, где 1234 и есть идентификатор. Скопируйте число, вернитесь в CRM → Ещё → История, укажите в фильтре тип элемента «Сделка» и вставьте ID в соответствующее поле.

Тот же ID пригодится, если вы обращаетесь в поддержку или к подрядчику по интеграции. «Посмотрите сделку 1234» это нормальная постановка задачи. «Посмотрите сделку с ООО Ромашка» уже нет, потому что одноимённых сделок в базе может быть десяток.

Что попадает в историю, а что нет

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

Что фиксируется:

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

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

Это особенно касается пользовательских полей, которые администратор добавил в карточку под задачи конкретной компании. Не считайте по умолчанию, что они ведут себя так же, как системные. Тест на пять кликов честнее любых предположений.

Кто из сотрудников что видит

Логика прав здесь простая и предсказуемая. Администратор Битрикс24 видит все изменения в истории CRM. Обычные сотрудники видят изменения только по тем элементам, к которым у них есть доступ.

Практический вывод для руководителя: не удивляйтесь, если менеджер говорит «у меня в истории пусто», а вы в том же разделе видите десятки записей. Скорее всего, у него просто нет прав на эти сделки. Обратная ситуация тоже показательна. Если рядовой сотрудник видит в общем журнале действия по чужим отделам, это повод пересмотреть настройки прав доступа в CRM, а не радоваться прозрачности.

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

Движение по стадиям: когда нужна не история, а отчёт

Отдельный класс задач звучит иначе: не «кто изменил», а «как долго сделки висят на каждой стадии и куда откатываются». Ковырять вкладку «История» вручную для этого бессмысленно, потому что вопрос статистический, а инструмент точечный.

Для таких задач в Битрикс24 есть отдельный REST-метод crm.stagehistory.list. Он возвращает историю движения элемента по стадиям. Метод принимает entityTypeId (тип сущности; для сделок это 2), filter, например по OWNER_ID конкретного элемента, order для сортировки и select с набором полей: ID, STAGE_ID, CREATED_TIME.

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

Разбор ситуации: сделка ушла в «Проиграна» без объяснений

Типовой ход расследования выглядит так. Пример условный, механика настоящая.

Понедельник, утро. Руководитель отдела видит в отчёте, что за выходные из воронки пропали три сделки на общую сумму около 12 миллионов тенге. Все три оказались на стадии «Проиграна». Менеджеры разводят руками.

Шаг первый: открываем одну из сделок, вкладка «История». Видим запись об изменении стадии, дату (воскресенье, вечер) и автора. Автор оказывается не менеджером, а сотрудником, у которого доступ к CRM формально есть, но задач в продажах нет.

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

Шаг третий: смотрим тип изменений. Кроме смены стадий в списке есть записи об экспорте элементов. Это уже совсем другой разговор, чем «сотрудник случайно кликнул не туда».

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

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

Когда штатной истории не хватает

Есть три ситуации, в которых вкладка «История» честно не решает задачу, и упираться в неё бессмысленно.

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

Вторая: история нужна регулярно и в виде отчёта. Смотреть карточки руками нормально один раз. Если вопрос «сколько сделок откатилось назад по воронке» задаётся каждый понедельник, нужен не журнал, а выгрузка через REST и таблица, которая обновляется сама.

Третья: история нужна как доказательство. Когда речь заходит о материальной ответственности или споре с сотрудником, скриншот вкладки становится слабым аргументом. Здесь имеет смысл заранее договориться с юристом о том, какая форма фиксации в вашей компании считается достаточной, и настроить процесс под неё, вместо того чтобы натягивать эту роль на интерфейс CRM.

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

Отдельно про удалённые сделки

Вопрос «а если сделку не изменили, а удалили» возникает почти сразу за вопросом про историю изменений, и это уже другой сюжет. Журнал изменений и восстановление удалённых элементов в Битрикс24 работают по-разному, путать их не стоит.

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

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

Что настроить, чтобы не расследовать каждый раз

История хороша тем, что отвечает на вопрос постфактум. Но если вы открываете её чаще раза в месяц, проблема не в истории, а в настройках портала. Вот что обычно закрывает вопрос надолго.

Начните с прав доступа. Большинство историй про «кто-то поменял сделку» заканчиваются тем, что этот кто-то имел на неё права, которых иметь не должен. Разграничение по ролям и отделам решает проблему до того, как она появится.

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

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

И наконец, дисциплина комментариев. Самая дешёвая мера и самая недооценённая. Строчка «клиент ушёл к конкуренту по цене» в таймлайне экономит потом полчаса чтения истории.

Все четыре пункта настраиваются штатными средствами, без разработки. Вопрос только в том, чтобы кто-то сел и сделал это осознанно, а не по остаточному принципу.

Частые вопросы

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

Почему я не вижу вкладку «История» в карточке сделки?
Состав вкладок карточки настраивается. Нажмите «Ещё» в строке вкладок, выберите «Настроить меню», верните нужную вкладку и нажмите «Завершить настройку».

Менеджер говорит, что в истории пусто, а я вижу записи. Кто прав?
Оба. Администратор портала видит все изменения в истории CRM, сотрудники только по тем элементам, к которым у них есть доступ. Разная выдача при одинаковом запросе здесь нормальна.

Видно ли в истории, что сотрудник просто открывал карточку или выгружал базу?
Да. Среди типов изменений есть просмотр и экспорт элементов, и по ним можно фильтровать общий журнал в разделе CRM → Ещё → История.

Как получить историю стадий по всем сделкам сразу, а не по одной?
Через REST-метод crm.stagehistory.list: он отдаёт записи о движении элементов по стадиям с полями ID, STAGE_ID и CREATED_TIME. Данные выгружаются в таблицу и уже там превращаются в отчёт по срокам и откатам.

Отличается ли история изменений в облаке и в коробке?
Логика работы вкладки и раздела одинаковая. Разница возникает на уровне серверной инфраструктуры и настроек конкретного портала, поэтому если вам нужен более глубокий аудит действий, чем даёт штатный журнал, задачу решают уже на стороне сервера и доработок.

Штатных инструментов хватает для большинства вопросов вида «кто изменил сделку в CRM»: вкладка «История» в карточке закрывает точечные случаи, раздел CRM → Ещё → История с фильтрами по автору и дате закрывает массовые. Проблемы начинаются там, где нужен аудит по полям, которые система не отслеживает, или регулярный отчёт по срокам стадий. Если вы упёрлись именно в это или просто не нашли нужную вкладку у себя на портале, наша техподдержка Битрикс24 на связи 24/7: разберёмся с настройками вашего портала и покажем, где смотреть.