Forward Обсудить проект

Биллинг в телекоме: как устроен и как его выбирают

· обновлено

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

Слово «биллинг» встречается и в настройках телефона, и в тендерах на сотни миллионов рублей. В первом случае это техническая настройка передачи данных, во втором — расчетный контур оператора связи. Здесь речь про второй.

Как устроен расчетный контур

За тем, что абонент воспринимает как мгновенное списание или счет в конце месяца, стоит цепочка из нескольких систем.

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

Медиация. Система Forward MD собирает CDR из разрозненных источников, отсеивает служебные и ошибочные записи, приводит форматы к единому и обогащает данными для тарификации. Без этого шага биллинг получал бы поток в десятках несовместимых форматов вместе с дублями и ошибками.

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

Управление балансом. Для предоплатной модели списание идет в реальном времени через Forward Fusion. Для кредитной — накопительно, с выставлением счета по итогам расчетного периода.

Счета и оплата. Forward Billing формирует счета, инициирует автоплатежи, передает данные в бухгалтерию и регуляторные выгрузки.

Для предоплатного звонка весь цикл от поднятия трубки до авторизации соединения занимает доли секунды. Это операционное требование: задержка онлайн-тарификации свыше 200–300 мс становится заметной абоненту.

Что входит в биллинг оператора

Модуль Что делает Продукт
Медиация Сбор, фильтрация и обогащение событий сети Forward MD
Тарификация Применение тарифных правил к событию Forward Billing
Онлайн-тарификация Списание в реальном времени для предоплаты Forward Fusion
Лицевые счета и балансы Начисления, задолженность, кредитный лимит Forward Billing
Продуктовый каталог Источник правил: что и по какой цене считать Forward PC
Счета и документы Конструктор счетов, закрывающие документы Forward Billing
Выгрузки 1С, СОРМ, ЭДО, Финмониторинг Forward Billing
Расчеты с партнерами Вознаграждения дилерам и агентам Forward PRM

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

Конвергентный биллинг

Исторически оператор держал отдельную систему под каждый тип услуги: одну под голос, другую под интернет, третью под телевидение. Абонент при этом получал несколько счетов, а оператор не мог собрать пакетное предложение, не написав интеграцию между своими же системами.

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

Подробнее про модели расчетов и балансы — на странице Forward Billing и в статье о конвергентном биллинге.

Кому нужен биллинг

Операторы связи и виртуальные операторы остаются основными пользователями: максимальный объем транзакций, сложные тарифы, жесткие требования к реальному времени.

Помимо них расчетный контур нужен медиа и контент-сервисам с подписками, операторам фискальных данных, работающим с тысячами юридических лиц, и компаниям с оплатой по потреблению в финтехе и SaaS. Проекты Forward это подтверждают: РБК с подписочной моделью, Первый ОФД с базой более 250 000 компаний, Chat2Desk с унификацией тарификации.

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

Как выбирают биллинговую систему

Реестр отечественного ПО. Для компаний в периметре импортозамещения это отправная точка, а не пожелание. Проверяется наличие конкретного продукта в реестре, а не вендора вообще.

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

Производительность и масштабирование. Биллинг крупного оператора обрабатывает миллиарды событий в сутки. Важно и то, как система растет: горизонтальное масштабирование без остановки сервиса отличается от «поставьте сервер помощнее».

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

Интеграции. Биллинг не работает изолированно: CRM, ERP, бухгалтерия, платежные шлюзы, оборудование сети. Отсутствие готовых коннекторов превращается в отдельный бюджет разработки.

Модель поставки. On-premise, облако или managed services. Выбор чаще определяют требования безопасности и готовность держать собственную команду эксплуатации.

Условия сопровождения. SLA, локальная поддержка, дорожная карта продукта. Внедрение растягивается на годы, и вендор становится долгосрочным партнером независимо от того, планировалось это или нет.

Разбор стоимости владения и окупаемости — в статье о внедрении биллинга в цифрах.

Что делать с устаревшим биллингом

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

Замена идет по понятной методике: инвентаризация контура, перенос тарифов и истории расчетов, параллельная работа двух систем со сверкой на реальных данных и переключение в объявленное технологическое окно. Порядок работ и риски разобраны на странице импортозамещения BSS/OSS.

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

Место биллинга в общем контуре оператора описано на странице BSS/OSS для оператора связи.

Вопросы и ответы

Чем биллинг отличается от CRM?

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

Что такое CDR?

CDR (Call Detail Record) — запись о конкретном событии в сети: звонке, SMS, сессии передачи данных. Содержит время, длительность, объем и идентификаторы сторон. CDR — исходный материал для тарификации, и качество расчетов напрямую зависит от того, насколько корректно эти записи собраны и обработаны.

Нужна ли биллинговая система виртуальному оператору?

В моделях Medium и Full — да, это один из первых модулей при проектировании контура. В агентских моделях расчеты ведет хост-оператор, и собственный биллинг не нужен. Переход между моделями обычно и означает появление собственного биллинга.

Что такое биллинг в настройках телефона?

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

Сколько занимает замена биллинга?

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

Кому нужен биллинг помимо операторов связи?

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