SCMP: The Screaming Customer Management Protocol

In 2002, I was working on an enterprise systems-management team. We were doing a great deal with SNMP: the Simple Network Management Protocol.

Technology has a long tradition of calling things “simple” when simplicity is more of a historical aspiration than an operational guarantee. SNMP was no exception.

At some point, our team leader introduced me to another management protocol: SCMP, the Screaming Customer Management Protocol.

I do not remember the exact conversation. It was twenty-four years ago. But I remember the term because, once you hear it, you begin recognizing implementations everywhere.

SCMP remains one of the industry’s most widely deployed monitoring systems. It requires no installation, produces extremely high-volume alerts, and automatically assigns priority based on the customer’s influence.

It was a joke about reactive support. It was also an uncomfortably accurate description of how many systems were—and still are—managed.

How SCMP Works

SCMP is an event-driven monitoring and escalation protocol used to detect failures that have not been identified, understood, or prioritized through conventional operational processes. Unlike SNMP, it does not require an agent on the affected system. Instead, it uses a customer located downstream of the failure.

It is also a two-for-one protocol. Every alert identifies both the problem the customer is experiencing and the organization’s failure to detect that condition independently.

The protocol begins when a customer encounters a problem. Before transmitting an alert, they may retry the operation, refresh the page, restart the application, consult a coworker, search the documentation, invent a workaround, or spend time assuming they are the one doing something wrong. None of these actions necessarily generates an alert. An SCMP transmission occurs only when the customer’s accumulated frustration exceeds their willingness to tolerate the problem quietly.

Once triggered, the alert may travel through a support ticket, email, telephone call, account manager, salesperson, social media post, or direct contact with an executive. SCMP is highly adaptable and works with mainframes, cloud platforms, SaaS products, internal systems, spreadsheets, manual processes, and nearly anything else capable of disappointing someone.

The receiving organization may have an official incident-management process, but SCMP can bypass it. A low-priority support ticket may become a critical incident within minutes when forwarded to the right person. This gives SCMP a responsiveness not always found in more formally designed systems.

Automatic Severity Assignment

One of SCMP’s most advanced features is dynamic prioritization. Traditional monitoring systems may assign severity according to availability, error rate, latency, resource consumption, or the number of users affected. SCMP uses a richer model based on how loudly and how often the customer complains, how much they pay, how close they are to renewal, how many executives have been copied, whether the complaint is public, and whether the customer has the CEO’s phone number.

Repeated transmissions increase priority, although they do not necessarily increase diagnostic accuracy. A customer reporting that “the entire system is down” may be describing a single failed transaction. They may also be accurately reporting that the entire system is down. SCMP is designed to generate urgency rather than diagnosis.

A simplified severity calculation might be expressed as:

SCMP severity = complaint volume × customer influence × executive proximity

Actual business impact may also be considered, although implementations vary.

This model can produce curious results. A large or well-connected customer may receive immediate attention for a problem affecting one workflow, while hundreds of smaller customers quietly experience a more damaging failure. The customer who knows whom to contact may receive a faster response than the customer who follows the official support process.

The loudest alert is not always the most important one. It is simply the hardest one to ignore.

Why SCMP Remains Popular

SCMP requires no installation because customers are already deployed in the production environment. There is no agent to configure, no collector to maintain, and no additional licensing cost. Organizations may begin receiving alerts immediately after launch.

It is also technology-independent. SCMP works equally well with modern distributed systems and twenty-year-old applications nobody understands well enough to replace. It remains compatible through platform migrations, architectural rewrites, vendor acquisitions, and organizational restructures. As long as a customer can experience disappointment and communicate it to someone, the protocol remains operational.

Its most important advantage is outcome-sensitive detection. Infrastructure monitoring tends to report what systems are doing. Customers report what systems are doing to them.

A server may be available. A process may be running. CPU utilization may be normal. Every dashboard may be green. Payroll may still not have run, orders may not be going through, reports may contain the wrong numbers, or users may be unable to complete the one task the system exists to support.

SCMP detects these conditions because it observes the system at the point where technical behavior becomes human consequence.

