§9.1

From Business Rules to Algorithms

Part IV — predicting who or what will do what next.

A manager already classifies, scores, and ranks dozens of times a day. Which leads should sales call first? Which customers look like they are about to leave? Which transactions deserve a second look? These decisions get made — quickly, often well, often inconsistently — by combining experience with rough rules of thumb. An algorithm does not replace that judgment. It writes the rule down, applies it to every case at once, and remembers what it did.

Part IV is about that translation. Across the next four chapters we walk from a business question to a model that can score new units the firm has never seen before — and back to a manager who has to decide whether the score is worth acting on. This first article sets up the basic move: from informal rule, to data-driven rule, to a decision that monitors itself.

The Executive Question

What pattern in our history is reliable enough to act on automatically, and where does a manager still need to be in the loop?

Two changes happen when a rule becomes algorithmic. First, the rule is no longer carried in one head; it can be applied consistently to every customer, claim, or click in the firm. Second, the rule becomes auditable — its inputs, its breakpoints, and its mistakes can be inspected. That second change is what makes the move from rules to algorithms a managerial topic, not a technical one.

Rules, Scores, and Decisions

Every algorithmic decision sits somewhere on a short ladder:

Table 1. The same business question, viewed at four levels of formalization. As the rule moves down the ladder, consistency improves and the auditing surface grows, but interpretability and the manager's local knowledge can erode.

Level	Churn example	Lead-scoring example	What it gains
Manager intuition	"This customer feels at risk."	"That account looks promising."	Local context, cheap to start.
Hand-coded rule	If no purchase in 60 days AND >2 tickets, flag.	If pricing page visited AND company >500, hot lead.	Explicit and reviewable.
Statistical score	Logistic regression on RFM features.	Logistic score on firmographic + behavior.	Ranks the whole book, not just edge cases.
Machine-learned model	Gradient boosting over 30 features.	Ensemble + interaction features.	Captures non-linear patterns and interactions.

The right level depends on the decision frequency and the cost of a single mistake. A pricing committee that meets monthly will tolerate — and may want — manager intuition layered on a coarse rule. A retention engine that has to act on every weekly active customer cannot scale without a score.

What an Algorithm Actually Is

Strip away the implementation, and an algorithm in this book is just three things:

A dataset of past cases, each with features and (usually) a known outcome.
A fitting procedure that finds a function mapping features to outcome.
A deployment loop that applies the function to new cases and feeds the results back.

The loop is the part most managerial conversations skip and most production failures hide in.

The predictive-modeling lifecycle

Figure 1. The predictive-modeling lifecycle. Preparation and modeling are where most teaching time gets spent; evaluation and operations are where most business value is lost.

Three observations about the lifecycle that managers should hold onto:

The first stage and the last stage are the same conversation. Monitoring failures almost always trace back to a fuzzy problem statement. Whom are we scoring, for what action, on what horizon? If those answers drift, the model drifts whether the data shifts or not.
The dashed feedback arrow is not optional. A churn model that gets retention offers also changes who churns next quarter. The model's outputs reshape the data its successor will see.
The boxes are not equally hard. With AutoML and modern tooling, model training and selection are increasingly cheap. Defining the target, engineering features, and interpreting evaluations are where managerial work concentrates.

When To Algorithmize, and When Not To

Not every decision wants to be an algorithm. A useful test is to ask three questions in sequence:

Is the decision repeated often enough that consistency pays? A one-time policy choice will not benefit from a model; a weekly retention decision applied to a million customers will.
Is there enough labelled history to learn the pattern? "Enough" is fuzzy, but if no past case looks anything like the case you are scoring, the model is extrapolating, not predicting.
Can the firm act on the output? A model that predicts customers will churn is useless if no team owns retention offers. The decision-readiness of the action matters as much as the accuracy of the score.

If the answer to any of these is no, do not start with a model. Start by writing the rule down and watching what it does for a month.