Ask a salesperson what they think of their company's lead score and the answer is usually a shrug. The number appears in the CRM. Sometimes it is high for a lead that is obviously useless. Sometimes it is low for a lead the salesperson knows is ready. Nobody can say why, so the experienced sellers ignore it and the new ones follow it, which is the worst combination.
The problem is rarely the maths. It is that the score cannot explain itself. CloudNala's view is that a lead score is a decision rule, and a decision rule that affects who gets called must be readable by the people it affects. Every score should show the reasons behind it, the threshold it is compared with should be written down, and the whole thing should be checked against what actually happened, every month. A score that cannot pass those three tests should not be routing leads.
CloudNala has made the same argument about scores in software delivery: release readiness scores need an explanation. A number that hides its reasoning moves the decision to whoever built the formula, and nobody can challenge it.
Lowveld Ledger is fictional, and its systems and figures are illustrative. Lowveld Ledger, the Mbombela accounting and payroll software company in this series, now has trusted lifecycle data (Part 3) and four signals proven against its own outcomes (Part 4). Its old score, inherited from a marketing automation template, gave points for every email open and every page view.
Why the old score failed
The template score had been switched on years earlier. It added five points for an email open, ten for a webinar registration, three for each page view, and fifteen for filling in the contact form. Anyone above 50 became an MQL.
It failed in predictable ways. A student who read twenty blog posts for an assignment became an MQL. So did a competitor's marketer who attended every webinar. A 40-person manufacturing company that had run a test payroll in its trial and visited the pricing page twice scored 38, because the template had no way to see product data and no way to know that company size mattered.
The SDRs learnt to ignore it. That was the rational response, and it meant the routing rules built on it were routing noise.
A transparent points model
The GTM engineer rebuilt the score from the proven signals in Part 4 and the written target profile from Part 3. It has two halves, each worth up to 50 points.
Fit, up to 50. Company size (up to 20 points, most for 20 to 80 employees), payroll need (up to 15, based on monthly payroll and employee count), and current tool (up to 15, most for companies still on spreadsheets or desktop software).
Engagement and timing, up to 50. Product use (up to 25, most for a test payroll run during the trial), pricing, demo or webinar interest (up to 15, for repeat pricing visits within a week, a demo request, or two or more people from the account attending a webinar), and a timing signal (up to 10, for example an employer reconciliation period or a newly advertised payroll role).
Webinar attendance counts only at account level, when two or more people from the same account attend, because Part 4 showed that one attendee alone predicted almost nothing. Email opens were removed entirely.
A score of 60 or more makes the lead an MQL and routes it to an SDR. Below 60, the account stays in nurture and is re-scored daily as new signals arrive.
The split matters. A high fit score with no engagement says "good company, wrong moment", which suggests a nurture play. A high engagement score with poor fit says "interested, but probably not a customer who will stay", which suggests a lighter-touch response. Showing both halves lets a seller see which situation they are in.
Every score shows its top three reasons
The most important change was not the points. It was what the seller sees.
Next to every score in the CRM, Lowveld Ledger shows the three reasons that contributed most, in plain language:
- FIT: 20 to 80 employees
- INTENT: viewed pricing twice in 7 days
- PRODUCT: test payroll run on trial day 10
Reason codes do three things. They let a seller decide quickly how to open the conversation. They let a seller disagree with a specific reason ("this company has 25 employees, but they outsource payroll to their accountant") instead of dismissing the whole number. And they make disagreements useful, because a seller who rejects an MQL now picks a coded rejection reason that can be compared with the score's reasons at the monthly review.
Points model or machine-learning model?
Once a company has enough outcome data, someone will propose replacing the points model with a machine-learning model. That can be the right decision. It should be made on evidence, not on novelty.
A points model is easy to read, easy to change and easy to explain. It encodes judgement directly, which is a strength when you have limited data and a weakness when the judgement is wrong. Its errors are visible.
A machine-learning model can find combinations of signals a person would not think of, and it can weigh many signals at once. It needs a reasonable volume of past outcomes to learn from, it can learn the biases in that history, and its reasoning is harder to show. If you use one, the reason-code requirement does not go away. The model must still show the factors that contributed most to each score, and the team must still be able to see why a particular lead was ranked high.
For a company of Lowveld Ledger's size, with around 1,100 new leads a month and a few dozen new customers, the points model was the right starting point. The decision rule was written down: revisit the choice when there are at least two years of clean outcome data, and only adopt a model that beats the points model on a held-out period while still explaining itself.
Calibrate against outcomes every month
A score that is never compared with what happened next is an opinion with decimals. Lowveld Ledger reviews its score once a month, using the lifecycle data from Part 3.
The review asks three questions.
Do higher score bands convert more? The leads are grouped into bands (for example 60 to 69, 70 to 79, 80 and above) and each band's rate of moving to SAL, opportunity and customer is compared. If the bands do not separate, the score is not doing its job, whatever its formula says.
Which reason codes predict wins? If one reason appears often in won deals and rarely in lost ones, its weight may be too low. If a reason appears equally in both, it may not belong.
Why did sellers reject MQLs? The coded rejection reasons show where the score and the sellers disagree. A cluster of "outsources payroll to accountant" rejections, for example, suggests a missing fit question at sign-up rather than a scoring error.
Changes are made only when the outcome data supports them, are recorded with a date and a reason, and are tested for at least a month before the next change. A score that changes every week cannot be calibrated, because nobody knows which version produced which outcome.
Guardrails on the score
Three rules keep the score honest.
The score routes; it does not decide. A seller can always accept a low-scoring lead with a reason, or reject a high-scoring one with a reason. Both are logged and reviewed.
The threshold is written down and owned. The head of sales owns the MQL threshold because it determines the SDRs' workload. The GTM engineer can propose a change; the head of sales approves it.
No signal enters the score until it is proven. This is the Part 4 rule applied to scoring. It protects the score from every new data feed and every new idea.
What changed at Lowveld Ledger
In the first months after the change, the monthly MQL count fell sharply, because the students, competitors and email-open machines stopped qualifying. The share of MQLs accepted by sales rose, and the rejection reasons became specific enough to act on. Marketing no longer reports a large MQL number. It reports the number sales accepted, because that is the number both teams now trust.
These are illustrative changes in a fictional company, not a benchmark. The point is that the conversation changed from "the score is wrong" to "this reason is over-weighted", which is a conversation you can resolve.
Start this week
- Open five recent MQLs and ask a seller why each one scored what it did. If nobody can answer, your score cannot explain itself.
- Add the top three reasons to every score where sellers can see them, even if you change nothing else yet.
- Run one calibration: group last quarter's leads into score bands and compare how each band converted.
Next: Part 6, Build GTM plays like small products. All parts are on the series page.
How CloudNala can help
CloudNala helps commercial teams replace opaque lead scores with explainable ones. We rebuild the score from your proven signals and written target profile, add reason codes your sellers can read and challenge, set up the monthly calibration against outcomes, and advise on when, and whether, a machine-learning model is worth the extra complexity.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Go-to-Market Systems Review or write to us at consult@cloudnala.co.za