Из чего складывается годовая цена офисной телефонии

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

Своя АТС: что входит в расходы за год

Когда мне говорят «поставим Asterisk, он бесплатный», я уточняю, что именно уже есть у компании: подходящий узел, питание, сеть, резервные копии и человек, который возьмёт систему на поддержку. Лицензия на Asterisk не равна цене готовой телефонной службы. Для небольшого офиса я начинаю с аудита ИТ-инфраструктуры: фиксирую число абонентов, пиковое число одновременных разговоров, внешние номера, маршруты и требования к отказу. Без этого смета похожа на чек из магазина, где покупатель забыл список покупок.

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

В базовом Asterisk есть инструменты учёта вызовов CDR: запись может содержать, кто звонил, кто ответил и сколько длился разговор. Это полезная телеметрия, но готовую тарификацию для выставления счетов она сама по себе не создаёт. Отдельно проектируют правила расчёта и сверяют их с договором оператора. Для записи аудио в Asterisk предусмотрено приложение MixMonitor; сами файлы требуют места, ограничений доступа, срока хранения и резервного копирования. Бесплатная запись на диске не становится бесплатной, если диск переполнен или разговоры потерялись.

Не закладывайте платные модули «на всякий случай». Asterisk распространяется по открытой лицензии, а расходы на конкретный кодек, интеграцию или дополнительный продукт зависят от того, что выбрано и как это лицензируется. Шифрование, запись и CRM-интеграция не превращаются автоматически в обязательные платные надстройки. Сначала составьте перечень нужных функций, затем проверьте возможности выбранной сборки и условия её компонентов. Иначе в смете появится строка с громким названием и нулевой пользой.

Есть ещё труд инженера. Время уходит на настройку маршрутов, проверку качества речи, добавление сотрудников, обновления, разбор проблем с оператором и восстановление после ошибки. Я отдельно считаю плановые работы и аварийные часы: если их смешать, поддержка выглядит «почти бесплатной». Ни RAID, ни копия конфигурации не заменяют проверку восстановления; в бюджете нужно учитывать саму процедуру и человека, который её выполнит. Для своего узла я также заранее назначаю ответственного за изменения, чтобы телефонный план не зависел от памяти одного сотрудника.

Для записей я считаю не только диск. На объём влияют длительность разговоров, формат аудио и срок хранения; отдельно нужны права на прослушивание и понятный порядок выгрузки. Сначала выясняю, кто использует записи и для какой рабочей задачи, затем выбираю объём и правила доступа. Если архив нужен для разбора обращений, его нельзя бездумно держать на том же узле, где работает АТС: отказ одного хранилища тогда лишит компанию и звонков, и архива. Это уже вопрос архитектуры и восстановления, а не галочка «запись включена».

• Телефоны, узел и сетевое питание
• Настройка, номера и интеграции
• Тариф оператора и стоимость разговоров
• Поддержка, обновления и резервное копирование
• Хранение записей и контроль доступа

Облачная АТС: за что берут абонентскую плату

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

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

Связь в облако всё равно приходит через сеть офиса. При потере канала сотрудники могут лишиться доступа к телефонии, а задержки и потери пакетов портят звук. Wi-Fi не всегда виноват, но радиоэфир меняется от помех и нагрузки; важны измерения на рабочих местах, а не уверенность, что «интернет быстрый». Для критичных разговоров я проверяю проводные точки, качество локальной сети и резервный способ принять вызов. А линию и тариф оператора считаю отдельно: полезно заранее разобраться, как устроены SIP-транки и IP-телефония.

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

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

• Абоненты или каналы
• Номера и исходящие вызовы
• Записи, хранение и интеграции
• Интернет и резервный доступ
• Поддержка по договору

Как посчитать год для условной сети «Юпитер-Плюс»

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

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

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

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

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

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

Когда собственная АТС оправдана

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

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

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

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

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

Как перейти без потери звонков и времени

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

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

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

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

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

• Соберите текущие сценарии звонков
• Запустите пилот и проверьте звук
• Испытайте резервный маршрут
• Зафиксируйте ответственных и план возврата
• Сверьте счёт после запуска

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