Автосалон: своя АТС на 15 менеджеров и запись разговоров, которая остаётся у вас

MAATRIX

Отдел продаж автосалона живёт на телефоне: клиент звонит узнать про наличие цвета и комплектации, менеджер перезванивает по заявке с сайта, РОП сверяет, кто как отработал возражение «дорого» или «поеду смотреть к конкурентам». Запись разговора — не формальность для галочки, а рабочий инструмент контроля качества и разбора спорных ситуаций. Проблема в том, что при облачной АТС эти записи физически лежат на серверах провайдера связи — вы получаете доступ через личный кабинет, но не распоряжаетесь файлами напрямую. Ниже — как устроена альтернатива: своя АТС на своём сервере, где записи хранятся там, где решаете вы, а не оператор связи.

Почему запись звонков — это инструмент продаж, а не формальность

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

• Контроль скрипта и качества. Не «прогнал ли менеджер чек-лист», а конкретно — как он ответил на «а что с скидкой», предложил ли тест-драйв, зафиксировал ли контакт для повторного звонка.
• Разбор конфликтов. Клиент утверждает, что менеджер по телефону обещал определённую цену или комплектацию, которой в итоге не оказалось. Запись — единственное объективное доказательство, что было сказано на самом деле.
• Разбор потерянных лидов. Когда заявка с сайта или из рекламы не превратилась в визит, полезно прослушать сам звонок целиком, а не читать краткое резюме из CRM.

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

Что не так с записью разговоров в облачной АТС

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

Практически это выражается так:

• Записи физически лежат у провайдера. Вы их слушаете через веб-интерфейс или скачиваете по одной, но массово выгрузить весь архив, настроить свою схему резервного копирования или подключить к записям собственный анализ — обычно нельзя или сильно ограничено функционалом личного кабинета.
• Срок хранения задаёт тариф, а не вы. Провайдер сам решает, сколько дней или месяцев хранить звонки без доплаты — это его бизнес-модель, а не ваша политика хранения данных.
• Смена провайдера = риск потерять архив. Если через год решите перейти на другую АТС или другого оператора связи, исторические записи чаще всего останутся заблокированы в старом кабинете или их придётся спешно выгружать вручную, пока не закрыли доступ.
• Записи — это персональные данные. В разговоре звучит голос клиента, его телефон, иногда паспортные данные при обсуждении кредита или трейд-ина. Формально автосалон остаётся оператором персональных данных по 152-ФЗ, но физически данные обрабатываются на инфраструктуре третьей стороны, с которой у вас есть только договор оферты, а не прямой контроль. Разбор того, что это значит на практике, — в статье про 152-ФЗ и законное хранение персональных данных.

Ни один из этих пунктов не делает облачную АТС «плохой» — для многих компаний это разумный компромисс. Но если контроль над записями разговоров с клиентами для вас принципиален, разумно рассмотреть альтернативу.

Своя АТС: что меняется технически

Идея простая: телефонная станция разворачивается не в облаке провайдера, а на вашем собственном сервере — арендованном VPS или выделенном сервере. Дальше через оператора связи подключается SIP-транк (это стандартный способ получить внешние номера и городские линии для программной АТС), а 15 менеджеров работают через внутренние добавочные номера — с IP-телефонов или софтфонов на компьютере.

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

• В облачной модели запись пишет и хранит сервер провайдера.
• В своей модели запись пишет и хранит модуль записи вашей АТС, а файл сразу попадает на диск вашего сервера — в директорию, которую вы сами создали и которой сами управляете.

Базовая схема каталогов для записей обычно выглядит так — по годам и месяцам, чтобы архив не превращался в один каталог с десятками тысяч файлов:

/var/spool/pbx/recordings/
├── 2026/
│   ├── 08/
│   │   ├── 2026-08-28_manager07_+7920xxxxxxx.wav
│   │   └── 2026-08-28_manager12_+7910xxxxxxx.wav
│   └── 09/

Такое разбиение сразу упрощает две вещи: ротацию (архивировать и переносить в холодное хранилище можно целыми месячными папками) и права доступа (можно дать РОПу доступ только к папкам текущего квартала, а более старые архивы — только администратору).

Отдельный плюс — интеграция. Если помимо телефонии у вас уже есть своя система учёта сделок на сервере, запись можно автоматически прикреплять к карточке клиента по номеру телефона через веб-хук или скрипт, который срабатывает по завершении звонка. В облачной АТС такая интеграция обычно возможна только через API провайдера и в рамках того, что он разрешил.

Где физически хранятся записи и кто к ним имеет доступ

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

• Кто имеет доступ на уровне ОС. Только системный администратор и, при необходимости, отдельная учётная запись для выгрузки бэкапов — без общего пароля «на всех».
• Кто имеет доступ на уровне приложения. РОП и, возможно, руководитель салона слушают записи через веб-интерфейс АТС с индивидуальными логинами — это даёт журнал, кто и когда прослушивал конкретный звонок.
• Как разграничен доступ по ролям. Рядовой менеджер обычно не должен иметь доступ к записям коллег — только к своим. Это стандартная настройка ролевой модели в веб-интерфейсе АТС, а не что-то экзотическое.
• Где физически стоит сервер. Это отдельный вопрос юрисдикции: если на записях звучат персональные данные граждан РФ и на вас распространяется требование локализации по 152-ФЗ, сервер для основной обработки таких данных должен физически находиться на территории России. Если это требование к вашему бизнесу не применимо или вы обрабатываете данные, на которые локализация не распространяется, выбор локации сервера — вопрос удобства и задержки связи, а не закона. Точный разбор — в той же статье про 152-ФЗ, ссылка выше.

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