Known Limitations

SCMP is usually a late-stage detection protocol. Before raising an alert, the customer may spend considerable time determining whether the problem is theirs, attempting workarounds, searching documentation, or repeating the failed operation. By the time the organization hears about it, the failure may have existed for hours, days, or longer.

The resulting alert is often high in consequence but low in diagnostic precision. Customers are frequently excellent at explaining what a failure is doing to them, but they are not necessarily positioned to identify its technical cause. This is not a failure on the customer’s part. It is unreasonable to expect someone using a service to understand the architecture behind it.

“The report is wrong” is not a root-cause analysis, but it is still important evidence. Organizations sometimes treat a lack of technical detail as a reason to discount the complaint rather than as a reminder that diagnosing the system is their responsibility.

SCMP also has a substantial false-negative problem: it cannot detect customers who do not scream. Some tolerate the failure. Some invent workarounds. Some assume the product is simply difficult to use. Others reduce their usage, decide not to renew, or leave without ever opening a ticket.

From the organization’s perspective, these customers produce no alert at all. The absence of screaming does not prove the absence of pain.

Frequent SCMP events can also produce alert fatigue. Teams learn which customers always escalate. Support staff develop scripts. Engineers wait for the complaint to reach a particular level before acting. The organization can become highly efficient at processing customer frustration without becoming any better at preventing it.

This can create the appearance of operational competence. Incidents are handled, calls are scheduled, status updates are sent, and executives are briefed. Yet the organization remains dependent on customers to discover failures on its behalf.

Recovery is similarly ambiguous. An SCMP alert often clears when the customer stops screaming. This may mean the problem was fixed. It may also mean the customer accepted a workaround, gave up, became exhausted, or decided to leave.

In SCMP, silence is frequently interpreted as recovery. This interpretation is not guaranteed by the protocol.

What SCMP Detects

It would be easy to treat SCMP as nothing more than a joke about inadequate monitoring. That would miss the more important point: SCMP sometimes detects something technical monitoring does not.

SNMP can tell us whether an interface is down, whether a device is reachable, or whether a threshold has been crossed. Modern observability systems can collect metrics, logs, traces, events, profiles, and dependency information. All of that data can be accurate while the organization still fails to understand whether the system is delivering value.

A technically healthy system can produce an unusable customer experience. A request can complete successfully while returning the wrong result. A process can remain available while taking too long to support the business it serves. A service can meet its internal targets while forcing customers to compensate for its failures manually.

This is where SCMP becomes valuable evidence. The customer is not merely reporting that a component failed. The customer is reporting that the system’s behavior has become consequential.

The problem is not that organizations listen to customers. They should. The problem is that many organizations cannot connect technical conditions to customer outcomes until someone screams.

A Better Monitoring Architecture

The answer is not to eliminate customer feedback. Customers encounter conditions we did not predict, use systems in ways we did not anticipate, and notice failures dashboards cannot see. Their reports will always be an important source of operational knowledge.

But customer complaints should supplement awareness, not substitute for it.

A healthier monitoring architecture connects infrastructure and application telemetry with end-to-end transaction checks, service-level indicators tied to real outcomes, support trends, business-process failures, and the consequences customers experience when the system misbehaves.

The difficult part is not collecting more data. Most organizations already have more data than they can interpret. The difficult part is connecting system behavior to delivered value.

Can users complete the task? Are the results correct? Is the service fast enough for the business process it supports? Are customers inventing workarounds? Are support contacts increasing before dashboards show a failure? Are customers quietly reducing their usage?

These questions require more than monitoring components. They require understanding the system as a service experienced by people.

SCMP Is Not Going Away

No monitoring system will detect everything. No dashboard will fully represent every customer’s experience. There will always be surprising failures, unexpected interactions, and complaints that reveal something the organization did not know.

SCMP will remain part of the operational environment. The goal is not to disable it. It is to stop depending on it.

Customer complaints are valuable evidence. They are simply a terrible primary monitoring architecture.

A customer should be one of the ways you learn that something is wrong—not the component your monitoring system was missing.