An email failed to arrive. Not all emails—the billing emails continued to arrive at the same address with the regularity that billing emails require, which was the first piece of evidence I offered and which the support system declined to treat as evidence. The billing emails arrive.
The specific category of emails does not arrive. The difference between the two categories is not at my end, because my end is the same for both. The difference is at the sending end, where something in the configuration distinguishes between the two categories in ways that produce different results. This is a rational hypothesis. It is not proof. It was, however, the most parsimonious explanation available given the observable facts.
The support system’s explanation was that I should check my spam folder. I checked it. The emails were not there. The support system’s explanation was that I should consider using a more common email domain. I noted that the billing emails reached my uncommon domain without incident. The support system’s explanation was that the issue might be at my end. I noted again that my end was identical for both categories of email and that only one category was failing. Six emails and a phone call later, a technician agreed that the issue was at their end.
The technical fault was forgivable. Technical faults occur. The six emails and the phone call were the problem—not as inconvenience, though they were inconvenient, but as a demonstration of something structural about how support systems process testimony from users who have already done the diagnostic work.
The support system was not dealing with a bot. It was staffed by people whose professional role is the identification and resolution of technical service faults. The role description implies a function—the investigative function of someone who takes the available evidence, assesses it against the possible explanations, and pursues the most plausible one. What the interaction revealed was that the role is not primarily investigative. It is primarily procedural. The person at the other end of the email was not functioning as an independent diagnostic authority. They were functioning as an executor of the first-tier remediation script, with escalation pathways for situations the script could not resolve.
The script was designed for the standard user encountering the standard problem. The standard problem is that the user’s configuration is preventing the email from arriving—the spam filter is catching it, the domain is being blocked, the settings need adjustment. The standard remediation is to direct the user toward these possibilities in the order of their statistical frequency. The script is efficient for the standard problem. It is structurally incapable of processing the non-standard problem—the problem where the user’s configuration is demonstrably not the issue, where the available evidence points toward the sender rather than the receiver, where the rational hypothesis is the one the script does not contain.
The script continued to produce its standard outputs against evidence that contradicted its assumptions, because the script does not update on evidence. The script runs. The script concludes. The script recommends Gmail.
The Gmail suggestion deserves particular attention because it reveals the system’s preferred resolution to the mismatch between the evidence and the script. The system cannot process the evidence. The system can process the user’s conformity to the expected configuration. The Gmail suggestion converts the system’s sender-side problem into a user-side solution: if the user adopted a more common domain, the friction would disappear from the system’s perspective. The sender-side inconsistency would continue to exist, but it would be hidden by the user’s adaptation to the system’s preferred norm. The system would register the problem as resolved. The problem would not have been resolved. The user would have absorbed the cost of the system’s unaddressed fault.
This is the pattern that runs through the collection of essays that have preceded this one. The freelancer whose income is irregular is asked to present an income that resembles employment. The patient whose condition is real but not fitting the diagnostic script is asked to submit to the tests that would establish a diagnosis the script can accommodate. The person whose social situation does not match the imagined user is not referred to a service that would address their actual situation—they are not referred at all. The non-standard user is consistently asked to bear the cost of the system’s calibration for the standard user, because the system cannot adjust and the user is present and can.
The adjustment that the system requests of the user is presented as practical advice. In some cases it is practical advice—the workaround that addresses the immediate problem even if it does not address the underlying fault. In other cases it is the system’s refusal to locate its own fault dressed as user guidance. The Gmail suggestion was the second kind. The billing emails were arriving. The system’s configuration was producing the inconsistency. The suggestion that I should change my domain to receive emails that should have arrived to the domain I have was a suggestion that I should make myself more legible to a system whose fault had made me less legible.
The credibility asymmetry is the part of the experience that produces a specific kind of irritation that is distinct from the irritation of the fault itself. Technical faults produce the irritation of inconvenience. The credibility asymmetry produces the irritation of being required to prove something that should not have required proof—of having a correct diagnosis repeatedly discounted because the support system’s model requires the user to be less informed than the evidence indicates they are.
The model requires this because the standard user is less informed. The standard user encounters an email delivery failure and does not have a hypothesis about sender-side configuration inconsistency. The standard user checks the spam folder, considers their settings, possibly creates a Gmail account, and either resolves the issue at their own end or abandons it. The standard user’s experience of the interaction confirms the script’s assumptions: the problem was probably at the user’s end, and the script’s remediation directed the user toward the relevant adjustments. The script worked.
The non-standard user’s experience of the same script is different. The non-standard user already knows their end is not the issue. The script’s remediation directs them away from the actual problem and toward adjustments they have already made or that are irrelevant to their situation. Each iteration of the script is not assistance. It is a requirement to prove, again, that the script’s assumption is wrong. The proving takes time. The time is the user’s. The fault that required the proving is the system’s.
The unpaid quality assurance function that this produces is one of modern bureaucracy’s more quietly significant features. The standard user who encounters a system fault is routed around it, by the system or by themselves, and the routing conceals the fault from the system’s internal view. The fault continues to exist. It continues to produce failures for users who encounter it. The users who encounter it are not reporting it in ways the system registers as evidence that the fault exists, because the system’s remediation pathways direct them toward user-side adjustment rather than toward fault diagnosis.
The non-standard user who refuses to be routed around the fault—who persists, who provides evidence, who requires the system to update its diagnosis against the available facts—is performing diagnostic labour that the system should be performing and is not. The labour is unpaid. The result of the labour—the technician’s eventual agreement that the fault was at the sender’s end—is a piece of information the system now has that it did not have before the non-standard user’s six emails and phone call produced it. The system has not paid for this information. The non-standard user has. The payment was time and the specific frustration of being required to prove, repeatedly, something that should not have required proof.
Error is expected in complex systems. Technical configurations fail. Email delivery is more complicated than it appears and more things can go wrong than most users are aware of. The error, in this case, was forgivable in the sense that it was not implausible or negligent. What degraded trust was not the error but the resistance to correct diagnosis—the structural inability of the support pathway to update its assessment when the evidence contradicted the script’s assumption.
The Belong essay described an organisation whose silence produced the experience of not being seen. This essay describes a different institutional pathology: an organisation whose processing produced the experience of being seen incorrectly and required to prove, at length, that the incorrect seeing was incorrect. Both experiences are produced by the same underlying condition—the system’s calibration for the standard case operating in contact with a non-standard one.
Belong assumed a user who would not push back on silence.
The ISP assumed a user who would not push back on the script.
Both assumptions were wrong in this case.
Both assumptions are right often enough that the systems continue to make them.
The problem was technical.
The ordeal was systemic.
The distinction is where the frustration lives.
The Vorpel Foundation