Как мы запускали свой биллинг

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

Изначально мы установили фиксированную стоимость за пользование нашим облаком, но потом оказалось, что это не работает: какие-то клиенты приносили нам прибыль при данной стоимости, а какие-то при ней же приносили убытки. С этим нужно было что-то делать.

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

На рынке уже были известные решения с API для интеграции, которые мы могли бы попробовать для себя, и с этого мы решили начать. Мы провели много тестов и выделили проблемы, которые никак не удавалось решить:

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

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

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

Возможности нашего биллинга

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

Так, Администраторы биллинга могут:

• Создавать услуги для наших клиентов. Услугой считается возможность сервиса, которую мы оказываем - например, “1 день записи с камеры по движению” или “видеоаналитика 1 канала”. В дальнейшем операторы связи могут комбинировать услуги, получаемые от нас, в тарифные планы для своих абонентов. Например, “7 дней записи по движению с определением автомобильных номеров на камере с фиксированной стоимостью в месяц” - это кастомный тарифный план, созданный клиентом. В основе данного тарифа лежит услуга “1 день записи”, помноженная на 7, к чему прибавлена дополнительная услуга распознавания номеров.

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

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

• Управлять списком пользователей системы. Мы можем добавлять своих новых администраторов, бухгалтеров и менеджеров в биллинг. Каждый из типов пользователей будет иметь доступ к той или иной функциональности.

• Видеть dashboard с текущими показателями развития клиентов в биллинге

Администратор облака может:

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

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

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

• Создавать аккаунты абонентам.
• Видеть список своих созданных аккаунтов.
• Видеть статистику по потреблению у созданных абонентов и сумму к оплате за период.

В дальнейшем реферальная система будет развиваться, будут добавляться дополнительные уровни, и наши клиенты-операторы смогут строить собственные эффективные структуры многоуровневого маркетинга, которые будут приносить дополнительную прибыль.

Мы сделали самую тяжелую работу и учли все нюансы взаимодействия биллинга с нашим Flussonic Watcher, и сейчас готовим API для дополнительной интеграции с биллингом клиента, если это требуется. А сейчас мы рады поделиться своим опытом и дать протестировать возможности нашего биллинга - достаточно написать нам и получить доступ.