Cloud explanations: we create a virtual PBX operator service in three days
Just a few years ago, the search engines in response to the search query "Clouds" gave out many links to children's cartoons and Wikipedia articles on atmospheric phenomena. In the last two or three years, the trend has changed and publications with a description of cloud computing and platforms began to fall into the top of the issue, and the term “Clouds” among IT-specialists now causes ambiguous associations: not everyone already imagines “atmospheric condensation products pair ”, rather in the minds of the“ right IT specialist ”, images of virtual platforms and platforms, various IaaS, PaaS, SaaS arise. Virtualization of everything and everyone is one of the main trends of the decade, many client services have long since migrated to the clouds, large telecom businesses are introducing more and more new VAS in addition to basic services, and often what used to be Value Added Service turns into base product. Communication services in this sense are no exception and the Cloud PBX service becomes just a mandatory item in the list of offers of the telephone operator. We will describe how (including with our help) to quickly and relatively easily launch our own cloud PBX service below.
For simplicity, we will determine that the eternal question “to be or not to be a new service” was originally decided and no one from the respected representatives of the telecom has any doubts that the telephone business without virtual PBX in 2015 is not quite right, or rather wrong altogether. The market in this segment is growing up to 40% per year and it is impossible not to reckon with this fact. Those of the operators who have not yet managed to launch cloud-based IP-PBX in production will almost certainly think about it or are just thinking about it, the question is only in methods and terms.
There are several ways to launch a SaaS phone service, briefly discuss the two most common ones: launching a cloud-based PBX as a proprietary development and launching a service based on the White Label platform of one of the vendors. If both ways to depict clearly and try to describe in a few words, you get this picture:
')
Own forces
We do everything ourselves, develop a platform from scratch or create it on the basis of existing open source (or proprietary) solutions, independently develop and support. In this case, the service provider gets a sense of independence and control of everything and everything, but spends a lot of time starting up and becomes involved in resources and financially, in fact, the development of the service never stops.
By model PaaS
We use a ready-made PaaS platform and deal only with sales and marketing, leaving the technological partner with most of the technical concerns. The implementation timeline tends to be minimal, there is no need for significant amounts of development and support, the resource is required only for marketing and sales and a little bit to the first level of support, you can focus on commercial aspects, without being distracted by round-the-clock coding, but there is a dependence on the vendor and its business models.
The first way is the subject of the whole, separate, research and we will definitely return to it in one of the following publications, while the second way is closer and clearer to us and we will examine it in detail using the example of our cloudy White Label platform ITooLabs . We only add that when launching a virtual PBX service on a PaaS platform, the choice of the “correct vendor” is one of the most important tasks, the correct solution of which can level the main problem - dependence on this vendor.
Development of ITooLabs Communication Server - a history lasting several years. The product is based on its own communication core, its own interfaces and components, its own vision of what the “correct” cloud PBX should be, many sleepless nights of developers and marketers. The server part, or what it is called PaaS, is deployed in its own cluster: so much calmer for us and our partners. We ensure the functioning of all segments, monitor and manage, monitor and update, support and support.
Partner service provider gets access to the admin panel after a short and completely painful customization: the logos, colors and graphical elements of the interface change almost on the fly. In most cases, the launch - from customization to the first "Hello" - takes no more than a few days. In addition, we give software ITooLabs Communicator (also customized) and constantly updated, up-to-date and demanded functionality. About platform features in infographics:
ITooLabs Communication Server provides access to two different types of management interface: operator interface (also known as super administrator interface) and client interface. The task of the first is to provide maximum control and controllability of the service on the operator’s side, the task of the second is convenience and simplicity, which is why there are a lot of buttons and checkboxes at hand, and in the client interface there is a minimum of unnecessary options and solid “beauty”. SysAdmin manages and controls, and the client sets up redirects and IVR. Both interfaces are customizable and customizable. An example of a "colored" client interface can be seen in the screenshot below.
The Sysadmin interface looks a little different, but it can also be customized in the style of the partner-operator.
Imagine that we have a request from a new partner-operator and go through the procedure of launching a virtual cloud telephone service through the eyes of the operator himself, in steps, with the connection of the first end client.
To begin with, we request and receive an account of the super-administrator of our platform segment. As mentioned above, the platform lives in our cluster, no multi-day installations and settings are required, in fact everything is simple: the interface is customized by TOR, a new SysAdmin account is generated and sent to the partner operator. Two or three days and the partner receives his account and can log in.
In this interface, in fact, most of the life of the service administrator passes: we see virtual PBXs of our “end points”, we can activate and deactivate them, disable or connect additional services, set limits and restrictions, configure trunks, numbers and routing. So, the first PBX is sold and we have the first client request. Next in steps.
Step one:
we are creating a new client PBX (it is clear that the client has previously informed how many employees he plans to telephone and what additional services he would like to use). We generate a new subdomain, accessible by a web address, which the respected partner operator has chosen to use for its new service. The address looks like: client_name.domain_partner.
Having studied the wishes of the client, we connect to him the set of services that he ordered after talking with sellers or after reading marketing descriptions on the website of the service. All management is only GUI, the console is not required at all. For those who wish, you can provide access to all the logs of the platform.
Step two:
we are an operator, we have a lot of joints with various upstream providers and we want to manage multiple trunks, ensuring that each customer can call the optimal route. To do this, we create the number of gateways that are needed (the gateway is the trunk, it is the joint, it is the gateway for incoming and outgoing calls). Here you can connect the billing, set all the necessary rules for the caller ID pass, the format of the broadcast numbers and features of the caller ID transmission.
Step Three:
we prescribe the necessary routes and say what calls and in what directions will be routed to certain trunk gateways. Optimization and optimization again. We send Moscow to Moscow operators, and the “Internar” to Dusseldorf or Hamburg. Routes can be arbitrarily diverse.
Step Four:
we create dial plans. Since the time of the USSR, in the minds of most older people, any call to long-distance and international destinations should begin with "8", and in the minds of generation X, which use only smartphones, the correct set always starts with a "+" sign. Simplify life with both of them and set up dial-up plans so that everyone is happy. Then dial-up plans "scatter" on users.
Step Five:
phone numbers. Cloud PBX service without incoming connection is nonsense. Therefore, the incoming connection should be. We are an operator and we have our own numbering capacity (or we get the numbering capacity under the partner scheme from higher-level providers). Let's write down the numbers available for users of cloud PBX, and compare the necessary numbers with the right customers. Now you can call the numbers and all calls will pass through the previously created routes. How many incoming numbers are available to the “end user” are solved only by a simple mouse click.
Step Six:
each client has his own route. We rely on our own business logic and enable clients to call in the way that is optimal for us. Attach a pre-created route to each individual PBX. Sometimes it happens that the client wants to continue using his old operator. Well, you can allow this by configuring a specific PBX to work through a separate, specialized gateway.
Six steps to configure the first virtual PBX passed, the moment of truth comes. Click "Save" and set up an administrator account for the client, specify the full name, contacts, phone numbers, passwords and attendances.
The robot generates an account and sends a welcome message.
A delighted client follows the link in the letter, enters his credentials (the authorization page is prudently customized in the corporate style of the partner), waits for a couple of seconds
and logs in to its newly-fledged cloud PBX, where it is awaited by a customized interface with optimum buttons and settings. Now it's up to you: to configure your PBX system on your own, but this is the task of the client himself. We will not disturb him.
Minimalism of the client interface should not be embarrassing: everything you need is there, the settings are visualized, the “Statistics” section has been created with the expectation of the eager head and displays all the details for each of the employees, generates graphs and reports. The “Settings” section is structured and all “features” are prudently hidden under the “More” icon. Button boxed integration with CRM is in the most prominent place. A detailed description of the client-side functionality of the ITOLabs cloud PBX would take a couple more pages of narrow text. Someday we will describe him as well, especially since in our opinion there is something to boast about. But that's another story.
It is clear that there are no ideal schemes in real life, just as there are no ideal ways to launch a new or conditionally new business. Each of the situations is individual and requires thoughtful approach and analysis. At the same time, there is a clear trend in telecom: the desire for unification and replicability of products, a kind of “telecom-McDonald’s” in which the connection of new customers, their support and maintenance, are put to stream by a proven technology. Using PaaS platforms is just a step in this direction, as the client becomes more demanding and capricious and asks for more love and attention. In such conditions, a huge amount of resources is spent on retention, not just on attraction. Everything described above is only one of the recipes of the “universal hamburger” and we believe that this model will be the most viable in the field of serial sales of telecom products for SMB.
After a while, back with new descriptions and ideas.
For simplicity, we will determine that the eternal question “to be or not to be a new service” was originally decided and no one from the respected representatives of the telecom has any doubts that the telephone business without virtual PBX in 2015 is not quite right, or rather wrong altogether. The market in this segment is growing up to 40% per year and it is impossible not to reckon with this fact. Those of the operators who have not yet managed to launch cloud-based IP-PBX in production will almost certainly think about it or are just thinking about it, the question is only in methods and terms.
We launch our cloud PBX
There are several ways to launch a SaaS phone service, briefly discuss the two most common ones: launching a cloud-based PBX as a proprietary development and launching a service based on the White Label platform of one of the vendors. If both ways to depict clearly and try to describe in a few words, you get this picture:
')
Own forces
We do everything ourselves, develop a platform from scratch or create it on the basis of existing open source (or proprietary) solutions, independently develop and support. In this case, the service provider gets a sense of independence and control of everything and everything, but spends a lot of time starting up and becomes involved in resources and financially, in fact, the development of the service never stops.
By model PaaS
We use a ready-made PaaS platform and deal only with sales and marketing, leaving the technological partner with most of the technical concerns. The implementation timeline tends to be minimal, there is no need for significant amounts of development and support, the resource is required only for marketing and sales and a little bit to the first level of support, you can focus on commercial aspects, without being distracted by round-the-clock coding, but there is a dependence on the vendor and its business models.
The first way is the subject of the whole, separate, research and we will definitely return to it in one of the following publications, while the second way is closer and clearer to us and we will examine it in detail using the example of our cloudy White Label platform ITooLabs . We only add that when launching a virtual PBX service on a PaaS platform, the choice of the “correct vendor” is one of the most important tasks, the correct solution of which can level the main problem - dependence on this vendor.
Development of ITooLabs Communication Server - a history lasting several years. The product is based on its own communication core, its own interfaces and components, its own vision of what the “correct” cloud PBX should be, many sleepless nights of developers and marketers. The server part, or what it is called PaaS, is deployed in its own cluster: so much calmer for us and our partners. We ensure the functioning of all segments, monitor and manage, monitor and update, support and support.
Partner service provider gets access to the admin panel after a short and completely painful customization: the logos, colors and graphical elements of the interface change almost on the fly. In most cases, the launch - from customization to the first "Hello" - takes no more than a few days. In addition, we give software ITooLabs Communicator (also customized) and constantly updated, up-to-date and demanded functionality. About platform features in infographics:
ITooLabs Communication Server provides access to two different types of management interface: operator interface (also known as super administrator interface) and client interface. The task of the first is to provide maximum control and controllability of the service on the operator’s side, the task of the second is convenience and simplicity, which is why there are a lot of buttons and checkboxes at hand, and in the client interface there is a minimum of unnecessary options and solid “beauty”. SysAdmin manages and controls, and the client sets up redirects and IVR. Both interfaces are customizable and customizable. An example of a "colored" client interface can be seen in the screenshot below.
The Sysadmin interface looks a little different, but it can also be customized in the style of the partner-operator.
Six steps to the first bell
Imagine that we have a request from a new partner-operator and go through the procedure of launching a virtual cloud telephone service through the eyes of the operator himself, in steps, with the connection of the first end client.
To begin with, we request and receive an account of the super-administrator of our platform segment. As mentioned above, the platform lives in our cluster, no multi-day installations and settings are required, in fact everything is simple: the interface is customized by TOR, a new SysAdmin account is generated and sent to the partner operator. Two or three days and the partner receives his account and can log in.
In this interface, in fact, most of the life of the service administrator passes: we see virtual PBXs of our “end points”, we can activate and deactivate them, disable or connect additional services, set limits and restrictions, configure trunks, numbers and routing. So, the first PBX is sold and we have the first client request. Next in steps.
Step one:
we are creating a new client PBX (it is clear that the client has previously informed how many employees he plans to telephone and what additional services he would like to use). We generate a new subdomain, accessible by a web address, which the respected partner operator has chosen to use for its new service. The address looks like: client_name.domain_partner.
Having studied the wishes of the client, we connect to him the set of services that he ordered after talking with sellers or after reading marketing descriptions on the website of the service. All management is only GUI, the console is not required at all. For those who wish, you can provide access to all the logs of the platform.
Step two:
we are an operator, we have a lot of joints with various upstream providers and we want to manage multiple trunks, ensuring that each customer can call the optimal route. To do this, we create the number of gateways that are needed (the gateway is the trunk, it is the joint, it is the gateway for incoming and outgoing calls). Here you can connect the billing, set all the necessary rules for the caller ID pass, the format of the broadcast numbers and features of the caller ID transmission.
Step Three:
we prescribe the necessary routes and say what calls and in what directions will be routed to certain trunk gateways. Optimization and optimization again. We send Moscow to Moscow operators, and the “Internar” to Dusseldorf or Hamburg. Routes can be arbitrarily diverse.
Step Four:
we create dial plans. Since the time of the USSR, in the minds of most older people, any call to long-distance and international destinations should begin with "8", and in the minds of generation X, which use only smartphones, the correct set always starts with a "+" sign. Simplify life with both of them and set up dial-up plans so that everyone is happy. Then dial-up plans "scatter" on users.
Step Five:
phone numbers. Cloud PBX service without incoming connection is nonsense. Therefore, the incoming connection should be. We are an operator and we have our own numbering capacity (or we get the numbering capacity under the partner scheme from higher-level providers). Let's write down the numbers available for users of cloud PBX, and compare the necessary numbers with the right customers. Now you can call the numbers and all calls will pass through the previously created routes. How many incoming numbers are available to the “end user” are solved only by a simple mouse click.
Step Six:
each client has his own route. We rely on our own business logic and enable clients to call in the way that is optimal for us. Attach a pre-created route to each individual PBX. Sometimes it happens that the client wants to continue using his old operator. Well, you can allow this by configuring a specific PBX to work through a separate, specialized gateway.
Six steps to configure the first virtual PBX passed, the moment of truth comes. Click "Save" and set up an administrator account for the client, specify the full name, contacts, phone numbers, passwords and attendances.
In the eyes of a client
The robot generates an account and sends a welcome message.
A delighted client follows the link in the letter, enters his credentials (the authorization page is prudently customized in the corporate style of the partner), waits for a couple of seconds
and logs in to its newly-fledged cloud PBX, where it is awaited by a customized interface with optimum buttons and settings. Now it's up to you: to configure your PBX system on your own, but this is the task of the client himself. We will not disturb him.
Minimalism of the client interface should not be embarrassing: everything you need is there, the settings are visualized, the “Statistics” section has been created with the expectation of the eager head and displays all the details for each of the employees, generates graphs and reports. The “Settings” section is structured and all “features” are prudently hidden under the “More” icon. Button boxed integration with CRM is in the most prominent place. A detailed description of the client-side functionality of the ITOLabs cloud PBX would take a couple more pages of narrow text. Someday we will describe him as well, especially since in our opinion there is something to boast about. But that's another story.
Instead of conclusion
It is clear that there are no ideal schemes in real life, just as there are no ideal ways to launch a new or conditionally new business. Each of the situations is individual and requires thoughtful approach and analysis. At the same time, there is a clear trend in telecom: the desire for unification and replicability of products, a kind of “telecom-McDonald’s” in which the connection of new customers, their support and maintenance, are put to stream by a proven technology. Using PaaS platforms is just a step in this direction, as the client becomes more demanding and capricious and asks for more love and attention. In such conditions, a huge amount of resources is spent on retention, not just on attraction. Everything described above is only one of the recipes of the “universal hamburger” and we believe that this model will be the most viable in the field of serial sales of telecom products for SMB.
After a while, back with new descriptions and ideas.
Source: https://habr.com/ru/post/269947/
All Articles