What 48 Client Calls Say About Where Revenue Systems Fail

I went back through 48 client calls from this year and counted what companies were actually calling about. The sample covered legal services, marine contracting, medical device, staffing, and professional services. The companies reported between two and twenty million in revenue. Their records lived in Salesforce, HubSpot, and, in two cases, no shared platform at all.

Different industries and different software produced a concentrated set of failures. Six areas accounted for nearly every call.

What companies called about

System architecture appeared in 42% of the calls. Questions about access and who could change what appeared in 33%. Data integrity appeared in 29%, while disputes over whether reported numbers meant what their labels claimed appeared in 27%. Software spend with no named owner appeared in 25%. Email deliverability appeared in 12%.

The last figure now governs how I open an engagement because deliverability appeared least often and caused the most damage per occurrence. Companies didn't book a call about SPF records. They booked because outbound had stopped producing and the writing seemed stale. The work then found three sending domains with authentication completed on one, bounce data collected without review, and roughly half the outbound landing in spam for much of a year.

That gap between the reported problem and the condition inside the company appeared across every area. Buyers described the symptoms accurately. The failing area was usually one they had no language for because the areas they could name were already being monitored.

The presenting problem can't set the scope

A company that calls about pipeline reporting may have a reporting problem. It may also have unreliable data expressing itself through reporting. Accepting the first description as the brief would leave the underlying condition in place, so the review has to score all six areas independently before the work is defined.

The same rule applied to access problems. A delayed project looked like a slow vendor until the record showed nine days spent waiting for credentials. Software waste looked like an expensive tool until an inventory showed that the person accountable for the subscription had left eleven months earlier. The visible symptom described the cost while the ownership record explained why it continued.

The lowest dimension governs the result

I score the operation at its lowest dimension because that is where it can produce a confident answer from weak inputs. An average spreads the failure across stronger areas and makes the overall condition look ordinary. Reporting can be carefully configured and still state something false when the records beneath it are unreliable.

One company scored 13 out of 24 across the six dimensions. The average was 2.2, which gave no useful instruction. One dimension scored a 1, and that dimension accounted for every conclusion the company had drawn about its outbound performance. Three sending domains were active. One had complete authentication. Bounce data existed and nobody reviewed it. Every conclusion about response quality began with the untested assumption that the messages had arrived.

The average would have buried the only finding worth acting on. The lowest score established the first repair and the sequence for everything that followed.

What the count changes

The 48 calls changed the opening question. I no longer ask a company to choose the area that needs work and build the engagement around that answer. I record the presenting problem, then test architecture, access, data integrity, reporting, software ownership, and deliverability as separate conditions.

This does not make the presenting problem irrelevant. It places the symptom beside the dependencies that can produce it. A reporting complaint can then be traced to a field definition. An outbound complaint can be tested against delivery before the copy is rewritten. A software-cost complaint can be resolved through ownership before another procurement decision is made.

The count also changes what deserves urgency. Frequency alone is a poor guide. Deliverability appeared in six of the 48 calls and carried consequences that had already accumulated for months. Architecture appeared in twenty calls and often sat beneath several later complaints. The order of work has to reflect consequence and dependency alongside prevalence.

A score should produce an order of work

A useful score gives the company a starting point. It shows which part of the operation can invalidate decisions made elsewhere and names the evidence needed to test it. A blended grade may be comfortable to read, though it cannot set that order when one weak dimension governs the reliability of the rest.

The six areas recur because they depend on each other. Access determines whether work can proceed. Data integrity determines what reports can state. Ownership determines whether software remains governed after the buyer leaves. Deliverability determines whether outbound performance can be judged from replies. Architecture establishes where each responsibility sits.

The Revenue System Score records those conditions separately and leads with the lowest result. The purpose is a sequence grounded in the part of the business most capable of making the rest of the numbers unreliable.