A service designed to address loneliness sent me an email. The email explained that my account had been inactive and invited me to reopen it by following a few easy steps. The steps were accessed through a link. The link was not a link in any sense that a person reading an email would recognise as functional.
It was a URL of approximately three hundred characters, broken across four lines of the email, each line ending mid-string because whatever system had generated the email had not checked whether the URL would remain intact after it was inserted into the message template. The string was not clickable. It was not copyable in any practical sense. It was a procedural vine that had grown across the bottom of the email and been presented as a staircase.
Follow a few easy steps, if you can find the staircase.
The system knew exactly who I was. It knew my account details, my previous engagement with the service, the specific reason it was writing, and the precise action it wanted me to take. It had all of this information assembled and organised. It had generated the email automatically, addressed it correctly, delivered it successfully to my inbox, and embedded within it a tracking and attribution object of considerable operational sophistication—encoding campaign source, user state, localisation parameters, tenant markers, customer identifiers, and analytics variables that would allow the system to know, with precision, whether I had clicked, when I had clicked, from what device I had clicked, and what I had done subsequently.
The system had done all of this correctly.
It had not checked whether I could use the result.
The URL is the most visible symptom of a condition that is structural rather than technical. The condition is the prioritisation of system-readable over human-readable—the tendency of complex automated systems to optimise for their own internal operational requirements before optimising for the intelligibility of what they produce for the person on the receiving end. The tracking parameters embedded in the URL are not there for me. They are there for the system’s analytics infrastructure, which needs to know where the click came from and what it produced. The parameters are entirely legible to the database that will receive them. They are entirely illegible to the person who received the email.
A link that says Click here to reopen your account would have served me better. It would have served the system’s user-facing purpose better. It would have required a trivially small additional design decision—the decision to make the URL human-readable by wrapping it in text, or to shorten it through one of the several available mechanisms that exist precisely for this purpose, or to test whether the URL survived line-wrapping in the email templates the system was using. None of these are technically difficult. All of them would have converted the procedural vine into a usable staircase.
The decision was not made, or was not made correctly, which means that at some point in the system’s design and operation, the requirement to track and attribute the click was operationally prioritised over the requirement that the person receiving the email be able to take the action the email was requesting. The tracking was essential. The usability was assumed. The assumption was wrong.
The email was sent by a service designed to address loneliness. This is the detail that makes the instance more than an anecdote about poor URL management. The service exists to connect isolated people with social opportunities, to reduce the gap between the isolated person and the connection they need. It was established because someone observed that isolated people had difficulty finding and accessing social connection, and decided to build a system to help them.
The system built to help isolated people access social connection sent those people an email that, in its most functionally critical element, could not be used by the person who received it. The system had optimised for its own operational coherence—the tracking, the attribution, the analytics infrastructure that allows the system to report its reach and engagement to the funders whose continued support the system requires—and in doing so had produced a communication that was internally coherent and externally unusable.
This is the pattern that the preceding essays have been tracing through different surfaces. The system measuring its own activity rather than its outcome. The response that exists at the level of the system’s record without existing at the level of the person’s experience. The communication designed to be tracked rather than used. The staircase hidden behind the telemetry scaffolding and presented, with institutional cheerfulness, as a few easy steps.
The particular fatiguing quality of this kind of encounter is distinct from the frustration of encountering a hostile system or a negligent one. The system that sent the email was not hostile. It was well-intentioned, professionally administered, and genuinely attempting to re-engage a user who had been inactive. The email was courteous. The invitation was warm. The few easy steps were presented as an act of helpfulness.
The helpfulness failed at the point of execution without anyone in the system noticing, because the point of execution—the moment at which the email became a communication rather than a data object—was outside the system’s primary monitoring scope. The system monitored what it could monitor: delivery rates, open rates, click-through rates. The click-through rate for this email would show that I had not clicked. The system would record the non-click as a data point. The data point would inform future communications—perhaps a follow-up email, perhaps a different subject line, perhaps a different send time. The system would not record that I had not clicked because the link was broken. The system did not have a mechanism for recording this, because the mechanism would require the system to check whether the email was usable from the recipient’s perspective rather than complete from the system’s perspective.
Completeness from the system’s perspective and usability from the recipient’s perspective are different things. The email was complete. It had all the required elements: the personalised salutation, the account status information, the call to action, the legal disclaimer, the unsubscribe link. Each element had been generated and inserted correctly. The system had produced the email it was designed to produce. The email could not be used for the purpose it had been designed to serve.
The legal, analytics, marketing, and localisation requirements that typically append themselves to the URLs in automated CRM emails are each, individually, legitimate. The legal team requires specific disclosures. The analytics infrastructure requires tracking parameters. The marketing team requires campaign attribution. The localisation system requires tenant markers. Each requirement is real. Each is added to the URL by the relevant system at the relevant point in the generation process. No single system is adding an unreasonable requirement.
The accumulation of these requirements produces a URL that is three hundred characters long, broken across four lines, and non-functional. The accumulation is not unreasonable in any individual step. It is unreasonable in its aggregate effect on the person who receives it. There is no central node in the system that asked, before the email was sent, whether the person who received it would be able to use the link. The question was not in anyone’s operational remit. It fell between the remits of the legal team, the analytics infrastructure, the marketing system, and the localisation layer, none of which was responsible for the coherence of what they collectively produced.
This is the no-one-is-steering problem that is visible across the systems these essays have examined. The individual components are maintained by the people responsible for them. The coherence of what the components produce together, from the perspective of the person who receives the output, is not anyone’s specific responsibility. The output is generated. The output is delivered. The output cannot be used. No record of the unusability enters the system, because the system records its own activity rather than the recipient’s experience of its activity.
When administrative sprawl wears a smile, the smile is the institutional cheerfulness of the communication’s tone and the sprawl is the procedural complexity that the tone is covering. The email was warm. The email was friendly. The email expressed genuine pleasure at the prospect of my re-engagement with the service. The email presented a broken link as a few easy steps.
The warmth and the brokenness coexisted without apparent tension, because they were produced by different parts of the system. The tone was produced by the communications team, or by the template they had approved. The link was produced by the CRM system, or by the concatenation of parameters that the CRM system had assembled. Neither component knew what the other had produced. The tone did not know the link was broken. The link did not know the tone was warm. The combination arrived in the inbox as a single coherent communication that was, at its most functionally critical point, not coherent.
The service designed to address loneliness had sent an email whose most important element—the path to the service—was not usable by the person to whom it had been sent. The person remained at a distance from the service. The system recorded a non-click. The service continued to address loneliness.
The staircase was there.
It was behind the scaffolding.
The email did not mention this.
It called the scaffolding steps.
The Vorpel Foundation