Buying connectivity: what to ask

Ask for evidence, not assurances

A provider can answer a question in three ways: with a document, with a measurement, or with an assurance. Only the first two can be checked. Ask for the route, the profile, the measurement, the owner and the exit in that order, and write the answer down while the call is still open.

Great coverage in Mexico is not an answer to a route question. The useful answer names the network that serves each area, the handoff into the country, the address pool and the APN. If the provider cannot name them, the claim is a starting point, not evidence.

The same rule applies to identity. Ask which IMSI range, which profile type and which entity holds the subscription. For an eSIM, ask who owns the profile and who can delete it. For a fleet that crosses borders, ask which network serves each market and what happens when the device moves.

Start with the claim you can test

Start with the route because it is the easiest claim to test. Ask for a traceroute from the device to the destination, at the busy hour, with the address of each hop. Ask where the traffic enters and leaves each country, and which address pool the device receives. A route that is not written down cannot be compared.

Then ask for the profile. The IMSI range tells you whose identity the device presents. The APN tells you which gateway it uses. The profile type tells you whether the subscription can move over the air. Together they answer whether the device will look local, roaming or private in each market.

Finally ask who owns each layer. A single account manager is not a responsible owner for the radio, the core and the platform. Ask for the escalation path per layer, and test it once before the fleet depends on it.

Name the owner for each layer

An answer that names one account manager for everything is not a responsibility answer. The radio, the core, the platform and the customer relationship can sit with different teams or different companies. Ask who is woken up for each kind of failure, and how the handoff between them works.

Test the escalation once. Open a low-severity case and watch how it moves. A path that works in a diagram but not in a ticket is a risk the fleet carries.

Write the names into the runbook, not into a slide. When a device stops, the first responder should know which layer to check and who owns the next step.

The same discipline applies to the commercial side. Ask who owns the invoice query, the contract change and the exit. A named person per function is easier to test than a promise of support. Record the name and the date in the runbook.

Write the exit plan before the first invoice

Write the exit plan before the first invoice. It should say how data leaves, how addresses are returned, how profiles are deleted, how the number or IMSI range is released and how much notice each side must give. An exit plan that exists only in a slide is not a plan.

The exit plan also protects the customer. If the provider changes ownership or stops serving a market, the device fleet still has to work. Ask for the format of the data export and the time it takes. Ask which parts of the configuration belong to you and which belong to the platform.

Review the plan at every renewal. A route or a profile can change in a year. The plan should name the date it was last tested and the person who tested it.