I2PS SOLUTIONSENGINEERING BLOGi2psolutions.com
Personal Experience

When Reputation Isn’t Enough

Conflict Still Ongoing

A. RemaniFounder, CEO & Head of Engineering · I2PS Engineering

Abstract

Over recent weeks, an unresolved Google Fi connectivity issue has moved from inconvenience to an operational and safety concern. For a remote oil engineer working in Africa, sometimes far from conventional infrastructure and in environments where security planning matters, dependable communication is not merely a consumer convenience. This article examines what reputation should mean when a service fails: ownership, clear escalation, fair billing, a concrete resolution path, and recognition of the real-world context in which the customer depends on the service.

Keywords: telecommunications, Google Fi, remote operations, oil field, Africa, connectivity, safety, service reliability, escalation, billing dispute, engineering redundancy.

There is a particular reason this dispute deserves to be documented publicly: the same service failure can have very different consequences depending on where the customer is standing.

For me, this is no longer only about whether a phone has bars. It is about what happens when an essential communications service fails while the customer is working remotely and the support process cannot provide a clear end point.

Reputation Is Supposed to Reduce Uncertainty

There is a reason engineers working in remote environments often choose established companies. We do not always choose them because they are the cheapest. We choose them because reputation is supposed to reduce uncertainty.

When your work takes you far from cities, into industrial sites and remote field locations, essential services are selected differently. You are not only buying a product. You are buying the expectation that the company behind it has mature systems, competent support and a credible way to recover when something fails.

That expectation is at the center of my current dispute with Google Fi.

When Connectivity Becomes Part of Safety

Over recent weeks, I have been dealing with a loss of dependable connectivity while relying on Google Fi internationally. Support has been contacted, the matter has been escalated, and the issue remains unresolved.

For someone in a city, losing mobile coverage can be frustrating. For a remote oil engineer, it can become something else entirely.

I work in Africa, including remote environments where distances are large, infrastructure can be limited and security planning is part of normal operations. In some of the environments where I work, risk assessments specifically consider threats to foreign and Western personnel. In that context, communication is not simply about convenience or productivity.

It can be the means by which a person checks in, coordinates movement, receives updated instructions, contacts colleagues, reports a change in conditions or requests assistance. A communications failure therefore has to be considered in the context in which the service is actually being used.

The Sahara Changes the Meaning of “No Service”

The phrase “no service” sounds almost harmless when read on a phone screen.

In the middle of nowhere, it has a different meaning.

Remote oil and energy operations can involve long distances between populated areas, limited alternative infrastructure and work locations where a normal urban assumption—simply finding another Wi-Fi network—does not apply.

That is why I do not consider this only a customer-service complaint. I consider it a reliability issue with a safety dimension.

A company does not need to guarantee that every network works everywhere. No responsible engineer would demand an impossible guarantee. What matters is how clearly limitations are communicated, how failures are handled, whether the customer is given a realistic path forward, and whether the company recognizes when the consequences extend beyond inconvenience.

Escalation Is Not Resolution

One of the most frustrating parts of the process has been the repeated concept of escalation.

The case moves to a higher level. Then another level. The customer is told that the matter is being reviewed. Yet the most basic operational question can remain unanswered: when will it be resolved?

In engineering, escalation is useful only when it transfers a problem to someone with greater expertise or authority and moves the system closer to recovery. Escalation without ownership, corrective action or a deadline is administrative motion, not resolution.

If a critical piece of field equipment failed, “we escalated it” would not be an acceptable final status. Someone would own the failure. A corrective action would be defined. A target date would be established. The result would be tested.

That is the level of clarity I am asking for here: who owns the issue, what is being done, and what is the expected resolution date.

Billing While the Service Remains Disputed

The dispute became more serious when the bill arrived while the underlying service issue remained unresolved.

My position is clear: I will dispute charges for service that I contend was not properly provided while the issue remains unresolved. If additional bills are generated under the same circumstances, those charges will also be disputed through the appropriate process.

This is not a refusal to pay a legitimate charge. It is a dispute about the relationship between billing and delivery of the service being billed.

When an essential service problem remains open through repeated escalation, continuing to invoice the customer without providing a concrete resolution path creates a second dispute on top of the first one. The technical problem becomes a billing problem, then a support problem, then an escalation problem. Eventually the organization can spend more effort moving the case than solving the original failure.

What Reputable Service Should Mean After Failure

No network is perfect. No technology company is immune to failure. Roaming can fail. Coverage can vary. Devices can malfunction. Software can contain bugs. Partners can have outages. These realities are not controversial.

The real test of reputation begins after something goes wrong.

Does the company acknowledge the problem clearly? Does somebody take ownership? Can the customer reach a team with authority to act? Is there a temporary alternative? Are disputed charges handled fairly? Is there a concrete date or at least a technically credible resolution window?

Reputation should not mean that failure never happens. It should mean that failure is handled professionally.

The Engineering Lesson: Reputation Is Not Redundancy

There is also a lesson here for engineers and anyone who works remotely: never allow the reputation of a supplier to replace redundancy.

A reputable company may reduce risk. It does not eliminate risk.

Critical power systems need backup paths. Important data needs backups. Safety procedures need contingencies. Communications for remote work should also have redundancy appropriate to the environment and the risk.

That principle does not remove responsibility from the service provider. It simply recognizes a basic engineering truth: any single component can fail.

Good engineering assumes failure is possible. Good service shows what happens after the failure.

The Conflict Is Still Ongoing

As of 18 August 2026, this matter remains unresolved.

I have received the bill. I have raised the connectivity problem. I have requested escalation. I have asked for clarity about the charges. I have explained that the loss of dependable connectivity is a serious safety concern in the context of remote work in Africa. And I have asked for something very simple: a concrete resolution date.

I do not need another undefined “higher level.” I need ownership and a deadline.

If a concrete resolution date cannot be provided, then the matter should move to the appropriate claims or executive-resolution process where responsibility can be clearly established.

Reputation Is Tested After Failure

This article is not an argument that Google Fi never works, nor is it a claim that every customer will have the same experience. It is an account of an ongoing service dispute and the broader engineering question it raises.

What are we actually buying when we choose a reputable company?

Part of the answer is the service itself. The other part is confidence in what happens when the service fails.

For people working remotely, sometimes in difficult operating environments, communications may form part of the infrastructure that allows us to work safely. That is precisely why established providers are chosen.

A strong brand creates expectations. The most important of those expectations may not be perfection. It may be accountability.

And accountability begins with a clear answer to a very simple question: who owns the problem, and when will it be resolved?

Editorial note: This article describes the author’s personal experience and an ongoing service dispute as of 18 August 2026. It does not claim that the experience described represents all Google Fi customers.

About the Author

A. Remani

A. Remani is the Founder, CEO, and Head of Engineering at I2PS Engineering. His background includes remote oil-field and industrial work, engineering, product development, field operations, and the design of systems intended for demanding environments.

Closing Reflection

For remote operations, connectivity can be infrastructure, not convenience. Reputation matters most when the expected service fails and the provider must demonstrate ownership, transparency and a credible path to resolution.