Сравниваю телефонию для офиса на 30 сотрудников

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

Сначала разделим услугу и оборудование

Когда говорят «подключим SIP-транк», часто смешивают две вещи: услугу оператора и АТС, которая распределяет звонки внутри компании. Транк — виртуальное соединение между АТС организации и оператором связи. По нему проходят вызовы; правила очередей, голосовое меню, внутренние номера и сценарии переадресации живут на стороне АТС. В документации Asterisk транк настраивается как подключение к оператору, а стандарт SIP описывает установление, изменение и завершение сеанса связи. Это не коробка с готовой телефонией и не самостоятельная замена АТС. Если требуется помощь с инфраструктурой, мы оказываем ИТ-аутсорсинг для офиса. Для общего разбора терминов пригодится статья о SIP-транках и IP-телефонии.

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

Для сравнения я фиксирую границы ответственности на бумаге. Кто выдает номера? Кто проверяет доступность АТС? Кто разбирает односторонний звук? Кто хранит записи и сколько? Кто меняет схему очереди? В облаке часть ответов будет в договоре и тарифе, при собственной АТС — в смете на сопровождение. Формулировка «всё включено» не отвечает ни на один из этих вопросов.

• SIP-транк связывает АТС с оператором.
• АТС управляет внутренней логикой вызовов.
• Облако переносит обслуживание платформы провайдеру.

Как считать расходы для 30 сотрудников

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

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

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

Сравнение получается честным, если обе модели считают одинаковые объемы: те же номера, нагрузка, исходящий трафик, срок хранения, интеграции и режим поддержки. Я не закладываю универсальную «экономию 50–75 процентов»: это не прогноз для конкретной компании. Цены операторов, структура звонков и нужные функции различаются. Беру две реальные коммерческие сметы и подставляю в них одинаковые требования. Так скучнее для презентации, зато полезнее для бюджета.

• Плата за платформу и каналы.
• Номера и исходящий трафик.
• Запись, хранение и интеграции.
• Сервер, поддержка и резервирование.
• Разовые работы и обучение.

Где возникают потери: каналы, тарификация, функции

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

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

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

Четвертая зона — сбой и восстановление. Облако уменьшает объем работ с сервером, но не устраняет зависимость от провайдера и доступа в интернет. Своя АТС не делает компанию независимой от оператора связи. Для обеих моделей нужны понятные контакты поддержки, схема эскалации, резервный способ принять важный звонок и проверенная процедура возврата к штатной работе. В SLA смотрю на точное определение доступности и исключения, а не на крупный процент в заголовке.

С безопасностью та же приземленная логика. Учетные данные телефонов и транков нельзя оставлять с простыми паролями и без контроля доступа; исходящие направления стоит ограничивать необходимыми правилами. У SIP есть механизмы аутентификации, но сам факт использования протокола не означает, что конкретная АТС настроена безопасно. Я проверяю, кто может менять маршруты, как быстро отключается учетная запись уволенного сотрудника и кто получает уведомление о необычных исходящих звонках.

• Проверьте пик одновременных вызовов.
• Сверьте детализацию с правилами тарифа.
• Получите полный список платных функций.
• Зафиксируйте поддержку и план восстановления.

Что показал разбор «Орион-Строй»

В исходном примере фигурировали сеть «Орион-Строй», 30 сотрудников, 15 линий, план роста до 20, а также годовые суммы 156 000 и 264 000 рублей. Для этих сумм не было расшифровки тарифа, объема звонков, цены записи, стоимости поддержки и исходных предложений поставщиков. Разницу в 108 000 рублей нельзя проверить арифметикой: неизвестно, из каких расходов она сложилась. Поэтому я не выдаю ее за результат реального проекта и не оставляю как доказательство преимущества одного варианта.

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

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

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

• 30 сотрудников — заданное условие.
• 15 каналов — проверяемая гипотеза.
• 20 каналов — сценарий роста, не факт.
• Годовую экономию без счетов не публикуем.

Как выбрать и перейти без сюрпризов

Перед выбором я фиксирую требования: номера, внутренние пользователи, очереди, расписание, переадресации, запись, интеграции и ожидаемый пик звонков. Затем проверяю совместимость существующей АТС и телефонов с выбранным оператором. В документации Asterisk есть отдельные схемы подключения к оператору через PJSIP; конкретная настройка зависит от версии, способа регистрации и требований провайдера. Универсального фрагмента конфигурации для всех транков нет, поэтому копировать первый попавшийся пример в рабочую систему — плохой способ экономить время.

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

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

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

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

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

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