👻 SupportNightmares 🧛 - Call for Contributions

👻 The SupportNightmares collection - what is it about?

Organisations tend to provide products, services, experiences and a mix of these things that people may find useful. Successful organisations provide some of their “stuff” well enough that a sufficient number of people or other organisations (i.e. essentially a different group of people) are willing to pay enough for the “stuff” to enable the organisation’s continued existence. Ideally, after a transaction has taken place, both parties are happier or better off than they were before the transaction, or than they would be in the absence of the transaction. Transactions may span from one-off value exchanges to recurring transactions over a longer period of time, providing mutual benefit for the transacting parties. Transactions take place between dynamic entities (i.e. humans and organisations) operating in a constantly changing dynamic environment. It is one of a major achievements of humanity that in spite of all the things that could potentially go wrong, things are generally going well. Occasionally however, things may not go as usual, an expectation gets violated or unfulfilled, and presents itself as a problem for the perceiver.

Humanity has developed various functions to deal with problems that have come up throughout history. Illnesses are treated by doctors, nations are ruled by laws, uncertainty is managed through insurances, behavior is governed by agreements and contracts, the effects of natural disasters are partially mitigated by monitoring systems, the weather report warns ahead of a rainy day etc. Organisations are well-aware of the fact that a variety of things may go wrong inside and outside of their boundaries, so they have developed systems to deal with the problems that their customers may encounter while trying to extract the promised value from the “stuff” they obtained through a transaction.

These systems are known as support teams, often tasked with providing assistance, help and solutions to the customers of the organisation experiencing some kind of problem with their “stuff”. Getting in touch with a support team is generally motivated by some kind of suffering, where the best-case outcome is a break even or reaching the previous level of satisfaction that was degraded by the problem. People reaching out for support teams are generally in a miserable state, seeking relief from a suffering, not for the extra joy expected from the interaction. Getting in touch with a support team therefore, is similar to be admitted to a hospital which is rarely motivated by its hedonistic value, but is most often motivated by the desire to be free from suffering. While the effects of being relieved from suffering should not be underestimated—as anyone who has ever left a hospital healed from a frightening illness can attest to the liberating and uplifting experiences—a recovery is still a recovery: a return to the state before the problem. Getting help and getting a problem out of the way (i.e. the joy of returning to the baseline from below) is a valuable experience. But unfortunately the systems designed to shield humanity from harm are not free from vulnerabilities and weaknesses, thus they may fail to fulfil their purpose: to solve a problem. Support teams provide an excellent example of how things may go doubly wrong: first by failing to solve the initial problem which triggered the support request, and second by creating additional problems and frustrations by mistreating the customer as well.

The following non-exhaustive list provides some ideas about the kind of problems experienced by customers that may trigger an attempt to reach out to an organisation’s support team:

• improper measures and routines for securing the customers’ personal data resulting in data breaches which may open up the stage for spam, surveillance, extortion, identity theft, unauthorized payments with stolen credit cards, etc.,
• failure to cover a valid, legitimate insurance claim after decades of receiving regular payments from the customer,
• total lack of concern for the damages inflicted on the natural environment and on other humans,
• claiming that a payment is not received when it has been completed by the customer,
• profiting from the inaction of the customer (e.g. default auto-renewals),
• dark UX practices to influence customer behavior in unethical ways,
• failure to replace or fix a faulty product within the warranty period,
• unilaterally modifying a contract to the detriment of the customer,
• failure to clearly communicate the changes affecting the contract,
• omission of important details related to a product / service,
• data collection, processing and sharing without consent,
• unlawful withholding and use of the customer’s money,
• vendor lock-in, artificial obstacles to change provider,
• creating an artificial sense of urgency / scarcity,
• service not meeting promises and expectations,
• failed deliveries, outages, service disruptions,
• overcharging accidentally or intentionally,
• hidden fees and extra costs appearing,
• difficult to cancel subscriptions,
• abusing the customer’s trust,
• running misleading ads,
• etc.

