Rules-based account prioritization or predictive scoring? What decides it

This is a question about the shape of your signal, not your analytical maturity. A rule produced $2.8M of cross-sell in year one at one client. In three of the four engagements where we did ship a model, the thing that moved the result was the pipeline, the instrumentation or the motion attached to the score.

Two ways to tell a seller which account to call. A list built from rules you can write down, or a score from a model trained on history.

The decision is usually framed as a maturity question, which is why it is usually answered wrong. It is a question about the shape of your signal.

Which approach fits which signal

Which approach fits which signal

This is a question about the shape of your signal, not about analytical maturity. Most estates should run rules first and add a model where the rules cannot reach.

A rule produced $2.8M of cross-sell in year one at an industrial distributor: flag contracts 90 days before expiry, escalate to a manager if the rep has not followed up within 30 days. No model involved.

Source: Thinklytics case library, published approaches and outcomes per engagement.

A rule fits when the signal is a known event with a deadline. A renewal date. A contract tier. A usage reading above a plan limit. A service call on equipment past a certain age. These are events, they are already in a table somewhere, and what is missing is a threshold and an alert.

A model fits when the signal is a pattern across many weak features that no single rule captures. Usage trend plus support volume plus payment behaviour plus seat changes, where none of those on its own means anything and the combination does.

The practical differences follow from that.

A rule reaches an action in weeks, because a rule is a query and an alert. A model needs labelled history, a stable pipeline, a holdout set and a monitored precision figure, and in our experience the pipeline rather than the model is the schedule risk.

A rule is completely explainable: the reason is the rule, and a rep can see why the account surfaced. A score needs reason codes designed in from the start, because a number with no explanation competes against a seller's own account knowledge and loses.

And they fail differently. A rule fails by being gamed, or by having a threshold nobody tuned. A model fails by having its precision collapse in production on the top band the team actually works, which is the failure mode documented in lead scoring and churn prediction.

What a rule produced

An industrial distributor had 180 field reps working from printed account summaries updated once a month, with renewal reminders arriving from the back office 45 days after contracts had already expired. The company put the missed cross-sell at $2M to $4M a year.

The work was a mobile app giving reps customer equipment details, service records, contract status and cross-sell opportunities, plus an automated rule: flag contracts 90 days before expiry, escalate to a manager if the rep has not followed up within 30 days.

Twelve weeks. Renewal lag from 45 days to 6. Quarterly renewals from 128 to 160. $2.8M of additional cross-sell revenue in year one. See the field analytics engagement.

Nothing in that is a model. It is a date, a threshold, an escalation and a phone. Worth sitting with before approving a scoring project, because the rule version was cheaper and shipped sooner.

What the model added, where we used one

What the model actually added, where one was used

Four engagements that shipped a model. The pattern is that the production work, not the model, was the constraint in three of them.

In three of the four, the model existed or was simple, and the thing that produced the outcome was the pipeline, the instrumentation or the motion attached to the score. Model accuracy was never the binding constraint.

Source: Thinklytics case library, published approaches and outcomes per engagement.

Four engagements in our case library shipped a model. The pattern across them is consistent and it is not flattering to the model.

An analytics vendor's churn model tested at 78 of every 100 correct and never went live. The pipeline broke several times a week because CRM and product usage data kept changing format, and without reliable data the customer success team could not see which accounts were at risk. The work that produced the outcome was rebuilding the pipeline to detect and repair schema changes, then validating on a three-month holdout, which lifted accuracy to 84, then running daily scoring with Slack alerts to named customer success managers. Live in week 10, $2.6M of at-risk ARR flagged in three months, 340 accounts retained.

A B2B SaaS company's expansion model is the case where the model was the point, and even there the prerequisite dominated. There was no usage signal at all before the engagement, so the work was instrumenting 140 user actions, building feature adoption scorecards, and only then a product-qualified lead model. It flagged 84 accounts ready to expand, worth $1.8M in six months, and cut the churn prediction window from 60 days to 14.

A retail loyalty churn model scored the full member base and surfaced 94,000 at-risk members in the first run. What produced $3.1M was the win-back motion attached to the score, which recovered 68 of every 100 high-risk members.

A wealth management risk profiling model across 42 advisors' books surfaced $14.2M of rebalancing opportunities. What made it work was putting it inside the review workflow advisors already ran, taking portfolio review from three hours to 22 minutes.

So in three of four, the model was either simple or already existed, and the result came from the pipeline, the instrumentation or the motion. Model accuracy was not the binding constraint in any of them. That is four engagements rather than a study, and the selection is ours, so treat it as a prior rather than a proof. It is a prior worth holding when a proposal leads with model quality.

Thresholds, gaming and reason codes

Three practical things that decide whether either approach survives contact with a sales team.

The threshold is a business decision. For a rule it trades volume against relevance. For a model it trades missed opportunities against wasted calls. Either way the owner is you, not the tool's default, and it needs tuning after the first month on real action-rate data.

Write rules on events the seller does not control. If a rule rewards logging an activity, activities get logged. A contract date, a usage threshold crossed inside the product, a service call logged by an engineer: those report on the world rather than on the CRM hygiene of the person being measured.