Сколько ресурсов это реально требует

Хорошая новость: сама программная АТС на 15 добавочных номеров — не тяжёлая нагрузка. Это не база данных с миллионами транзакций и не рендеринг видео. Обработка голосового трафика для полутора десятков одновременных разговоров комфортно укладывается в пару виртуальных ядер и несколько гигабайт оперативной памяти с большим запасом. Основной ресурс, который реально «съедается» со временем, — дисковое пространство под архив записей.

Чтобы прикинуть объём, полезно знать один реальный технический факт: стандартный телефонный кодек G.711, который чаще всего используется в SIP-телефонии из-за своей универсальности, кодирует голос с битрейтом около 64 кбит/с. Это значит, что одна минута разговора в этом кодеке занимает примерно 480 КБ. Если использовать более сжимающие кодеки, файлы будут в разы меньше, но это уже настройка конкретной АТС и договорённость с оператором связи о том, какие кодеки поддерживает SIP-транк.

Дальше — просто формула, а не готовая цифра, потому что нагрузка у каждого салона своя:

объём_в_день = число_менеджеров × среднее_число_звонков_на_менеджера ×
               средняя_длительность_звонка_в_минутах × 480 КБ

объём_архива = объём_в_день × срок_хранения_в_днях

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

Пусть у вас 15 менеджеров, и предположим, что в среднем на менеджера приходится условное число звонков в день продолжительностью в несколько минут каждый. Даже при заведомо щедрых предположениях суммарный объём в день у одного салона обычно измеряется сотнями мегабайт, а не десятками гигабайт — телефония в аудиоформате «весит» не так много, как видео с камер или фотографии автомобилей. Хранить записи даже за год-два на своём сервере — задача, которая упирается не в объём диска, а в организацию архива и резервного копирования.

Резервное копирование и организация архива

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

• Ротация по месяцам. В конце месяца архив записей упаковывается и переносится в отдельное хранилище — либо на другой диск того же сервера, либо (лучше) на отдельный сервер бэкапов.
• Шифрование архива. Поскольку в записях звучат персональные данные, архив имеет смысл шифровать перед переносом на внешнее хранилище.
• Проверка целостности. Периодически стоит проверять, что архивные файлы действительно читаются и воспроизводятся, а не просто лежат «для галочки».

Пример скрипта, который упаковывает записи за прошедший месяц и шифрует архив (концептуальный пример — под вашу АТС пути и имена нужно адаптировать):

#!/bin/bash
# monthly-archive.sh — упаковка и шифрование записей за прошлый месяц
MONTH=$(date -d "last month" +%Y/%m)
SRC="/var/spool/pbx/recordings/$MONTH"
DST="/backup/pbx-archive/$(date -d "last month" +%Y-%m).tar.gz.enc"

tar -czf - "$SRC" | \
  openssl enc -aes-256-cbc -pbkdf2 -salt -pass file:/root/.archive-key \
  -out "$DST"

echo "Архив за $MONTH сохранён: $DST"

Такой скрипт удобно поставить в cron на первое число каждого месяца, а /backup/pbx-archive/ синхронизировать на отдельный сервер бэкапов — чтобы сбой основного сервера с АТС не означал потерю истории звонков за прошлые месяцы.

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

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

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

Что вы теряете, отказываясь от облачного провайдера

Честно: своя АТС — это не только плюсы, и важно понимать, что вы берёте на себя.

• Обслуживание становится вашей задачей. Обновления, патчи безопасности, мониторинг доступности — всё это раньше делал провайдер как часть услуги, теперь этим занимаетесь вы или подрядчик на аутсорсе.
• Отказоустойчивость нужно строить самим. Если сервер с АТС выходит из строя, звонки перестают проходить — если заранее не настроен резервный сценарий (например, переключение SIP-транка на резервный маршрут или временная переадресация на мобильные номера менеджеров на время восстановления сервера).
• Нужны минимальные компетенции в администрировании. Развернуть и поддерживать программную АТС может штатный айтишник или подрядчик, но это уже не «просто зарегистрировался и работает» — есть входной порог.
• SLA теперь ваш, а не провайдера. У коммерческого облачного провайдера обычно есть договорные гарантии доступности. На своей инфраструктуре доступность — это то, что вы сами спроектировали и мониторите.

Для салона с 15 менеджерами, где звонки — ежедневный производственный процесс, эти издержки обычно окупаются: контроль над записями разговоров и отсутствие растущей абонентской платы за каждое место перевешивают затраты на администрирование. Но если у вас два-три менеджера и звонков немного, содержать отдельный сервер под АТС может быть избыточно — тогда облачное решение остаётся разумным выбором.

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