Some potential problems related to the (in)activities of the support team contributing to the secondary sufferings experienced by customers:

• discrepancies between expectations related to what the support team expects from the customer and how they behave e.g. nonsensical deadlines set for the customer to provide something vs. long periods of inactivity and unresponsiveness from the support team,
• superficial and meaningless politeness without actual care (no real attempt at solving or mitigating the problem),
• creating unnecessary roadblocks during the process hoping that the customer will just abandon the case,
• not respecting the potential long-term value of the relationship with the customer,
• repeated violations of the norms governing human behavior,
• inconsistent, confusing, self-contradicting communication,
• very difficult to reach or nearly unreachable support,
• inability to take responsibility for a failure,
• delaying the progress of a support case,
• inability to understand the problem,
• not respecting the customer’s time,
• boilerplate, scripted responses,
• failure to keep promises,
• lack of empathy,
• shifting blame,
• etc.

While the situation seems troubling, there is a great deal of uncertainty regarding the extent and scope of such doubly wrong and objectionable practices. From time to time a major issue surfaces and gets widely broadcasted through the media, but everyday experiences shared informally by a variety of people suggest that the problems are highly prevalent and may represent default experiences with “support teams”. If such experiences are widespread and accepted by people without much objection, they become normalized business practices. Such normalization of the abnormal and the immoral, are not only unbeneficial for the customers, but downright detrimental. Meanwhile, the organisations acting without self-restraint, direclty profit from collecting some extra money unfairly while pursuing their only objective: generating value.

It should be noted that not all negative experiences with an organisation or a support team are symptoms of a fundamental flaw in their designs or their principles. The world, and the systems are highly complex and often unpredictable, therefore unintentional, benign human errors, system errors, omissions, etc. may also result in SupportNightmares. Since such problems are easy to fix, the way such unintentional errors and troubles are handled reveals their true nature: if they get solved without major external pressures and within a reasonable time, they were truly mistakes and errors; however if they remain unsolved, they can be safely regarded as non-benign or intentional actions.

🧟 Why contribute to the SupportNightmares collection?

There are several considerations / hypotheses motivating the development of the SupportNightmares collection which are relevant for the Call for Contributions as well:

• We are not living in a perfect world, thus certain things could be improved.
• One specific problem with the world, that would definitely benefit from improvement, is how organisations may mistreat not just the entities that get tangentially involved (often against their will) in their activities, but also their customers.
• The reason that any organization exists is predicated on their ability to serve some human needs, whereas the existence of humans is not predicated on any organization’s ability to serve any of their needs.
• Organizations may exist and continue to exist as long as customers (humans and other organisations who are essentially just another groups of people) are willing to enter into transactions with the organisation: customers are willing to pay for the “stuff” created or provided by the organisation.
• Organisations, especially those acting as monopolies, are not really good at regulating themselves in many aspects that people value highly.
• Even governments and regulatory bodies may lack the power or willingness to regulate organisations and limit their undesirable behavior.
• The way an organisation treats the ones in need (i.e. paying / loyal customers in need of help with a problem) is very telling about the organisation’s true priories and valuations.
• If organisations act in objectionable ways, people need to exercise their freedom of choice and their other rights to correct objectionable activities.
• Individuals are powerless against behemoth organisations, but groups of individuals are powerful and able to balance the power imbalances when such imbalances are abused by an organisation.
• Data on negative experiences with support teams (i.e. SupportNightmares) are scarce, scattered, disorganized and hidden at organisations which makes it difficult to assess the gravity (i.e. global costs) of the problems for society at large.
• Nevertheless anecdotal evidences, daily experiences, news reports suggest that the problems may be highly prevalent on a global scale.
• If negative experiences are under-reported, our shared reality lacks important pieces of information to establish facts and truth.
• A key contributor to the lack of data and the resulting apathy (lack of visible corrective actions) may be due to a carefully calculated strategy on the organisations’ part which exposes people to unfairness just below a certain threshold, so that the costs of any corrective action outweigh the potential gains from the action, thus leaving most of the unpleasant experiences hidden and swept under the carpet.
• Data sharing, openness and a higher level of transparency may help with having a better overview of the impact of the problems.
• Transparency, facts and clear evidences are necessary for accountability and for corrective actions.
• Collective corrective attempts are more effective to facilitate desirable changes than the attempts of scattered, disconnected individuals.
• Writing about unpleasant or traumatic experiences is beneficial in itself for processing the events, and it may help people develop solutions and move on.
• Sharing experiences with others exposed to similar experiences is a powerful source of social support when official support teams fail miserably.

