November 3, 2015 at 00:13Cloud explanations: we create a virtual PBX operator service in three days
Just a few years ago, search engines in response to a search query "Clouds" issued a lot of links to children's cartoons and Wikipedia articles about atmospheric phenomena. In the last two or three years, the trend has changed and publications with descriptions of cloud computing and platforms have begun to fall into the top results, and the term “Clouds” among IT specialists now causes ambiguous associations: far from everyone imagines “atmospheric condensation products suspended in the atmosphere couple ”, rather in the mind of the“ right IT specialist ”there appear images of virtual platforms and platforms, various IaaS, PaaS, SaaS. Virtualization of everything and everything is one of the main trends of the decade, many client services have long moved to the clouds, large telecom businesses are introducing more and more VASin addition to basic services, and often, what once was Value Added Service turns into a basic product. Communication services in this sense are no exception and the Cloud PBX service is simply becoming an obligatory item in the list of telephone operator offers. We will talk about how (including with our help) to quickly and relatively naturally launch our own cloud PBX service below.
For simplicity, we define that the eternal question “to be or not to be a new service” was solved initially and that no respected telecom representative doubts that the telephone business without virtual telephone exchanges in 2015 is not quite right, or rather, wrong at all. The market in this segment is growing up to 40% per year and this fact cannot be ignored. Those of the operators who have not yet managed to launch cloud-based IP-PBX in production almost certainly think about it or are just about to think, the question is only in methods and timing.
There are several ways to launch a telephone SaaS service, briefly dwell on the two most common ones: launching a cloud-based PBX as our own development and launching a service based on the White Label platform of one of the vendors. If both ways to visualize and try to describe in a few words, you get the following picture:
On our own
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 it. In this case, the service provider gets a sense of independence and control of everything and everything, but spends a lot of time to launch and gets involved resource and financially, in fact, the development of the service never stops.
By model PaaS
We use the ready-made PaaS platform and are engaged only in sales and marketing, leaving the technology partner with most of the technical concerns. Implementation periods tend to a minimum, there is no need for significant volumes 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 a whole, separate, research, and we will definitely return to it in one of the following publications, the second way is closer and clearer to us and we will examine it in detail on the example of our cloud-based White Label platform ITooLabs. We add only that when starting a virtual PBX service on a PaaS platform, choosing the “correct vendor” is one of the archival tasks, the correct solution of which can offset the main problem - dependence on this vendor itself.
The development of ITooLabs Communication Server is a history of several years. The product is based on its own communication core, its own interfaces and components, its own vision of what a “correct” cloud-based PBX should be, and many sleepless nights for developers and marketers. The server side, or what is commonly called PaaS, is deployed in its own cluster: it is calmer for us and our partners. We ensure the functioning of all segments, control and manage, monitor and update, support and support.
Partner service provider gets access to the admin panel after a short and completely painful customization: logos, colors and graphic interface elements 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, relevant and popular functionality. About platform features in infographics:
ITooLabs Communication Server provides access to two different types of management interface: the operator interface (aka super administrator interface) and the 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 CisAdmin has a lot of buttons and checkboxes at hand, and the client interface has a minimum of extra options and solid “beautiful things”. SysAdmin manages and controls, and the client configures forwarding and IVR. Both interfaces are customizable and customizable. An example of a “painted” client interface can be seen in the screenshot below.
The SisAdmin 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 process of launching a virtual cloud telephone service through the eyes of the operator in steps, with the connection of the first end client.
To get started, we request and get the super administrator account 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 according to the 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, a large part of the service administrator’s life passes: we see the virtual exchanges of our “endpoints”, we can activate and deactivate them, disable or enable additional services, set limits and restrictions, configure trunks, numbers and routing. So, the first PBX has been sold and we have a request from the first client. Further down the steps.
Step one:
create a new client PBX (it is clear that the client has previously announced how many employees he plans to telephon and what additional services he would like to use). We are generating a new subdomain, accessible at the web address, which the respected operator partner has wished to use for his new service. The address looks like: client_name. Partner_domain.
Having studied the client’s wishes, we connect him the set of services that he ordered after talking with sellers or after reading marketing descriptions on the service’s website. All management is only a GUI, the console is not required at all. For those who wish, you can provide access to all the platform logs.
Step two:
we are an operator, we have many interfaces with various higher providers and we want to manage multiple trunks, providing each client with the opportunity to make calls along the optimal route. To do this, we create the number of gateways that is necessary (the gateway is a trunk, it is a joint, it is a gateway for incoming and outgoing calls). You can immediately connect billing, set all the necessary rules for skipping caller ID, the format for broadcasting the number, and the features of sending ANI.
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.
Fourth step:
creating dial plans. Since the days of the USSR, in the minds of most older people, any call to intercity and international destinations should begin with “8”, and in the minds of generation X, which use exclusively smartphones, the correct set always starts with a “+” sign. We simplify life for both of them and set up dial plans so that everyone is happy. Then we’ll “scatter” the dial plans by users.
Step Five:
phone numbers. Cloud PBX service without incoming communication is nonsense. Therefore, the incoming connection should be. We are an operator and we have our own numbering capacity (or we get numbering capacity according to an affiliate scheme from higher providers). We will register the numbers available for users of cloud exchanges and compare the necessary numbers with the right customers. Now you can call numbers and all calls will go through pre-created routes. How many incoming numbers are available to the "end" we decide only with a simple click of the mouse.
Step Six:
Each client has his own route. We are based on our own business logic and give customers the opportunity to call in an optimal way for us. We attach a pre-created route to each individual telephone exchange. Sometimes it happens that the client wants to continue using his old operator. Well, you can enable this, by setting up a specific PBX to work through a separate, specialized gateway.
Six steps to configure the first virtual PBX are passed, the moment of truth comes. Click "Save" and start an administrator account for the client, indicate the name, contacts, phone numbers, passwords and attendance.
The robot generates an account and sends a message to the welk.
The delighted client follows the link in the letter, enters their credentials (the authorization page is prudently customized in the corporate style of the partner), waits a couple of seconds
and logs in to his newly minted cloud PBX, where he is waiting for a customized interface with optimum buttons and settings. Now the thing is small: configure your PBX-ku according to your own understanding, but this is already the task of the client. Let's not bother him.
Minimalism of the client interface should not be embarrassing: everything you need is there, the settings are visualized, the "Statistics" section is created with the expectation of the inquisitive mind of a prudent manager and displays all the details for each employee, generates graphs and reports. The "Settings" section is structured and all the "features" are prudently hidden under the "More" icon. The CRM box integration button is in a prominent position. A detailed description of the functionality of the client side of the ITooLabs cloud-based PBX would take another couple of pages of chunky text. Someday we will describe him, especially since in our opinion there is something to brag 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 start a new or conditionally new business. Each of the situations is individual and requires a 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-mcdonalds" in which the connection of new customers, their support and service are put on stream using proven technology. Using PaaS platforms is just a step in this direction, as the client becomes more demanding and moody and asks for more love and attention. In such conditions, a huge amount of resources is spent on retention, and not just on attraction. Everything described above is just one of the recipes for a “universal hamburger” and we believe that
After a while, we’ll return with new descriptions and ideas.
For simplicity, we define that the eternal question “to be or not to be a new service” was solved initially and that no respected telecom representative doubts that the telephone business without virtual telephone exchanges in 2015 is not quite right, or rather, wrong at all. The market in this segment is growing up to 40% per year and this fact cannot be ignored. Those of the operators who have not yet managed to launch cloud-based IP-PBX in production almost certainly think about it or are just about to think, the question is only in methods and timing.
Launching your cloud PBX
There are several ways to launch a telephone SaaS service, briefly dwell on the two most common ones: launching a cloud-based PBX as our own development and launching a service based on the White Label platform of one of the vendors. If both ways to visualize and try to describe in a few words, you get the following picture:
On our own
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 it. In this case, the service provider gets a sense of independence and control of everything and everything, but spends a lot of time to launch and gets involved resource and financially, in fact, the development of the service never stops.
By model PaaS
We use the ready-made PaaS platform and are engaged only in sales and marketing, leaving the technology partner with most of the technical concerns. Implementation periods tend to a minimum, there is no need for significant volumes 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 a whole, separate, research, and we will definitely return to it in one of the following publications, the second way is closer and clearer to us and we will examine it in detail on the example of our cloud-based White Label platform ITooLabs. We add only that when starting a virtual PBX service on a PaaS platform, choosing the “correct vendor” is one of the archival tasks, the correct solution of which can offset the main problem - dependence on this vendor itself.
The development of ITooLabs Communication Server is a history of several years. The product is based on its own communication core, its own interfaces and components, its own vision of what a “correct” cloud-based PBX should be, and many sleepless nights for developers and marketers. The server side, or what is commonly called PaaS, is deployed in its own cluster: it is calmer for us and our partners. We ensure the functioning of all segments, control and manage, monitor and update, support and support.
Partner service provider gets access to the admin panel after a short and completely painful customization: logos, colors and graphic interface elements 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, relevant and popular functionality. About platform features in infographics:
ITooLabs Communication Server provides access to two different types of management interface: the operator interface (aka super administrator interface) and the 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 CisAdmin has a lot of buttons and checkboxes at hand, and the client interface has a minimum of extra options and solid “beautiful things”. SysAdmin manages and controls, and the client configures forwarding and IVR. Both interfaces are customizable and customizable. An example of a “painted” client interface can be seen in the screenshot below.
The SisAdmin 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 process of launching a virtual cloud telephone service through the eyes of the operator in steps, with the connection of the first end client.
To get started, we request and get the super administrator account 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 according to the 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, a large part of the service administrator’s life passes: we see the virtual exchanges of our “endpoints”, we can activate and deactivate them, disable or enable additional services, set limits and restrictions, configure trunks, numbers and routing. So, the first PBX has been sold and we have a request from the first client. Further down the steps.
Step one:
create a new client PBX (it is clear that the client has previously announced how many employees he plans to telephon and what additional services he would like to use). We are generating a new subdomain, accessible at the web address, which the respected operator partner has wished to use for his new service. The address looks like: client_name. Partner_domain.
Having studied the client’s wishes, we connect him the set of services that he ordered after talking with sellers or after reading marketing descriptions on the service’s website. All management is only a GUI, the console is not required at all. For those who wish, you can provide access to all the platform logs.
Step two:
we are an operator, we have many interfaces with various higher providers and we want to manage multiple trunks, providing each client with the opportunity to make calls along the optimal route. To do this, we create the number of gateways that is necessary (the gateway is a trunk, it is a joint, it is a gateway for incoming and outgoing calls). You can immediately connect billing, set all the necessary rules for skipping caller ID, the format for broadcasting the number, and the features of sending ANI.
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.
Fourth step:
creating dial plans. Since the days of the USSR, in the minds of most older people, any call to intercity and international destinations should begin with “8”, and in the minds of generation X, which use exclusively smartphones, the correct set always starts with a “+” sign. We simplify life for both of them and set up dial plans so that everyone is happy. Then we’ll “scatter” the dial plans by users.
Step Five:
phone numbers. Cloud PBX service without incoming communication is nonsense. Therefore, the incoming connection should be. We are an operator and we have our own numbering capacity (or we get numbering capacity according to an affiliate scheme from higher providers). We will register the numbers available for users of cloud exchanges and compare the necessary numbers with the right customers. Now you can call numbers and all calls will go through pre-created routes. How many incoming numbers are available to the "end" we decide only with a simple click of the mouse.
Step Six:
Each client has his own route. We are based on our own business logic and give customers the opportunity to call in an optimal way for us. We attach a pre-created route to each individual telephone exchange. Sometimes it happens that the client wants to continue using his old operator. Well, you can enable this, by setting up a specific PBX to work through a separate, specialized gateway.
Six steps to configure the first virtual PBX are passed, the moment of truth comes. Click "Save" and start an administrator account for the client, indicate the name, contacts, phone numbers, passwords and attendance.
Eyes of a customer
The robot generates an account and sends a message to the welk.
The delighted client follows the link in the letter, enters their credentials (the authorization page is prudently customized in the corporate style of the partner), waits a couple of seconds
and logs in to his newly minted cloud PBX, where he is waiting for a customized interface with optimum buttons and settings. Now the thing is small: configure your PBX-ku according to your own understanding, but this is already the task of the client. Let's not bother him.
Minimalism of the client interface should not be embarrassing: everything you need is there, the settings are visualized, the "Statistics" section is created with the expectation of the inquisitive mind of a prudent manager and displays all the details for each employee, generates graphs and reports. The "Settings" section is structured and all the "features" are prudently hidden under the "More" icon. The CRM box integration button is in a prominent position. A detailed description of the functionality of the client side of the ITooLabs cloud-based PBX would take another couple of pages of chunky text. Someday we will describe him, especially since in our opinion there is something to brag about. But that's another story.
Instead of a conclusion
It is clear that there are no ideal schemes in real life, just as there are no ideal ways to start a new or conditionally new business. Each of the situations is individual and requires a 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-mcdonalds" in which the connection of new customers, their support and service are put on stream using proven technology. Using PaaS platforms is just a step in this direction, as the client becomes more demanding and moody and asks for more love and attention. In such conditions, a huge amount of resources is spent on retention, and not just on attraction. Everything described above is just one of the recipes for a “universal hamburger” and we believe that
After a while, we’ll return with new descriptions and ideas.