I left the first energy provider. Not in frustration, exactly—frustration implies that the outcome was unexpected, and by the time I left I had a fairly precise understanding of what the system was and what it was not going to do.
I left because I had identified the constraint clearly enough to know that continuing to engage with it was not going to produce a different result.
The system could not change a name on an account. It could close an account and open another. It could not carry an identity across the gap between the two. It could offer steps to follow. The steps led back to the same constraint. I stopped following them.
I signed up with a different provider the same day.
The contrast was immediate, which made it instructive in a way that a smoother experience would not have been. The new provider is larger than the one I left. Its systems are not simpler—a company of that scale operates infrastructure of considerable complexity, managing accounts across a large customer base, handling billing, metering, transfers, complaints, and the various administrative events that arise across the lifecycle of a utility relationship. The complexity is real and present. What differs is not the amount of complexity but where it sits.
The online sign-up failed. A form did not complete. The process stopped before the account existed.
In the first provider’s system, this kind of failure produces a loop. The incomplete process sits in an indeterminate state. The system has a partial record but not a complete one. Attempting to continue requires re-entering the same data. Attempting to verify identity encounters the partial record. The user must determine what state the process is in, which requires navigating between screens that each assume the process is in a different state, and resolve the inconsistency through trial and re-entry. The system does not acknowledge that it has produced a contradictory state. It presents each step as though the previous step had completed normally.
When the new provider’s sign-up failed, the system transitioned. Not looped—transitioned. It recognised that the online process had not completed and moved to an alternative channel. I made a phone call. The person on the phone knew the sign-up had been attempted and had not completed. They did not ask me to re-enter everything. They did not ask me to prove I was the person who had just attempted the sign-up. They continued from where the process had stopped.
The account was created. The process had taken two steps through two channels. It had not required me to understand why the first channel had failed, or to resolve the failure before proceeding, or to start again as though the first attempt had not occurred.
The phone system itself was worth noting, because phone systems are usually where the contrast between a functional and a performative approach becomes most visible. The recorded message did two things. It acknowledged that my time had a cost—not as a courtesy phrase, not as your call is important to us, but by offering alternatives that actually functioned. If waiting was not acceptable, something else was available. The acknowledgement was supported by an option that worked.
Most phone systems acknowledge wait time as a social gesture—the phrase exists to soften the experience of waiting, not to address the waiting itself. The acknowledgement and the experience are decoupled. You are told your call is important while the mechanism that would demonstrate its importance—an alternative that reduces the wait—is absent or non-functional. The phrase substitutes for the action.
The new provider’s system coupled the acknowledgement to an action. The action worked. This means the system had been designed with the assumption that the user’s time has value, and the assumption had been built into the structure rather than expressed in the script.
The transfer from the old provider will be handled by the new one. I was told this directly and it was confirmed in the account setup. The administrative sequence required to close one account and open another—the sequence that the first provider had placed entirely on my side of the interaction—had been absorbed by the new provider as a routine part of its own process. It handles transfers as a standard operation. The previous provider’s account will be closed. The service will continue. The timing will be managed. I will be notified when the transfer is complete.
I did not have to navigate the gap between the two accounts. I did not have to manage the identity conflict that the gap produced. I did not have to call both providers and coordinate between their separate systems. The new provider took the transition as its problem, not mine. This is not a feature it advertises prominently. It is simply how the process works. The work of continuity sits with the system.
The technical capability is roughly equivalent. What differs is where the complexity sits.
Both providers operate at scale. Both have automated systems, verification processes, customer databases, billing infrastructure. Both can send emails and receive calls and process payments and manage metering data. The technical capability is roughly equivalent. What differs is the structural orientation of the capability—specifically, which side of the interaction bears the cost of the system’s complexity.
Some systems export their complexity. They present each process to the user as a task to be completed, and when processes conflict, the user is required to resolve the conflict. The system’s internal coherence becomes the user’s problem. Identity constraints, sequencing requirements, validation failures—these are communicated as steps the user must navigate rather than as conditions the system should manage. The user becomes part of the system’s operation. Their role is to provide inputs that resolve the system’s own inconsistencies.
The first energy provider operated this way. Its systems were internally coherent in the sense that each part functioned according to its own rules. The rules produced contradictions when applied to a simple request—a name change on an existing account—because the rules had not been designed with that request in mind. The system had no path for it. Rather than acknowledging the absence of a path, the system offered paths that existed for other purposes, which produced the loops and dead ends I have already described. I was required to navigate these not because the navigation served my purpose but because it was all the system had available.
The second provider operated differently. Its complexity was present—the failed sign-up was evidence of that, a real error in a real process—but when the complexity produced a failure, the system absorbed it. It transitioned to an alternative. It maintained state across the transition. It did not require me to understand the failure or to reconstruct the process from the beginning. It recognised that its internal problem was its internal problem, not mine.
The difference is not friendliness. Friendly language appears in both systems. Both thank you for your patience. Both express regret for any inconvenience. Both use the register of customer care, the warm tone, the phrasing that signals concern. The friendliness is a property of the communication layer, which both systems have calibrated to similar standards. It is not a property of the structural orientation, which differs entirely.
A system that exports its complexity can be friendly about it. The scripts can be warm. The apologies can sound genuine. The experience can feel personal, even as the user is being asked to perform work the system should be doing. The friendliness and the burden are not mutually exclusive. They co-exist routinely.
A system that absorbs its complexity does not need to compensate for the burden it places on the user, because the burden is not placed on the user. The friendliness, when it appears, is ambient rather than compensatory. It is not working to offset something.
The first provider’s phone system told me my call was important. The second provider’s phone system gave me an alternative that worked. Both were friendly. One of them was also functional.
I have been examining, across a range of interactions, the pattern by which systems substitute their own activity for the outcomes they are supposed to produce. The review requested before any service has been delivered. The verification process that requires more data than the organisation already holds. The opt-out that demands full participation in the system it is opting out of. The response that arrives promptly and does not answer the question. The security measure that measures its own completion rather than actual security. In each case the system has oriented itself around what it can record rather than what the user needs to occur.
The second energy provider is a counter-example to this pattern, which is why the contrast was immediate. The system had oriented itself around the outcome—a functioning account, a transferred service, a user who could proceed without understanding the administrative structure beneath the process. When something failed, the system absorbed the failure. When a transition was required, the system managed the transition. When my time had a cost, the system treated it as a cost and offered something in response.
The work was done on the system’s side.
This is not extraordinary. It is the minimum that the description of a service implies. A service takes a need and moves it toward resolution. The work of moving the need is the service’s work. When that work is exported to the user, the service is not being provided. A process is being provided. The process and the service are not the same thing.
One system required me to fix it.
The other replaced it.
The difference is where the work is done.
