An email arrived from a Business Development Executive. The subject line read: “Reaching out regarding your expressed interest.” I had not expressed interest. The company had contacted me. This is not a small inaccuracy. It is the entire architecture of the email, stated in the first line.
The account in question had already been verified. The email did not know this, or did not check, or checked and found something the system read as ambiguous. What it found, it translated into concern. The language was warm and specific: I may be experiencing difficulty. This was not a question. It was presented as information the sender had about my situation. She did not have this information. She had a trigger.
The title beneath the email was a Business Development Executive. The email offered technical guidance or support. These two things do not belong together, and the email did not notice. Business development means relationship, revenue, expansion into new accounts. It does not mean knowing why a verification flag is sitting on a system. The offer of technical support was not a description of capability. It was a sentence drawn from a template that had absorbed the language of several different roles—sales, support, onboarding, customer success—and deployed them all at once without being answerable for any of them. She speaks in every register. She occupies none.
After establishing that I may be having difficulty, the email asked whether I needed help. The question followed the assertion without acknowledging the gap between them. If the system believed I was having difficulty, the next step was not inquiry—it was assistance. Instead the email stopped at the edge of the problem and waited. This is not attentiveness. It is a procedural requirement. Confirmation must be obtained before the next stage can begin. The system cannot proceed without logging that the user has asked it to proceed. The question is not curiosity. It is compliance in the shape of a sentence.
There were no links in the email. No documentation, no checklist, no path to resolution. This is the most direct evidence of what the email was for. A message designed to solve a problem includes the solution, or at minimum the direction of one. This email included an offer, a question, and an invitation to reply. It was structured to continue the interaction, not to end it. Resolution closes a loop. A closed loop produces no further engagement. The system needs engagement, so the loop stays open.
I have been on the receiving end of a version of this situation before. Not always with email. Sometimes with a phone system that knows, before you select an option, that your recent transaction may be causing concern—did you call about that? The affect is helpful. The architecture is circular. You confirm the concern, you are placed in a queue, you speak to someone who opens a ticket, you receive an automated message, the ticket closes. Whether the concern was addressed is a question that lives outside the process.
The internet I remember from before this one was not like this. That network did not perform concern. Gopher returned files. Usenet delivered posts. If something was wrong, you read the error, and the error described the problem with reasonable accuracy, and you knew where to look. The system assumed you could read. It assumed you would act on what you read. Directness was not a design philosophy—it was simply the only approach that made sense when the people using the system were expected to understand it.
At some point the assumption changed. The new internet was not built for people who understood the structure underneath. It was built for scale, which meant it had to work across people with very different levels of engagement, patience, and technical knowledge. The solution was mediation. More interface, more language, more process between the user and the thing. The process could guide someone who needed guiding. For anyone who did not need guiding, the process added friction without adding value. This is not a complaint. It is the correct description of a trade-off that was made deliberately and in one direction.
The Business Development Executive sits at the front of a funnel. This is a spatial metaphor the industry uses comfortably. Wide at the top, narrow at the bottom. She receives contact, generates a response, and moves the interaction toward the next stage. What the next stage is depends on whether I reply. If I reply, a further process begins: authentication, assignment, perhaps a handoff to someone with the word technical in their title. The funnel narrows. At some point, if the narrowing continues, something may be resolved. This is the optimistic version.
What I expected was different. The account had been verified. The email was wrong about my situation. A system with access to my account status could have checked. Perhaps it did check and found an ambiguity. The correct response to an ambiguity is to state it precisely: we see this flag, we are not sure what it means, here is what to do if it is a problem. Instead the email stated my difficulty as fact, offered help it may not be able to provide, asked a question it had already answered, and provided no mechanism for resolution. The gap between what was implied and what was delivered is not accidental. The email was not a vehicle for resolution. It was a vehicle for contact.
There is a formulation that follows from this. The system cannot reliably determine my state. It cannot directly resolve my state. It can send an email. So it does the one thing it can do with certainty and calls that thing assistance. The offer is the assistance. Everything else—links, instructions, actual guidance—would require the systems to talk to each other, the state to be accurately tracked, someone to own the outcome. These are harder than sending the email. The email is what scales.
Somewhere in the process there is a person who verified the account—me, completing a form, uploading a document, clicking a link. The system registered this, or did not register it cleanly, and produced the email. The email assigned to me an interest I had not expressed, a difficulty I did not have, and a need that the email would not address even if I confirmed it. Every element of the interaction was attributed outward, onto me, in language that sounded attentive and was not.
The subject line does this most efficiently. Reaching out regarding your expressed interest. Words of agency assigned to the wrong party. I did not reach out. She did. This is not a technicality about email headers. The subject line is the system’s description of the nature of the interaction, and its description is precisely inverted. The company contacted me and the email recorded that I had contacted the company. The record will show engagement. The record will show interest. I expressed neither.
A functional version of this email would take three sentences. We noticed your verification may not have completed. If that is the case, here is the link. If it has completed, no action is needed. That version closes the loop, requires no reply, and produces no further engagement. This is why it was not sent.
