A business link can underperform for several reasons, and the carrier is only one possibility. The service that suits one site may not fit another site’s location, access technology, traffic pattern, availability requirement or support process. Before renewing or changing a connection, compare the service against the way that site and its applications actually operate.
Start with the site requirement
For each location, list the applications and services that depend on connectivity, the users and devices involved, expected traffic patterns and the business impact of an outage. Note any requirements for voice, cloud platforms, remote access, security inspection, guest wireless or operational technology.
Record what matters for the site: availability, performance, resilience, support escalation, installation timing and any contractual service commitments. Do not assume every location needs the same bandwidth or service type. A small branch, a large office and a remote operating site can have different constraints.
Verify what is available at the address
Check the access technology, service availability, physical hand-off, lead time and any site-specific limitations. A carrier may offer several products, but the available service can vary by address. Confirm the actual quoted service, not just a product name or coverage map.
Ask how the connection reaches the site and where the provider’s responsibility ends. Understand the demarcation point, customer equipment, managed router or firewall responsibilities and the process for fault diagnosis. For remote locations, verify how the connection is delivered and what support access is possible if the primary path fails.
Evaluate performance with evidence
Do not rely only on a headline speed. Review the performance the applications need and how it varies during normal and busy periods. Where possible, test the current service from the affected site and record latency, loss, utilisation and application response. Compare results at consistent times and against an agreed requirement.
Investigate the full path. An issue may come from the local network, wireless coverage, device, DNS, security inspection, carrier access, internet routing or application service. Changing a carrier without evidence may leave the actual fault untouched.
AltTab’s original post claimed that up to 80% of network performance comes down to the underlying carrier, but it supplied no source or methodology. That statistic is not repeated here. The proportion of any performance issue attributable to a carrier depends on the specific service and evidence available.
Check support and contract boundaries
Understand how the carrier defines a fault, what information it needs, how status is communicated and who can escalate a case. Read the service commitment and exclusions. Confirm whether the commitment applies to the access circuit, end-to-end availability or another defined component. Do not assume a service-level term covers a cloud application or every part of the site network.
Identify who manages the provider relationship and who collects evidence when a fault occurs. If a managed service provider is involved, clarify who opens the carrier case, who coordinates troubleshooting and which changes need customer approval.
Treat carrier diversity carefully
Two circuits do not necessarily provide independent resilience. They may share a conduit, exchange, local access provider, upstream route, building entry or power source. Ask for route and service diversity information where the business requirement justifies it, and document what the provider can confirm.
If a secondary service is intended for failover, test how it behaves. Confirm routing, security policy, address changes, application reachability, monitoring and how the team returns to the primary path. A backup link that has not been tested may not support the assumed recovery plan.
Make the choice by location
Create a comparison for each site that includes the application requirement, available access technology, performance evidence, support model, contract conditions, cost inputs from the quote and resilience design. Use a consistent evaluation method, but allow the preferred service to differ by location.
When a site is critical, consider the effect of an extended outage and whether an alternative path, wireless service or manual process is appropriate. Confirm the operational and commercial details before committing. Avoid treating “telco-agnostic” as a guarantee that one carrier will be available or suitable everywhere.
Find the right owner for the problem
Carrier choice matters, but it is one part of the network design. Review the evidence across site LAN, wireless, DNS, security controls, carrier access and application dependencies before deciding what to change.
Read how to troubleshoot DNS-related delays and how to design resilience beyond one connection. For AltTab’s current network assessment, carrier and resilience considerations, see Networking and connectivity.