Current Location ：
Multi-Tenant Voice Platforms for Managed Service Providers
Running voice for one organisation is an engineering problem. Running it for thirty is a business problem with engineering constraints. The questions that dominate are not about call quality, which is largely solved once, but about separation, delegation, and the cost of serving each additional customer. A platform that works beautifully for a single enterprise can be a poor fit for a service provider simply because every customer action requires provider involvement. This article covers what tenant separation actually needs to guarantee, how delegated administration changes the operating cost, what per-tenant data is needed for billing, and where support boundaries belong.
Separation Has Three Dimensions
Tenant separation is often discussed as a security property and treated as complete once customers cannot see each other's configuration. That is one dimension. Providers also need separation of change impact, so one customer's change cannot degrade another's service, and separation of failure, so a problem affecting one tenant is contained rather than shared. A design that separates configuration but not capacity will produce cross-tenant incidents during peak periods.
| Dimension | What it requires | Failure if missing |
|---|---|---|
| Configuration | Tenants cannot view or alter each other's settings | Data exposure and accidental cross-tenant changes |
| Change impact | A change for one tenant does not alter service for others | Routine work causing incidents for unrelated customers |
| Capacity | Resource consumption is bounded per tenant | One busy tenant degrading service for everyone |
| Failure | Faults remain contained within the affected tenant | Localised problems becoming platform-wide events |
Delegated Administration Determines Operating Cost
The single biggest lever on the cost of a hosted voice business is how much a customer can do without contacting the provider. Moves, adds, and changes are the bulk of the request volume, and each one routed through provider staff costs margin. Delegating administration to a named person at the customer, with limits appropriate to their competence, converts a ticket into nothing. The design question is how far to delegate: too little and the provider drowns in small requests; too much and the provider inherits the cleanup.
- Delegate routine moves, adds, and changes to a trained customer administrator
- Reserve carrier-facing and numbering changes for the provider
- Provide template-driven onboarding so each new tenant starts from a known-good configuration
- Log administrative actions per tenant so changes can be attributed later
- Define what happens when a delegated administrator leaves the customer organisation
Billing Data Is a Product Requirement
Per-tenant usage data tends to be discovered late, when the first invoice run reveals that the platform records calls but not in a form that maps to a billing model. Decide early what needs to be captured per tenant: call counts or duration by direction, numbers and trunk consumption, licence or seat counts over time, and any usage that is billed separately. Then verify that the data can be extracted reliably and repeatedly, because a billing process that depends on manual assembly will eventually produce a dispute.
Onboarding and Support Boundaries
A repeatable onboarding pattern is what allows a provider to grow without adding proportionally more engineering effort. Standard templates, a stated set of verification steps, and documentation written once and reused turn onboarding from a project into a procedure. Support boundaries belong in writing too: which issues the customer's administrator handles, which go to the provider, and which go to the carrier. Ambiguity here becomes an unpaid tier of support.
One more boundary worth stating explicitly is the carrier relationship. When an issue is upstream with a carrier, the customer usually wants it fixed and the provider usually has to escalate. Defining how that escalation works, and what the customer is told during it, prevents the most common source of dissatisfaction in hosted voice.
Redstone Approach
Redstone works with service providers delivering voice to their own customers on hosted and hybrid models. Our teams can discuss tenant separation design, delegated administration models, per-tenant reporting for billing, and onboarding patterns, and can support provider staff through design and early deployments. Commercial and technical models for provider arrangements are agreed in writing, including support boundaries and escalation paths.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
