Customer business models and account roles

It is essential for every service provider to have a thorough understanding of their customers, e.g., which services they use or would like to have, and what their needs are, etc. In order to simplify customer management in a convergent environment where different types of services are provided, PortaBilling introduces two important concepts: business model and account role.

A business model defines which type of service a customer is using. The following business models are available:

• Cloud PBX
• SIP trunking
• Residential VoIP
• PINless
• Internet access
• Prepaid cards holder
• Mobile
• Universal

The first six business models in the list are self-explanatory, while the other two must be explained in more detail. The Mobile business model is customized for configuring mobile network subscribers – customers who are provided with a full range of mobile services. The Universal business model is a generalized model that allows you to configure any type of service for your customers. In addition, the Universal business model is also used for backward compatibility – any previously created customer is automatically assigned the Universal business model after a software upgrade. An administrator assigns a business model via a customer class.

Depending on the chosen business model, the administrator is offered a list of recommended account roles for it.

An account role defines what a specific account is designated for (e.g., whether the account represents a phone line or a top-up voucher) and executes account ID validation. Thus, for a phone line, one can only pick a valid phone number as an account ID. The following table demonstrates which account roles are available for each business model:

The administrator defines account roles for both accounts and products. This introduces the following constraint – a product can only be assigned to an account having the same role. This makes it possible to reduce the occurrence of errors during product assignment. For example, an account that is supposed to be for a phone line can only be assigned to a product that is designated for that; i.e. one cannot mistakenly pick a business SIP trunk product. The administrator can change an account role if required. Along with an account role, an administrator can define an account realm.

An account realm allows administrators to impose a scope of uniqueness for an account ID. An account realm is configured for a product.

For example, user John Doe wants to subscribe to the SmartCall product for PINless dialing from their mobile phone 12065551234. To provision John Doe’s mobile phone in PortaBilling, the administrator configures the SmartCall product using an ani realm. The administrator adds an account and chooses the SmartCall product for it. Then the account is saved in the following format: 12065551234@ani. John Doe finds another PINless dialing product attractive, MegaCall, and wants to subscribe to it too. The administrator needs to add an account that must not be confused with the account for the SmartCall product. The account realm perfectly serves this purpose. The administrator configures the MegaCall product with subrealm1.ani realm. The administrator adds an account and chooses the MegaCall product for it. The account is saved in the following format: 12065551234@subrealm1.ani. This allows proper provisioning for both accounts in PortaBilling.

When an administrator adds an alias to an account, a role and realm must be selected for it. Alias role and realm selection is limited by the main and add-on products assigned to the account.

The introduction of the business model and account role concept ensures that:

• The correct account ID format is preserved during account creation; and
• The chances of assigning an incorrect product to an account are significantly reduced.

This makes the account creation procedure more user-friendly and reduces the occurrence of human error.