Design reason codes with the model, not after it. A seller with 40% of their week available for customer conversations, per Salesforce's State of Sales survey of 4,050 sales professionals across 22 countries conducted August to September 2025, will not spend it reverse-engineering a number.

The order of work

The order that gets an action in the first month

Each step produces something a seller can act on, which is what keeps the programme funded long enough to reach the model.

• List the expansion events you can already name
• Write one rule per event, with a threshold
• Alert a named owner in the tool they already use
• Measure the action rate, not the score
• Add a model only where the rules found nothing

Step four is the one skipped most often. If nobody acts on the rule output, a model will not fix that, and you will have spent a quarter proving it.

Source: Thinklytics engagement pattern across the account growth and churn prediction engagements in the case library.

Five steps, and the fourth is the one that gets skipped.

List the expansion events you can already name. Write one rule per event, with a threshold. Alert a named owner inside the tool they already have open. Measure the action rate rather than the score. Then add a model only where the rules found nothing.

Measuring the action rate before funding a model is the whole discipline here. If nobody works the rule output, that is an ownership or a delivery problem, and a model inherits it along with a larger invoice. The follow-through evidence is uncomfortable on exactly this point and it is in lead scoring: why scores do not move revenue.

What we would do first

Take your renewal book for the next two quarters and build the rule by hand, in a spreadsheet, for one segment. Contracts expiring in 90 days, sorted by value, with an owner against each.

Send it to the owners. Then, three weeks later, count how many were worked.

That number is the single most informative thing you can learn before spending anything. A high action rate means the constraint was the signal and you should invest in signal. A low one means the constraint is ownership or workflow, and a model would have been the wrong purchase.

How to scope the pilot once you know which it is sits in how to scope an account-growth analytics pilot, and the account growth pilot success criteria are the measures we agree with clients before a pilot starts.

Delivery sits in pipeline and revenue analytics for the account view and the rules, forecasting and optimisation where a model is warranted, analytics and BI for the delivery surface, and sales and CRM AI automation where the alert has to land inside the seller's existing tooling. The full set of work in this area sits under we react instead of predicting.

Frequently asked questions

Should we use rules or a predictive model to prioritise accounts?

It depends on the shape of the signal, not on analytical maturity. If the signal is a known event with a deadline, such as a renewal date, a contract tier or usage above a plan limit, a rule is faster, explainable to the seller, and frequently produces more revenue because it ships in weeks. If the signal is a pattern across many weak features that no single rule captures, a model is the only way to find it. Most estates should run rules first and add a model where the rules found nothing.

What did a rule actually produce?

At an industrial distributor with 180 field reps, a rule flagged service contracts 90 days before expiry and escalated to a manager if the rep had not followed up within 30 days, delivered through a mobile app carrying equipment details, service records and contract status. Renewal lag fell from 45 days to 6, quarterly renewals rose from 128 to 160, and cross-sell revenue rose $2.8M in the first year. No model was involved.

When is a model the right answer?

When the thing you want to predict has no clean trigger event, so the signal is a combination of many weak features: usage trend plus support volume plus payment behaviour plus seat changes. A B2B SaaS company instrumented 140 product events and built a product-qualified lead model over them, flagging 84 accounts ready to expand and producing $1.8M in six months. No rule was going to find that pattern, because the pattern was the point.

Why do predictive scoring projects fail?

Rarely because the model is weak. In our own work the constraint was the production path three times out of four. An analytics vendor had a churn model at 78 of every 100 correct that never shipped, because the pipeline broke several times a week on CRM and product schema changes. Separately, the documented failure mode worth knowing is precision collapsing in production on the top band the team actually works, which is covered in our piece on lead scoring and churn prediction.

What should we measure, the score or the action?

The action rate, first and above everything. The share of flagged accounts a named owner actually worked, within a stated number of days. A perfect score nobody acts on returns zero, and no amount of additional model quality changes that. Measure the action rate on the rules output before funding a model, because if nobody works the rule output, the model will inherit the same problem with a larger invoice.

How explainable does a score have to be?

Explainable enough that a rep can see why the account surfaced, or it gets ignored. This is the quiet advantage of rules: the reason is the rule. For a model, plan the reason codes as part of the build rather than as a later enhancement, because a score with no reason competes for a seller's attention against their own account knowledge and loses.

Can a rule be gamed?

Yes, and that is its main failure mode alongside an untuned threshold. If a rule rewards logging an activity, activities get logged. Write rules on events the seller does not control, such as a contract date, a usage threshold crossed in the product, or a service call logged by an engineer. Then the rule reports on the world rather than on the CRM hygiene of the person being measured.

What is the right order of work?

List the expansion events you can already name. Write one rule per event with a threshold. Alert a named owner inside the tool they already use. Measure the action rate rather than the score. Then add a model only where the rules found nothing. Step four is the one most often skipped, and skipping it is how a team spends a quarter proving that the output nobody was working was accurate.

The work behind this

Six engagements in the case library carry lead scoring and churn prediction, and four of them shipped a model into production with a measured result. The highest-returning account growth engagement in the library used no model at all.

Lead scoring and churn prediction, 6 engagements.