Retail customers

A customer is an entity (an individual or a company) who is responsible for using the service via one or more accounts. For instance, when a family signs up for residential VoIP services, a man, his wife, and his brother will all have individual phone lines, each represented by an account. The person who signs the contract (and who is responsible for paying the bills) will be entered as the customer, and all the accounts will be listed under him.

When a credit account is charged for using the service, this directly affects the customer’s balance, and the activities of all accounts are included in the consolidated invoice. This allows quick tracking of service use for a group of accounts, or the application of a credit limit for the whole group.

Typically used for: business end-customers (when more than one account per customer is required)

Customers are divided into prepaid and postpaid categories, depending on how their balance is controlled.

For customers who have a prepaid balance model, they first pay for the services and then use them (e.g., customers will not be able to make outgoing calls or surf the Internet without topping up the balance first).

The balance for prepaid customers is shown as a positive value and indicates how much of the services can be used with the funds currently available.

While consuming the service, the amount of funds decreases. When it reaches zero value, no more services can be used.

Once payment is made, the amount of available funds increases.

Typically used for: calling card services.

For customers who have a postpaid balance model, services are provided to them on credit. This means they use the services and then pay for them on the basis of invoices generated at the end of a billing period.

The balance for postpaid customers indicates the amount of money owed to the service provider. Once the invoice is paid, the balance decreases.

To prevent misuse of services and fraud traffic (e.g., the account’s credentials were stolen and lots of traffic was sent to the network), it is highly recommended that you set up a credit limit for postpaid customers. When the customer’s balance reaches that credit limit, this customer’s accounts will no longer be allowed to use the service.

Typically used for: businesses (e.g., companies having several phone lines and paying consolidated invoices for the total amount of services used).

Please find the usage of customer balance models different business scenarios in the table below:

* It is possible to define individual credit limits for particular users under the customer (in this case users top up their accounts themselves with a credit card, either manually or automatically.) This account’s service usage affects both the account’s balance and the customer’s balance or available funds.

Organizing the customer hierarchy, administrators can easily configure the distributed infrastructure of a company with several functional departments (for example, the support and sales departments) so that their billing-related activities are maintained separately. Moreover, features such as extensions and hunt groups have only to be configured once before they can be shared among all of a company’s departments.

This is achieved by introducing two types of customers within a hierarchy:

• Main Office (HQ) – this defines the “main” customer in the group for which the basic service configuration is done. All extensions and hunt groups added for this customer become available for all of its linked customers.
• Branch Office (site) – this defines the “subordinate” customer created under the Main Office (HQ) customer. This customer inherits all of the main customer’s extensions and hunt groups.

Customer hierarchy is also useful for when an administrator needs to configure a company’s geographically-distributed infrastructure. In this case, the company has multiple independent offices and requires individual billing statistics for each of them.

To configure the customer hierarchy, first enable the corresponding feature for the “main” customer:

• Go to the Customer > Personal > General info > Additional info page.
• Turn on the Use the hierarchy of offices toggle.
• In the Office field, leave “Main (HQ)”.

Then, in the same way, you can enable the Use the hierarchy of offices option for the “subordinate” customers, just marking these customers as “Branch (Site)” and linking them with the corresponding main office.

See the details in the How to configure the customer hierarchy section.

Let`s say the company has its main office on shore and its petroleum towers at sea. The personnel who work on the towers need to communicate with the main office via extensions and they also make calls to the main office’s hunt groups. Their chief accountant wants each tower’s billing and payments activities managed individually.

The administrator creates a Main Office (HQ) customer in PortaBilling and configures the extensions and hunt groups for it. Then he creates a group of Branch Office (site) customers and links them to the Main Office (HQ) customer created earlier. Since the extensions and hunt groups defined for the Main Office (HQ) customer are available for this group of linked customers, no additional configuration is required.

The administrator then configures the billing-related activities (such as invoice generation, balance management, amount due tracking) for each customer he created, and billing-related statistics for each of them can be tracked individually.

Let’s say a company has a main office and a group of branch offices. All of the offices share the same PBX environment (e.g., personnel can communicate across all of the offices via extensions, or make calls to other offices’ hunt groups). The company owner wants to pay the communication charges for all their offices in a single bill.

An administrator creates a Main Office (HQ) customer and a group of Branch Office (site) customers and links them together. Then the administrator enables both statistics and invoice generation and defines the taxation settings for the Main Office (HQ) customer. The billing period must be the same for all linked customers in the group.

To avoid discrepancies during tax calculation, disable tax calculation for all Branch Office (site) customers within the group.

At the end of the billing period, the system generates a consolidated invoice for the Main Office (HQ) customer. This invoice includes the total charged amount for all of the company offices. The Main Office (HQ) customer also receives statistics reports generated for each branch office.

The system generates consolidated invoices in accordance with the time zone defined for the Main Office (HQ) customer. If Branch Office (site) customers are located in different time zones, you may need to postpone invoice generation until their billing periods are closed. In that case, use the customer class option The billing period is closed.

To generate an individual invoice for a branch office, the administrator disables the Include charges into main office invoice option for the corresponding Branch Office (site) customer.

The administrator can configure an individual credit limit/spending plan for each linked customer in the group.

Consolidated invoice allows service providers to consolidate all of their communication charges on a single bill for their customers that have distributed infrastructure, and thereby provides greater convenience.

Before PortaBilling generates a consolidated invoice, it checks the status of the Main Office (HQ) customer. See the details about customer statuses in the Customer and account statuses section.

The table below shows the service availability for Branch Office (site) customers and consolidated invoice generation depending on the status of the corresponding Main Office (HQ) customer.

You may terminate a customer, including all his accounts. If, for some reason, you do not want a customer to remain in your PortaBilling environment any longer, click the Change Status button on the Customer Info toolbar and then select the Permanently Terminated check box. This option allows you to stop all the customer’s activities, and later to remove him and all his accounts from the environment. When terminated, the customer is no longer available for any operations. The only way to trace this customer is by using Advanced Search with the “Permanently Terminated” status filter.

In addition to permanent termination, you can use the provisional termination functionality.

Once a customer is provisionally terminated, all their services are closed (that is, no services can be used). But there is still an option to reactivate services that were disconnected if the customer should change their mind later on. The administrator is easily able to restore this customer’s services so that they can be used exactly as before.

If a customer ultimately decides to discontinue services, the administrator can permanently terminate this customer in the system. In case of permanent termination, all customers’ services are closed and cannot be restored.

Note that if you are going to provisionally terminate a customer, this customer won’t be charged for any DID numbers assigned to them. At the same time, the DID provider will still charge you a fee (e.g., $5/month) because these DID numbers remain allocated to your network until the customer is permanently terminated.

Also, a subscription fee won’t apply for the days when a customer is provisionally terminated (credits for a subscription fee are issued for these days), no matter what conditions are set for subscription charging.

Customer classes allow you to define which type of service a customer is using and a set of parameters that will be shared among a certain category of customers. For instance, suppose your invoice term for retail customers is “Net 21 days,” while for business customers it is “Net 30 days.” If your operators enter these values manually for each customer, there will inevitably be mistakes. Instead, you can define two separate customer classes, one named “Retail” and the other “Business,” and define these parameters within them. After that, your operators need only assign a specific class to a given customer in order for the customer to automatically inherit all the class properties (grace period, invoice template, taxation, notification list and so on).