A business failed to send me an email. I know this because I receive every other communication from them without difficulty, including the billing emails that arrive to the same address with the regularity that billing emails require.
The specific email—a confirmation of something I needed to confirm—did not arrive. I raised this with them.
They told me to check my spam folder. I checked it. The email was not there. They told me to consider using a more common email domain. I noted that the billing emails reached my uncommon domain without incident. They told me the issue may be at my end. I noted that the issue was demonstrably not at my end, because the same address receives their other communications without difficulty. They told me they would look into it. Nothing resolved. I have decided to wait and see, which is the decision available to a person who has exhausted the interaction’s productive possibilities without exhausting the interaction’s procedural ones.
This is Kafka in Orwell’s 1984 caught in a Catch-22, with the addition of a Claytons solution: the help you receive when you are not receiving any help.
Kafka supplies the architecture. The system that produces the failure is not reachable through the interface the system provides for reaching it. The people answering the support communications are not the people who can examine the outbound sender configuration. The people who can examine the outbound sender configuration are not accessible through the support channel. The support channel produces responses that are scripted for the standard user encountering a standard problem. The standard response to email delivery failure is: check your spam folder, consider your domain, check your settings. These responses are correct for the standard problem. The standard problem is that the user’s configuration is preventing the email from arriving. The non-standard problem—that the sender’s configuration is producing inconsistent outbound behaviour across departments—is not in the script. The script cannot acknowledge what it does not contain. The support communication continues to produce the script.
Orwell supplies the narrative enforcement. The system’s version of events, maintained through each communication, is that the problem lies at the user’s end. This is not a position the system arrived at through investigation. It is the position the script begins with, and the script does not have a mechanism for revising it in response to the evidence the user provides.
The user’s evidence—that the billing emails arrive without difficulty to the same address—is received by the script as additional information to be absorbed without changing the conclusion. The conclusion is that the user should check their spam folder. The user has checked the spam folder. The conclusion remains that the user should check their spam folder.
Catch-22 supplies the self-sealing logic. The more technically precise the user becomes in describing the problem, the more the user is classified as the problem requiring simplification. The person who says the email didn’t arrive is describing a problem the script can process: check the spam folder. The person who says the outbound sender configuration appears inconsistent across departments is describing a problem the script cannot process, and the script’s response to problems it cannot process is to return to the beginning and offer the spam folder again. Technical precision disqualifies the user from the script’s remediation pathway. The qualification for the pathway is the presentation of the problem in the terms the script can receive. The terms the script can receive do not include a diagnosis of the system’s own behaviour. The diagnosis is therefore returned to sender, undelivered.
The Claytons solution is the distinctly contemporary addition to the literary catalogue. It is the solution you receive when you are not receiving a solution—the appearance of assistance in the absence of the function. The support ticket is opened. The ticket receives a response. The response contains actionable instructions. The instructions are followed. The instructions do not address the problem. The ticket is updated. A further response arrives. The further response contains different actionable instructions. The instructions are followed. The problem remains. The ticket registers ongoing engagement. The engagement is the product the support system produces. The resolution is a different product that the support system may or may not produce as a byproduct of the engagement.
The Claytons solution works because the appearance of assistance is sufficient to manage the customer’s experience within the tolerances the system was designed to maintain. The standard user, encountering email delivery failure, receives the spam folder instruction, accepts it, concludes their own settings must be the issue, adjusts the settings, and either receives the email eventually for unrelated reasons or abandons the need for the email and moves on. The system has managed the experience. The system has not diagnosed the problem. The problem may still exist for the next standard user who encounters it, who will also be directed to check their spam folder.
The standard user is a design fiction rather than a description of an actual person. Systems design their interfaces around a model user whose characteristics make the interface manageable—who encounters failures in the expected ways, who accepts the scripted responses as adequate, who does not possess the diagnostic capacity to distinguish between a user-side failure and a system-side failure, who moves through the support pathway without generating the kind of friction that reveals the pathway’s limits. This user is easier for the system to manage not because the system serves them better but because the system’s failures are less visible to them.
The non-standard user—the user whose technical literacy exceeds the script’s assumptions, whose email domain is outside the system’s expected configuration, whose capacity for diagnosis is more precise than the support script can accommodate—is not a user who experiences worse service in any meaningful sense.
They experience a service that is equally limited but whose limits are more legible to them. The failure that the standard user absorbs as vague uncertainty, or attributes to their own inadequacy, or resolves by accepting a workaround that does not address the underlying problem, is visible to the non-standard user as a specific system behaviour that the script is failing to acknowledge.
The deviation from the standard user model is therefore not the cause of the problem. It is the condition that makes the problem visible as a problem rather than as an unexplained outcome. The outbound sender configuration that is inconsistent across departments fails for the standard user and for the non-standard user alike. The standard user concludes their settings are the issue. The non-standard user concludes the sender configuration is the issue. The first conclusion is manageable for the system. The second conclusion is not, because it locates the failure inside the system rather than outside it.
The institutional preference for the first conclusion is not the product of deception. It is the product of a support system designed to manage the volume of interactions the system generates, and the management of volume requires the standardisation of responses. The standardised response addresses the most common cause of the most common version of the problem. It cannot address all causes of all versions without becoming the kind of individually customised investigation that volume management precludes. The standardisation is the efficiency. The efficiency is the product. The product does not include the diagnosis of system-side failures that appear in a small enough percentage of cases to be below the threshold at which standardised response is revised.
The small percentage of cases that reveal system-side failures are the cases most likely to involve the non-standard user, because the non-standard user is more likely to generate the conditions under which the system’s assumptions about the user are violated. The violation makes the failure visible. The visibility does not produce diagnosis, because the support pathway was not designed to receive diagnoses from users. It was designed to apply scripted remediation to user-side failures. The user-side failure remediation, applied to a system-side failure, produces the Kafka architecture: the response that addresses the wrong end of the problem without acknowledging that it has addressed the wrong end.
The system may eventually resolve the issue. The resolution may occur because someone in a different part of the system who was not involved in the support interaction happens to examine the outbound sender configuration for an unrelated reason and corrects it. The resolution will arrive without explanation. The support ticket will register a resolved status. The system will imply that things appear to be working normally now, as though the spam folder advice had been the relevant intervention.
The rational witness inside procedural unreality is a position that is both clearly defined and practically useless. The witness can see what is happening. The witness cannot make the system see it. The system processes the witness’s accurate account of events through a framework that was not designed to receive accurate accounts of system-side failures, and returns the account transformed into a version the framework can accommodate: the user should check the spam folder.
Evidence without agency.
The evidence is available. The agency—the capacity to direct the evidence toward someone who can act on it—is not available through the interface the system provides. The interface was designed for the standard problem. The standard problem is solved by checking the spam folder. The non-standard problem continues to exist behind the spam folder instruction, unaddressed, waiting for the accidental resolution that the system may produce without understanding what it has fixed.
I am waiting.
The email has not arrived.
The spam folder remains empty of the thing it was suggested might be there.
The system is confident that things should be working normally.
We have not yet established that they are.
The Vorpel Foundation