Some time ago, we decided to launch our video surveillance service for those customers who wanted to quickly get a ready-made infrastructure. Some of our end users wanted to connect the cameras to the cloud, and not to the local DVR, and we didn’t have something to offer them yet. Besides, we were approached by large telecom operators with a request to demonstrate the operation of the solution from the moment of purchasing the camera to the moment of debiting money from a bank card for using the video surveillance service. We needed a base for such a demonstration. As a result, we prepared a distributed network of servers, installed our software on them, and started connecting subscribers to it.
Initially, we set a fixed cost for using our cloud, but then it turned out that this did not work as some customers were profitable at the set price, and some are not. We had to do something about it.
First of all, we tried to consider the statistics of resource consumption and to bill based on how much of the footage the camera recorded for each individual customer. It was a very time-consuming job that clearly needed to be automated. In addition, for new customers, we began to offer individual rates, which also led to the emergence of new tasks to ensure settlements with customers. It became obvious that we needed to connect a billing system.
There were already well-known solutions with integration APIs on the market that we could try for ourselves, and we decided to start with this. We conducted many tests and identified problems that could not be solved:
● No cameras in the ready-made billing system. The fee is associated with cameras, and cameras form billing units for which the subscriber pays a monthly fee, so billing cannot function without such an essential detail.
● Inability to configure adaptable billing for different access levels. By launching a video surveillance cloud, we identified three access levels: system administrator, customer cloud administrator, and customer cloud subscriber. For each of these three levels, billing must be adapted primarily in terms of the information displayed.
No matter how hard we tried, we could not solve these significant problems for us with the help of ready-made solutions. After about two months of trying, we came to a simple solution: create our own billing system adapted to our business processes. Our team could do it, and, most importantly, we knew exactly what we needed from billing. Considerable time has passed since then, and now we are actively using our own billing.
Our Billing Features
We have built a hierarchical system of access levels with corresponding billing options.
So, billing administrators can:
● Create services for our customers. A “service” is considered the feature of the service that we provide - for example, “1 day of motion-activated recording” or “video analytics for 1 channel”. Then telecom operators can combine the services received from us into tariff plans for their subscribers. For example, “7 days of recording traffic and capturing car license plates with a fixed monthly cost” is a custom tariff plan created by a customer. This tariff is based on the “1 day of recording” service multiplied by 7, with an additional fee for reading car license plates.
● Create a cloud for the customer by specifying their username and selecting affordable rates. For each cloud, we can set discounts, appoint a responsible manager, monitor usage history, add users, cameras, tariffs, and so on.
● Receive a report on the resources used and services provided, calculated automatically by the consumption of the services provided on each individual camera.
● Manage the system user list. We can add our new administrators, accountants, and managers to the billing system. Each type of user will have access to a particular functionality.
● Access a dashboard with current customer billing metrics
The cloud administrator can:
● Create tariff plans for subscribers, combining the services provided by the service administrator.
● See and manage the cloud subscriber list.
● Create accounts for subscribers and assign responsible account managers.
● Receive reports for each subscriber to prepare invoices for payment or transfer data to the payment gateway.
The subscriber themselves get the opportunity to see usage reports, which form the basis of the invoice issued by the operator.
In addition to these three categories, we introduced another one - referrals. This category cannot be found in any other billing system. The referrals are needed if the operator wants to increase their sales by attracting new customers, but does not want to add new employees. Referrals are third party agents who will bring new customers to operators for a percentage of sales. In billing, they can:
● Create accounts for subscribers.
● See a list of their created accounts.
● See consumption statistics for created subscribers and the amount payable for the period.
In the future, the referral system will be further developed, additional levels will be added, and our customers will be able to build their own effective multi-level marketing structures that will bring additional profit.
We did the most difficult work and took into account all the nuances of the interaction of billing with our Flussonic Watcher, and now we are preparing an API for additional integration with customer’s billing, if necessary. And now we are happy to share our experience and test the capabilities of our billing system. Just write to us for access.
Aleksey Yurchenko Product owner Flussonic Watcher