Удалили сделку или контакт в CRM: что сделать до попытки восстановления

Поспешное восстановление способно затронуть чужую работу

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

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

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

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

До разбора полезно остановить тот процесс, который продолжает удалять записи: импорт, интеграцию или массовую операцию, если именно он связан с происшествием. Это решение принимают ответственные вместе с администратором. Произвольная остановка всей работы компании не требуется, но продолжающееся изменение данных усложняет понимание масштаба и выбор момента восстановления.

Пустая корзина сотрудника не равна пустой корзине портала

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

Удалённые карточки ищут в CRM, открыв «Ещё», затем «Корзина». Нужную запись можно найти по её ID — уникальному номеру элемента.

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

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

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

Срок в корзине не стоит превращать в обещание сохранности

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

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

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

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

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

Возвращённая запись получает новый идентификатор

Возвращённую карточку придётся искать по новому адресу. Битрикс24 указывает, что после восстановления из корзины ID меняется, а прежняя ссылка больше не открывает элемент. Для отдела продаж это касается сохранённых ссылок на контакт или сделку: карточка уже вернулась, но переход из задачи или письма ведёт к старому адресу. Менеджеру понадобится новая ссылка, а специалисту по обмену — связь прежнего номера с восстановленной записью. Эти адреса передают тем, кто использует их в работе, чтобы возврат данных действительно позволил продолжить продажу.

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

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

Я бы передал восстановленную карточку на приёмку тому, кто ведёт клиента. Администратор подтверждает техническую доступность, а менеджер лучше заметит отсутствие существенного условия или неправильную связь. Менеджер перечислит, какие сведения нужны для продолжения разговора и чего пока не хватает.

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

Резервная копия возвращает портал, а не одну карточку

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

Полный откат касается всех сотрудников. Данные возвращаются к выбранной дате, а последующие изменения удаляются.

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

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

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

Поддержке нужен состав потери, а команде — план проверки

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

Подходящая копия предшествует нежелательному изменению. Самая свежая доступная дата может уже включать ошибку.

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

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

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

После возврата данных остаётся причина удаления

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

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

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

Для разбора ситуации в Битрикс24 с ШТАБ ИТ пригодятся время, типы объектов и сведения о корзине без паролей и ключей. Сначала выбирается минимальный способ возврата, затем отдел принимает вернувшиеся данные, а специалист устраняет причину потери. Полный откат остаётся осознанным решением о данных всей компании, а не первым действием из-за одной пропавшей сделки.