International numbering projects often slow down because responsibility is assumed rather than written. The customer expects the provider to obtain documents that only the customer can supply. The provider expects a carrier to accept a request that still lacks local evidence. A third-party platform is treated as part of the voice service even though its licences and permissions belong to a separate account.
A practical project starts with a responsibility model. GeoNumbering's Master Offer separates customer inputs, provider configuration and coordination, carrier dependencies and third-party platform requirements. It also distinguishes actions within New Assistent's control from lead times or decisions that depend on others.
Customer responsibilities
The customer provides the business and technical facts on which the project is based. That normally includes the legal entity requesting the service, the countries and number types required, the intended use, current number inventories, porting information, technical contacts and the routing or platform design on the customer side.
Where local documentation is required, the customer supplies accurate corporate evidence and confirms that the planned use meets its local obligations. The customer also controls its own LAN, WAN, Internet access, PBX or SBC unless those elements are explicitly included in the provider's scope.
The key principle is simple: the provider cannot validate facts that only the customer knows. Incomplete or inconsistent information can increase operational complexity and can delay carrier review.
Provider responsibilities
Within the agreed scope, New Assistent configures GeoNumbering services and coordinates the relevant carrier and platform activities. This can include number ordering, routing, Cloud PBX or Contact Center configuration and project-specific integrations.
The provider should translate the commercial scope into a technical configuration, identify missing inputs and explain which dependencies are external. It should not present carrier availability, local acceptance or third-party features as if they were fully under its control.
The provider also owns clear project communication. That means maintaining the configuration record, identifying the first response path, documenting changes and stating when a request is waiting for customer evidence, carrier action or third-party approval.
Carrier and third-party responsibilities
Carriers control the availability and activation processes for the number ranges and network services they provide. They may validate documentation, apply local requirements, confirm portability and establish routes. These conditions can vary by country, number type and carrier.
Third-party platforms control their own licences, permissions, supported countries, integration requirements and product behaviour. When Microsoft, Google or another vendor is involved, the applicable requirements should be verified in that vendor's official documentation. Their functions must not be attributed to GeoNumbering.
The important distinction is between coordination and control. A provider may coordinate a carrier or integration step without being able to guarantee the other organisation's decision or timing.
A three-column responsibility table
| Customer | Provider | Carrier and third parties |
|---|---|---|
| Defines countries, number types and intended use | Translates scope into the GeoNumbering configuration | Confirms availability within its own network and rules |
| Supplies company documents and authorised contacts | Checks completeness and coordinates submissions | Validates documents and local requirements |
| Supplies number inventories and migration information | Coordinates port-in activities within scope | Processes requests for the relevant ranges |
| Prepares its LAN, WAN, PBX, SBC and endpoints unless included | Configures agreed routing, PBX, Contact Center and integrations | Operates external networks or platforms |
| Verifies its local compliance obligations | Documents boundaries, dependencies and first response | Applies its own licences, permissions and service conditions |
This table is a starting point, not a substitute for the statement of work. Each project should add named owners, evidence required and the condition that marks each task as complete.
Three questions to ask before signing
First, who supplies and validates every required input? Ask for a checklist that names the document, its owner and the party that accepts it.
Second, which parts of the schedule are under the provider's control, and which depend on carriers, documentation or third-party platforms? The answer should avoid unsupported activation promises.
Third, what is explicitly included in the configuration and support profile? Core service, optional modules and external licences should be separated so that the scope is comparable.
Turn the table into an operating plan
For each task, record the owner, required input, dependency, evidence of completion and escalation path. Review the table when the country list, number type, routing design or third-party platform changes. A change in any of these areas may create new documents, permissions or carrier checks.
The purpose of a responsibility model is not to shift risk between parties. It is to make the project executable. When customer, provider and carrier duties are visible, teams can prepare the right evidence and direct questions to the organisation that can actually answer them.