🧛 How to contribute to the SupportNightmares collection?

The SupportNightmares collection is a publicly accessible repository currently hosted on GitHub. It aims to facilitate information sharing built around cases with a wide scope: unpleasant / objectionable / unfair / illegal organisational practices when help is requested through the support teams operated by an organization. The goal of facilitating information sharing is to:

• build a better understanding of the scale of the problem,
• identify common patterns across cases and organizations,
• identify the types of situations that have a high probability of turning into real SupportNightmares,
• develop strategies to mitigate the detrimental effects of SupportNightmares at the level of individuals and society,
• motivate collective and corrective actions when objectionable practices become overwhelming,
• help people exposed to such experiences overcome the secondary problems (e.g. unfairness, negligence from the “support” teams) through writing and sharing the experiences in a dedicated environment.

Therefore, the SupportNightmares collection is open for anyone to contribute with their experiences. It is best to fully document the progress of a support request case and share all the important pieces of evidence in the SupportNightmares collection to make it easy for everyone to understand what went wrong and how the process got derailed. The collection aims to collect experiences from the widest possible groups of people and about the widest possible negative experiences related to support teams and the organisations operating the teams. In short the scope of the collection is wide and expandable.

Guidelines for contributions

There are a few guidelines that provide useful information on how to prepare and share contributions using the template documents and the repository’s folder structure which starts from the most general Entities category and goes through several levels like Sub-units, Isssues reaching the concrete Case where the main case file and the supporting documents need to be placed.

The structure of the folders and the templates may evolve as more experience is gained about the pros and cons of the current structure.

Currently there are two ways to submit contributions after compiling the supporting documents, main case file and the optional analysis file according to the guidelines:

• Option 1: using GitHub’s pull request functionality signals the intention to contribute with a case. When the contributor’s local copy of the main case file and all the supporting documents is added to the SupportNightmares public repository’s folder structure, everything included in the package becomes immediately accessible to anyone.
• Option 2: contributions are also possible without a GitHub account by sending the main case file and the supporting documents (or their links) in a mail clearly marking the topic (e.g. SupportNightmares - case XXX) in the subject line. This method requires providing access to the files that are ready for sharing publicly.

In order to make the materials available to a wider audience, and to make them easier to read and share, the cases added to the SupportNightmares collection may be turned into blog posts. It is relatively easy to turn the case materials into reader-friendly blog posts when the naming system, the template documents and the folder hierarchy follows the provided guidelines.

When submitting a contribution please indicate whether the materials related to the case can be processed further to turn them into a blog post. Optional: It is especially great if the shared materials contain the customized YYMMDD_NameOfContributor_XXX_1_analysis.md file that already contains an analysis written as a blog post ready for immediate sharing with the public.

Example of a contribution

Check out this post about a legitimate but failed refund process to get an idea of what a (typical?) case that turns out to be a SupportNightmare looks like. The post also provides an example about the level of details, the types of information and the structure of the main case file that are desirable for a contribution. Presenting the supporting documents in a structured way allows anyone to get an accurate and sufficiently detailed overview about the issues at hand and about the dynamics of the case. The post uses the YYMMDD_NameOfContributor_XXX_1_analysis.md analysis file to provide an in-depth dissection of the interactions with the support team separately from the main case file.

Contribute with your experiences to the SupportNightmares collection on GitHub!