Запись групповых звонков: зачем нужна и где хранится

Запись группового звонка нужна как доказательство договорённостей: кто что обещал клиенту, поставщику или подрядчику. Хранится она там, где решил администратор мессенджера, — на локальном диске, в облаке сервиса (обычно 30–90 дней, потом файл удаляется автоматически) или на собственном сервере компании, откуда запись можно привязать к сделке в 1С.

зачем компании нужна именно запись, а не протокол встречи

Протокол фиксирует итог, запись — процесс. На созвоне закупочного комитета из 8–12 человек решение почти всегда рождается из спора: кто-то настаивал на скидке, кто-то — на сроке поставки, а в итоговый протокол попадает уже согласованная формулировка без нюансов. Через два-три месяца, когда стороны трактуют эту формулировку по-разному, поднимают именно запись, а не протокол.

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

Практических причин хранить запись обычно четыре:

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

🕵️ как теряется запись: типичный сценарий на 1,4 млн рублей

Отдел закупок компании из Москвы созванивается с поставщиком по видео в корпоративном мессенджере — 11 участников, обсуждают скидку 8% на партию комплектующих и срок поставки в 45 дней. Звонок записан автоматически, файл лежит в облаке мессенджера. Сделку заключают, работа идёт.

Через четыре месяца поставщик присылает счёт без скидки — говорит, что 8% обсуждались «предварительно» и в договор не вошли. Юрист компании поднимает переписку, но там только резюме встречи из трёх строк. Он идёт за записью звонка — но в мессенджере стоит стандартный срок хранения 30 дней, и файл давно удалён.

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

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

где хранится запись: три варианта и разница в контроле

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

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

✅ пять признаков, что хранение записей настроено неправильно

Проверить своё положение можно за пять минут — без опроса ИТ-отдела.

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

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

как привязать запись звонка к карточке сделки в 1С

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

1. ✓в мессенджере включают вебхук на событие «звонок завершён и запись готова»;
2. ✓в 1С разворачивают HTTP-сервис, который принимает ссылку на файл и идентификатор участников звонка;
3. ✓ссылку прикрепляют к документу сделки или взаимодействия — она видна в карточке клиента вместе с историей переписки;
4. ✓для документа настраивают срок хранения и права доступа по ролям — например, запись видит руководитель отдела, но не рядовой менеджер конкурирующего направления;
5. ✓перед продакшеном интеграцию проверяют на одном реальном звонке, а не сразу на всём отделе.

push или pull: как мессенджер отдаёт запись

Здесь два технических сценария, и от выбора зависит, сколько правок потребуется в 1С. При push-модели мессенджер сам присылает вебхук с готовой ссылкой сразу после окончания звонка — интеграция получается компактной, обычно в пределах одного HTTP-сервиса. При pull-модели 1С должна периодически опрашивать API мессенджера и проверять, не появились ли новые записи, — это на порядок больше кода и риск пропустить звонок, если опрос настроен реже, чем компания успевает провести созвонов. Перед тем как заказывать доработку, стоит уточнить у поставщика мессенджера, какая модель у него реализована — от этого зависит и срок работ, и её стоимость.

На старых редакциях — например, 1С:Управление торговлей 10.3 — HTTP-сервисов может не быть вовсе, тогда доработку блокирует не мессенджер, а версия учётной системы: сначала нужно обновление 1С, и только потом интеграция с записями звонков. Саму доработку — приём вебхука и привязку к карточке сделки — делает доработка 1С. Если сделки пока вообще не ведутся в 1С, а живут в почте и таблицах, разговор о привязке записи преждевременный: сначала нужна сама CRM-часть, обычно через внедрение 1С:Управление торговлей для торговых компаний или внедрение 1С:ERP для производства.

что говорит 152-ФЗ о голосе участников — и где компании ошибаются

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

Парадокс в том, что бизнес боится удалить запись слишком рано — и в ответ настраивает бессрочное хранение на своём сервере. Это тоже нарушение 152-ФЗ, только зеркальное: раз цель хранения — разбор спора по сделке, срок логично привязывать к сроку исковой давности (обычно 3 года по ГК РФ), а не хранить записи звонков пятилетней давности без единого повода.

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

сколько стоит организовать хранение звонков правильно

Отдельный сервер для хранения записей и работы 1С обходится от 3300 руб/мес — это дешевле, чем один сорванный спор по сделке из-за удалённого файла. Настройку регламента хранения, прав доступа по ролям и первичную привязку интеграции обычно закрывает разовая доработка, а дальнейшее сопровождение — работа 1С-администратора или системного администратора от 3800 руб/час: раз в квартал он проверяет, что старые записи действительно удаляются по регламенту, а не копятся вечно.

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

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

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

Сколько по умолчанию хранится запись группового звонка в мессенджере?

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

Можно ли хранить запись звонка вечно, чтобы точно не потерять?

Формально да, технически препятствий нет, но по 152-ФЗ хранить персональные данные дольше цели обработки нельзя — это тоже нарушение, только зеркальное. Разумный ориентир — срок исковой давности, обычно 3 года по ГК РФ, после чего звонок можно и нужно удалить из архива.

Нужно ли предупреждать участников о записи группового звонка?

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

Что дешевле: хранить записи в мессенджере или на своём сервере?

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

Сколько занимает интеграция записи звонков с 1С?

Зависит от того, push- или pull-модель реализована у мессенджера, и от версии 1С — на старых редакциях вроде УТ 10.3 сначала нужно обновление системы. Точный срок и стоимость доработки определяются по техническому заданию после разбора конкретного мессенджера и его API.