How is billing done there: when a customer and a developer speak different languages
Since 2006, we are engaged in billing systems. In total - more than 12 years. We started to work from the television market, now among our customers there are banks, mobile operators, and Internet TV providers. The billing system itself evolved from a more or less simple solution for television to a full-fledged convergent billing with the possibility of using a prepaid scheme. And during this time we managed to fill a lot of cones, both in terms of implementation and support for billing. Often, errors occur because the customer does not know the “materiel”, and the developers of the billing do not understand the concerns and needs of the client.
Billing systems for a long time not just keep the balance of the client and invoice. They are deeply integrated into the business: they provide traffic control, manage the procedure for providing access to services, provide the client with a report on expenses in different sections - for a month, for a year, since the last payment. Plus, the billing system, as a rule, should support a lot of user balances: monetary and some real (bonuses, minutes of conversation, gigabytes of traffic, etc.). Not to mention affiliate programs and other cross-selling options. What is called modern convergent billing. It is implemented due to the integration of the tarifficator with other modules and subsystems: CRM, PRM, BPM, etc. For developers, this is not “intimate” knowledge. As they say, divide the functions and conquer. But for billing users,
An example from our practice. The client is a small but promising company. They did not have enough budget for the billing complex entirely, they asked to remove the BPM (business process management) module. It is necessary to pay tribute, the guys who were quite advanced in the technical sense worked there. They said they would take the open source solution, set up, integrate with the system. We agreed. And after four months, they “drowned” in their appeals to tech support for incorrect data.
BPM is a system that, among other things, when a subscriber is connected, deals with data validation, and does not let you go to the next step until you fill in all the necessary parameters - technical and personal. And they refused BPM, and simply drew an interface for data entry. People who accept applications for connection are not highly paid specialists, there is a big turnover there, a short staff training time. Naturally, they constantly made mistakes when entering data. The result - at the end of the month, the company bills, and the caller lacks the parameters. He “swears”, gives error messages. Customer calls in support. In the end, we made the decision to give them BPM in default settings. Everything began to converge with them, and our technical support had less headache. Now we don’t sell billing without BPM, except when it is already implemented and there are options for integration with it. If the client does not have enough money for the minimum required set, we offer rent or lease with the possibility of redemption in five years. Or, if this is some kind of startup, but it is clear that people are serious about the business and they have prospects, we offer a scheme with a rhubarb. In any case, it protects the nerve cells of both us and the management of the client company.
The ill-conceived architecture of the billing system turns around not only technical failures. In our experience, in 70% of cases, the need to replace billing arises due to its insufficient marketing flexibility. The telecom market is now oversaturated, and companies can only get new customers by defeating them from competitors. Even major providers, mastering new niches and expanding the territory of presence, begin to dump, and even the new players on the market “God himself ordered” to attract attention with unique offers. A real war of tariffs is unfolding. And then marketers are clutching their heads: “We will be able to put your new innovative tariff“ Super-New Year ”into sales only by July,” a message from the IT department comes.
What is the problem. In a very small number of billing systems there is, for example, a separate product catalog, which makes it easy to combine services into packages and set up promotions. The parameters with which he operates can be both services and individual parameters such as talk minutes, traffic packages or services offered by partners (so-called third-party services), such as movie tickets or taxi rides. There is an opinion that the product catalog is generally an element of a CRM system, and not billing. But even if it is so, not all companies have a separate CRM. Many subscribers are serviced directly in the billing system. And this means that any new service, new tariff, new action - and “IT people” need not to collect it in the designer, but to add fields and write lines of code. July is just around the corner.
True, marketers usually do not understand what the vendor has in mind, saying that his system is “quite flexible”. Enough for what? "Komersantov" primarily interested in time-to-market, the time required to release the service to the market. Once representatives of a client - a regional operator, in whose region federal players came - directly to the presentation meeting brought us descriptions of 3 cases of competitors that they could not implement at home. They put the question bluntly: for how long can you configure on your system? It’s not a sin to boast - we set up one case in a test environment right in front of them while the presentation was on. In general, with a well-designed billing architecture, any and using the product catalog, any package or share can be customized and brought to the market in 2-3 days, not counting the marketing and functional testing time. Check whether this is a specific billing, it is better at the stage of dating. Because there are cases when setting up a new tariff in a “fairly flexible” system actually takes several months.
Similar problems in terms of marketing and sales are faced by large companies, which have grown due to the absorption of regional operators. Different billing systems in the branches do not allow, for example, to launch large-scale actions all over the country. Reporting and analytics suffer: it is simply impossible to collect data on connections and use of services from all of these disparate systems. A partial solution to the problem is an umbrella CRM, in which there is a product catalog. Some companies do that - they trade from CRM, and they charge for billing. For this, the company must have a really advanced IT department. Integrating billing systems written in different languages and on different principles with a single CRM is not an easy task.
But there is one eternal problem that distributed systems cannot solve - this is a banal fraud in the field. We had several such examples. In particular, in Ukraine, where we implemented centralized billing, transferring data from recently acquired regional branches. When we migrate data, we do a series of checks and comparisons, all discrepancies fall into the appropriate reports, and after that, the security company usually begins to stir. What is there just is not. Subscribers connected by accounting systems, “zero” tariff plans, etc. ... There was a frank fraud: the company was sold, and the receipts to subscribers for some time put on the left details.
The organization of a single settlement center makes all such situations transparent, in the regions only the subscriber information service function remains, so there is practically no possibility for fraud. Plus a large customer base, consolidated into a single system, allows analyzing and predicting customer behavior at a completely different level. We gradually begin to apply to such large data our analytics systems built on machine learning. For example, we can identify in the client base “risk groups” - those who may soon refuse the services of the company. This is revealed by how people pay, how they use services, personal account, how they communicate with the call center, how much and for what reasons they have a block.
True, the centralization of billing brings with it other problems. It is necessary for regional branches to maintain a share of technical independence. Otherwise, if suddenly the central settlement center turns out to be “out of the access zone,” customer service in the region may suffer. We solve it at the expense of “outsourcing” to the periphery: authorization servers, elements of collecting and processing traffic, and elements of service provisioning. In particular, for mobile operators, our prepaid platform (Forward Fusion) can charge services autonomously and wait for the connection to be restored in order to synchronize data with the billing center. At the same time, regional subscribers may notice that the personal account has become unavailable, but the degradation of the provided service does not occur.
There are many options for how and where to place the billing system. Often companies worry about the safety of customer data, they themselves buy servers and install in their data center. But not everyone can pull their quality service. Sometimes a client has something broken, but he doesn’t even understand that this is on his side. He calls us in technical support, and already our admins tell him where the failure is, which server is not responding. Our system is set up so that it constantly “monitors” the serviced systems in many ways, and raises the alarm if something is wrong. So we can report in advance that the memory is running out or the speed of an important process has dropped below normal. But this unfortunately does not cancel force majeure.
Another option is when the client wants to be placed in his home, and we supply the hardware and software complex; this is done when the client wants us to grant him a certain performance on services that are critical for him. In this case, the cost of "iron" immediately laid the cost of its three-year support from the manufacturer. Then it keeps the spare parts and if something breaks, then their specialists go to the place with spare parts during the day and eliminate the damage.
There are times when, on the contrary, they bring their servers and install them in our Tier III certified data center.
Another common option - we rent everything. Then we are fully responsible for the "iron" - and for the service, and for the time to increase the required capacity. For this reason, at some point we began to use private clouds. If we have increased the load, we change the settings, and we are allocated additional computational power. No need to endlessly engage in non-core for us "upgrade" of equipment. Unfortunately, Russian companies that today offer public cloud services cannot yet provide the level of guaranteed performance that the billing system requires. They can host sites, you can deploy online stores or put 1C. Therefore, we still have to actively participate in optimization and testing solutions for various private clouds,
The importance of choosing a database for billing is difficult to overestimate. High performance here can be achieved only by optimizing the billing system for a specific product. Forward Billing is optimized for working with two DBMS: Oracle Database and PostgreSQL). Last year, Forward Billing was included in the register of Russian software permitted for use in state-owned companies. And recently, the news came that in half a year they will begin to exclude development on the basis of foreign DBMS from the registry. From the point of view of the state, this is understandable. In conditions when almost all new Russian companies fall under the sanctions, they want to ensure the complete independence of the Russian software. But for vendors it threatens with decent additional costs.
Somewhere in an ideal world, the level of technical support from a supplier is determined by a clearly defined SLA - Service Level Agreement, which is also the Service Level Agreement. How does SLA differ from just a contract, where customer support hours are fixed? It contains specific requirements for service: the speed of receipt of the application, the time to solve the problem - and the system of fines that are imposed on the supplier, if the requirements are not met.
As practice shows, in order for SLA to become an effective tool for regulating relations between a customer and a supplier, the customer will have to carry out some analytical work. You need to understand how incidents will be critical for a particular business, and which ones are not worth it to panic. Most of our clients in one way or another use our basic SLA repeatedly tested and in our opinion are optimal.
Part of the problem is that small companies that acquire ready-made “boxed” solutions for billing in case of problems turn out to be 376 in the queue for technical support. Often, for such companies, the community of users of this product is provided more quickly by an online forum.
True, there are other extremes. One potential customer, a small virtual mobile operator, came to us just after it “burned” badly with the support of the billing system. As a result, this client offered us a “crazy” SLA, multiplying our standard requirements for response times and penalties almost a hundred times. Unfortunately, we failed to convince him and he continues to serve his subscribers at his own peril and risk.
Billing is not just a calculator
Billing systems for a long time not just keep the balance of the client and invoice. They are deeply integrated into the business: they provide traffic control, manage the procedure for providing access to services, provide the client with a report on expenses in different sections - for a month, for a year, since the last payment. Plus, the billing system, as a rule, should support a lot of user balances: monetary and some real (bonuses, minutes of conversation, gigabytes of traffic, etc.). Not to mention affiliate programs and other cross-selling options. What is called modern convergent billing. It is implemented due to the integration of the tarifficator with other modules and subsystems: CRM, PRM, BPM, etc. For developers, this is not “intimate” knowledge. As they say, divide the functions and conquer. But for billing users,
An example from our practice. The client is a small but promising company. They did not have enough budget for the billing complex entirely, they asked to remove the BPM (business process management) module. It is necessary to pay tribute, the guys who were quite advanced in the technical sense worked there. They said they would take the open source solution, set up, integrate with the system. We agreed. And after four months, they “drowned” in their appeals to tech support for incorrect data.
BPM is a system that, among other things, when a subscriber is connected, deals with data validation, and does not let you go to the next step until you fill in all the necessary parameters - technical and personal. And they refused BPM, and simply drew an interface for data entry. People who accept applications for connection are not highly paid specialists, there is a big turnover there, a short staff training time. Naturally, they constantly made mistakes when entering data. The result - at the end of the month, the company bills, and the caller lacks the parameters. He “swears”, gives error messages. Customer calls in support. In the end, we made the decision to give them BPM in default settings. Everything began to converge with them, and our technical support had less headache. Now we don’t sell billing without BPM, except when it is already implemented and there are options for integration with it. If the client does not have enough money for the minimum required set, we offer rent or lease with the possibility of redemption in five years. Or, if this is some kind of startup, but it is clear that people are serious about the business and they have prospects, we offer a scheme with a rhubarb. In any case, it protects the nerve cells of both us and the management of the client company.
Flexibility - a loose concept
The ill-conceived architecture of the billing system turns around not only technical failures. In our experience, in 70% of cases, the need to replace billing arises due to its insufficient marketing flexibility. The telecom market is now oversaturated, and companies can only get new customers by defeating them from competitors. Even major providers, mastering new niches and expanding the territory of presence, begin to dump, and even the new players on the market “God himself ordered” to attract attention with unique offers. A real war of tariffs is unfolding. And then marketers are clutching their heads: “We will be able to put your new innovative tariff“ Super-New Year ”into sales only by July,” a message from the IT department comes.
What is the problem. In a very small number of billing systems there is, for example, a separate product catalog, which makes it easy to combine services into packages and set up promotions. The parameters with which he operates can be both services and individual parameters such as talk minutes, traffic packages or services offered by partners (so-called third-party services), such as movie tickets or taxi rides. There is an opinion that the product catalog is generally an element of a CRM system, and not billing. But even if it is so, not all companies have a separate CRM. Many subscribers are serviced directly in the billing system. And this means that any new service, new tariff, new action - and “IT people” need not to collect it in the designer, but to add fields and write lines of code. July is just around the corner.
True, marketers usually do not understand what the vendor has in mind, saying that his system is “quite flexible”. Enough for what? "Komersantov" primarily interested in time-to-market, the time required to release the service to the market. Once representatives of a client - a regional operator, in whose region federal players came - directly to the presentation meeting brought us descriptions of 3 cases of competitors that they could not implement at home. They put the question bluntly: for how long can you configure on your system? It’s not a sin to boast - we set up one case in a test environment right in front of them while the presentation was on. In general, with a well-designed billing architecture, any and using the product catalog, any package or share can be customized and brought to the market in 2-3 days, not counting the marketing and functional testing time. Check whether this is a specific billing, it is better at the stage of dating. Because there are cases when setting up a new tariff in a “fairly flexible” system actually takes several months.
Between centralization and autonomy
Similar problems in terms of marketing and sales are faced by large companies, which have grown due to the absorption of regional operators. Different billing systems in the branches do not allow, for example, to launch large-scale actions all over the country. Reporting and analytics suffer: it is simply impossible to collect data on connections and use of services from all of these disparate systems. A partial solution to the problem is an umbrella CRM, in which there is a product catalog. Some companies do that - they trade from CRM, and they charge for billing. For this, the company must have a really advanced IT department. Integrating billing systems written in different languages and on different principles with a single CRM is not an easy task.
But there is one eternal problem that distributed systems cannot solve - this is a banal fraud in the field. We had several such examples. In particular, in Ukraine, where we implemented centralized billing, transferring data from recently acquired regional branches. When we migrate data, we do a series of checks and comparisons, all discrepancies fall into the appropriate reports, and after that, the security company usually begins to stir. What is there just is not. Subscribers connected by accounting systems, “zero” tariff plans, etc. ... There was a frank fraud: the company was sold, and the receipts to subscribers for some time put on the left details.
The organization of a single settlement center makes all such situations transparent, in the regions only the subscriber information service function remains, so there is practically no possibility for fraud. Plus a large customer base, consolidated into a single system, allows analyzing and predicting customer behavior at a completely different level. We gradually begin to apply to such large data our analytics systems built on machine learning. For example, we can identify in the client base “risk groups” - those who may soon refuse the services of the company. This is revealed by how people pay, how they use services, personal account, how they communicate with the call center, how much and for what reasons they have a block.
True, the centralization of billing brings with it other problems. It is necessary for regional branches to maintain a share of technical independence. Otherwise, if suddenly the central settlement center turns out to be “out of the access zone,” customer service in the region may suffer. We solve it at the expense of “outsourcing” to the periphery: authorization servers, elements of collecting and processing traffic, and elements of service provisioning. In particular, for mobile operators, our prepaid platform (Forward Fusion) can charge services autonomously and wait for the connection to be restored in order to synchronize data with the billing center. At the same time, regional subscribers may notice that the personal account has become unavailable, but the degradation of the provided service does not occur.
The server that Jack put: where is the data stored?
There are many options for how and where to place the billing system. Often companies worry about the safety of customer data, they themselves buy servers and install in their data center. But not everyone can pull their quality service. Sometimes a client has something broken, but he doesn’t even understand that this is on his side. He calls us in technical support, and already our admins tell him where the failure is, which server is not responding. Our system is set up so that it constantly “monitors” the serviced systems in many ways, and raises the alarm if something is wrong. So we can report in advance that the memory is running out or the speed of an important process has dropped below normal. But this unfortunately does not cancel force majeure.
Another option is when the client wants to be placed in his home, and we supply the hardware and software complex; this is done when the client wants us to grant him a certain performance on services that are critical for him. In this case, the cost of "iron" immediately laid the cost of its three-year support from the manufacturer. Then it keeps the spare parts and if something breaks, then their specialists go to the place with spare parts during the day and eliminate the damage.
There are times when, on the contrary, they bring their servers and install them in our Tier III certified data center.
Another common option - we rent everything. Then we are fully responsible for the "iron" - and for the service, and for the time to increase the required capacity. For this reason, at some point we began to use private clouds. If we have increased the load, we change the settings, and we are allocated additional computational power. No need to endlessly engage in non-core for us "upgrade" of equipment. Unfortunately, Russian companies that today offer public cloud services cannot yet provide the level of guaranteed performance that the billing system requires. They can host sites, you can deploy online stores or put 1C. Therefore, we still have to actively participate in optimization and testing solutions for various private clouds,
Базы данных: важно не только где, но и как
The importance of choosing a database for billing is difficult to overestimate. High performance here can be achieved only by optimizing the billing system for a specific product. Forward Billing is optimized for working with two DBMS: Oracle Database and PostgreSQL). Last year, Forward Billing was included in the register of Russian software permitted for use in state-owned companies. And recently, the news came that in half a year they will begin to exclude development on the basis of foreign DBMS from the registry. From the point of view of the state, this is understandable. In conditions when almost all new Russian companies fall under the sanctions, they want to ensure the complete independence of the Russian software. But for vendors it threatens with decent additional costs.
SLA: decide on priorities
Somewhere in an ideal world, the level of technical support from a supplier is determined by a clearly defined SLA - Service Level Agreement, which is also the Service Level Agreement. How does SLA differ from just a contract, where customer support hours are fixed? It contains specific requirements for service: the speed of receipt of the application, the time to solve the problem - and the system of fines that are imposed on the supplier, if the requirements are not met.
As practice shows, in order for SLA to become an effective tool for regulating relations between a customer and a supplier, the customer will have to carry out some analytical work. You need to understand how incidents will be critical for a particular business, and which ones are not worth it to panic. Most of our clients in one way or another use our basic SLA repeatedly tested and in our opinion are optimal.
Part of the problem is that small companies that acquire ready-made “boxed” solutions for billing in case of problems turn out to be 376 in the queue for technical support. Often, for such companies, the community of users of this product is provided more quickly by an online forum.
True, there are other extremes. One potential customer, a small virtual mobile operator, came to us just after it “burned” badly with the support of the billing system. As a result, this client offered us a “crazy” SLA, multiplying our standard requirements for response times and penalties almost a hundred times. Unfortunately, we failed to convince him and he continues to serve his subscribers at his own peril and risk.