Machine Learning for Complete Beginners: Simple Work Predictors

Section 1.1: What a “predictor” is and why it matters at work

A predictor is anything that takes what you know now and produces a best-guess about what will happen next. In everyday work, you already rely on predictors—even if nobody calls them “machine learning.” For example: “This ticket will probably take two days,” “This customer is likely to churn,” or “This shipment may arrive late.” These are predictions, and they drive decisions: staffing, prioritization, inventory, outreach, budgeting, and timelines.

Predictions show up most often when there’s uncertainty and limited time. You cannot wait to see the future, but you still need to choose an action today. A predictor helps you reduce uncertainty just enough to make a better choice than guessing. Notice the standard here: you’re not aiming for perfection; you’re aiming for better decisions.

• Sales: Estimate next week’s pipeline, or whether a lead will convert.
• Operations: Predict delays, defects, or workload volume.
• Support: Predict which tickets will breach SLA, or which need escalation.
• HR: Predict hiring time, or training completion risk.

A key beginner habit is to ask: “What decision will this prediction change?” If nobody will act differently, the model won’t matter. If a simple spreadsheet rule already solves it reliably, ML may be unnecessary. The sweet spot for ML is when the decision is real, the signal is subtle, and examples exist in your historical data.

Section 1.2: Inputs, output, and examples (the core idea)

Machine learning, in one sentence: ML learns patterns from examples to make predictions on new cases. Each example has inputs (what you know at prediction time) and an output (what actually happened). If you can create a table where each row is one past case, you are already most of the way to an ML project.

Think of a spreadsheet where each row is a completed work item (a ticket, an order, a delivery, a sales opportunity). Columns are details you knew early (team, priority, product, customer segment, day of week) plus the outcome you care about (resolution time, late/not late, revenue). ML tries to connect the inputs to the output by finding a pattern that generalizes beyond the rows it has seen.

• Output (target): the thing you want to predict (e.g., “hours to resolve”).
• Inputs (features): the clues you use (e.g., priority, channel, component).
• Examples (rows): past cases where both inputs and outcome are known.

Turning a work question into a clear prediction target is a skill. “Will we hit our SLA?” becomes “Predict breach_sla (yes/no) for each ticket at creation time.” “How long will this take?” becomes “Predict resolution_hours using fields known at intake.” Be strict about timing: only use inputs you would truly have before the outcome occurs. A common mistake is accidentally including information from the future (like “date closed” when predicting “time to close”). That makes the model look great in testing but fail in real use.

Section 1.3: Training vs. using a model (practice vs. performance)

There are two phases in any ML workflow: training and using the model. Training is practice: you show the algorithm historical examples and let it learn a pattern. Using is performance: you feed in a new case and get a prediction.

This sounds simple, but many beginner errors come from mixing the two phases. If you train and evaluate on the same data, the model can “memorize” and appear impressive, even if it won’t work on new cases. Good evaluation means simulating the real situation: predicting outcomes for cases the model has not seen.

• Training set: examples used to learn patterns.
• Test set (or validation): examples held back to measure real-world performance.
• Deployment / use: predictions on new rows that arrive tomorrow.

Another practical point: data preparation is part of training. Your model learns from whatever you feed it, including mistakes. If your spreadsheet has inconsistent categories (“High”, “high”, “HIGH”), missing values, or duplicate rows, those issues become part of what the model “learns.” You don’t need perfect data, but you do need usable data: consistent columns, clear units, and a target that makes sense.

Set expectations early. As a beginner, you can build models that are safe and useful when the stakes are moderate and the output supports human decisions. You are not trying to automate high-risk judgments (like hiring decisions) from day one. Instead, aim for a decision aid: a ranked list, a risk flag, or a rough estimate that saves time and focuses attention.

Section 1.4: Two main job types: predicting numbers vs. categories

Beginner ML projects usually fall into two job types, which determines what model you build and how you measure success.

1) Predicting a number (regression): The output is numeric, like “days to deliver,” “monthly spend,” or “number of calls next week.” A good beginner approach is a simple number predictor that learns how inputs shift the expected value. You’ll later evaluate it with intuitive metrics like average error (how far off you are, on average) and compare it to a baseline such as “always predict the historical average.”

2) Predicting a category (classification): The output is a label like yes/no or one of several buckets (e.g., “late vs. on-time,” “high risk vs. low risk”). A yes/no predictor is often the most useful at work because it can drive quick actions: escalate, inspect, follow up, or prioritize. You’ll later evaluate it with metrics that match the decision, such as accuracy and (when classes are imbalanced) precision/recall-style thinking.

• Regression example: Predict resolution_hours from priority, component, customer tier.
• Classification example: Predict breach_sla (yes/no) from the same inputs.

Choosing the right job type is an engineering judgment. If the team only needs to know “which items are at risk,” a yes/no model may be better than a precise time estimate. If planning requires a numeric forecast, regression is the right fit. Don’t force a problem into the wrong shape; match the output to the decision that will be made.

Section 1.5: Common myths and misunderstandings (plain-language fixes)

ML gets confusing when it’s mixed up with other tools. Clearing this up now will save you time and prevent unrealistic expectations.

• Myth: “ML is just automation.” Fix: Automation executes steps; ML predicts outcomes. You might automate a workflow using an ML prediction, but they are different.
• Myth: “ML is the same as rules.” Fix: Rules are hand-written logic (“if priority=high then escalate”). ML learns patterns from examples, which can capture combinations you didn’t think to encode.
• Myth: “ML is just reporting.” Fix: Reports summarize what happened; ML estimates what will happen next. A dashboard can be a great input to ML, but it does not replace prediction.
• Myth: “More data always wins.” Fix: Cleaner, more relevant data often beats lots of messy data. A small, well-defined dataset can outperform a huge but inconsistent one.
• Myth: “If accuracy is high, the model is good.” Fix: If 95% of tickets never breach SLA, a model that always predicts “no breach” gets 95% accuracy and is useless. You must compare against a sensible baseline and pick metrics that match the decision.

One more misunderstanding: ML does not remove uncertainty; it manages it. A prediction is not a guarantee. Your goal is to make predictions that are reliable enough to improve a process. That’s why baseline thinking matters: start with a simple reference (average, majority class, last week’s value), then check whether ML improves it fairly on held-out data.

Finally, be cautious about sensitive topics and fairness. Even “simple work predictors” can cause harm if used to judge people rather than processes. As a beginner, aim for problems where the prediction supports operational improvements (routing, capacity planning, prioritization), and keep a human in the loop.

Section 1.6: Your first mini-project idea (choose a work-friendly problem)

Your first mini-project should be small, practical, and easy to evaluate. The best choice is a question you already ask informally, where you have historical examples in a spreadsheet. The workflow is straightforward: define the question, translate it into a target and inputs, assemble a dataset, build a baseline, train a simple model, and compare results.

Pick one of these work-friendly patterns:

• “Will this be late?” Target: late (yes/no). Inputs: promised date lead time, vendor, shipping method, weekday, destination region.
• “How long will it take?” Target: days_to_close. Inputs: priority, category, assigned team, intake channel, requester type.
• “How many will we get?” Target: next_week_volume. Inputs: week number, seasonality clues, campaign flag, holiday indicator.

To create a small usable dataset, export a spreadsheet where each row is one completed case. Include: (1) an ID, (2) the input columns known at the time you would predict, and (3) the outcome column you want to predict. Then do a quick “data reality check”: remove duplicates, standardize categories, confirm units (hours vs. days), and ensure missing values are handled consistently. If a column is filled only after completion, treat it as off-limits for prediction.

Set safe beginner expectations: your first model might only be “a bit better than baseline,” and that’s still progress. If your baseline is “always predict average resolution time,” even a modest improvement can help staffing or prioritization. The practical outcome you want is a model you can explain, test honestly, and use as decision support—not a black box that looks impressive but fails in the real workflow.

In the next chapters, you’ll build two models (a number predictor and a yes/no predictor) and learn simple, fair ways to check quality so you can tell the difference between real improvement and accidental self-deception.

Section 2.1: What counts as data for machine learning

For machine learning, “data” is not just numbers in a database. Data is any consistent record of past situations paired with what happened next. In a workplace setting, that often means spreadsheets, ticket systems, time trackers, CRM exports, form submissions, or simple logs you already have. If you can describe a repeated process (requests arrive, work gets done, outcomes occur), you probably have data.

The key requirement is repeatability. A machine learning model learns patterns that generalize across many similar cases. So one-off stories (“that one project last year”) don’t help much unless you can turn them into many comparable rows. This is why a dataset plan matters: you decide what each row represents (a ticket, an order, a task, a customer, a day) and what fields are recorded the same way each time.

Start with a concrete work question and translate it into “examples.” For instance: “Can we predict if an invoice will be paid late?” Each invoice becomes one row. The outcome (late or not) is recorded after the fact, but the inputs should be information you knew at the time you would have made the prediction (invoice amount, customer segment, payment terms, month sent).

A good dataset plan answers three practical questions:

• What is one row? Choose a unit that makes sense for the prediction moment (one ticket at creation time, not the whole customer lifetime).
• What fields do we collect? Include what is plausibly useful and available before the outcome occurs.
• Where does the outcome come from? Define how you will label each row (paid late: yes/no; resolution time: number of hours).

In other words, data for machine learning is “historical examples in a consistent table form.” If your spreadsheet has many tabs, merged cells, summary rows, and notes, it may still contain data—but it likely needs reshaping into a clean training table first.

Section 2.2: Features (inputs) and target (the thing you predict)

Every beginner-friendly model you’ll build in this course can be described with two parts: features (inputs) and a target (the output you want to predict). The target is a single column: the number or yes/no label you want the model to learn. Features are the other columns you provide to help it make that prediction.

To turn a work question into a dataset plan, force yourself to write the prediction like this: “Predict target using features at the time of decision.” Examples:

• Yes/No predictor: Predict “resolved within 24 hours” using “ticket priority, product area, day of week opened, requester type.”
• Number predictor: Predict “days to complete” using “task type, estimated size, assignee workload, dependencies count.”

Now apply a simple rule: your features must be available before the target happens. If you include “actual resolution time” as an input while predicting “resolved within 24 hours,” you have cheated. This mistake is common because spreadsheets often include fields filled in later (closed date, final status, final cost). Using them creates a model that looks accurate in testing but fails in the real world.

Also pay attention to what each row and column means. A healthy training table looks like this:

• Rows: one example each (one ticket, one invoice, one task).
• Columns: stable fields (priority is always one of a known set; created date is always a date; amount is always a number).

If a column mixes meanings (sometimes “N/A,” sometimes “unknown,” sometimes blank; or sometimes “priority” contains free-form notes), the model will treat those as separate patterns. Your job is to decide whether to standardize, remove, or split that field so its meaning stays consistent.

Section 2.3: Clean vs. messy data: examples you can recognize

A “clean” dataset is not perfect; it is consistent enough that a model can learn real patterns instead of spreadsheet artifacts. Messy data is normal—especially when the spreadsheet was created for humans, not for training models. The trick is learning to recognize the messes that matter.

Common messy patterns you can spot quickly:

• Missing values: blank cells, “—”, “N/A”, or “unknown” used inconsistently.
• Duplicates: the same ticket exported twice, the same customer repeated with tiny spelling differences, or multiple rows per item when you expected one.
• Messy categories: “High”, “high”, “HIGH”, “H”, “urgent” all meaning the same thing.
• Mixed types: numbers stored as text (“1,200” with commas), dates stored as text (“03/04/25” ambiguous), or a column that sometimes contains a number and sometimes a note.
• Hidden structure: merged cells, subtotal rows, or headers repeated every 50 lines in an exported report.

To create a clean “training table” from a raw spreadsheet, aim for a simple rule: one row per example, one column per field, one cell per value. Remove report formatting and summaries. If your sheet has totals and section headers, those belong in a separate report—not in the training data.

Duplicates deserve special care because they can trick you into thinking the model is better than it is. If the same example appears in both training and testing (more on splitting later), the model may simply “remember” it. When you deduplicate, use an identifier if you have one (ticket ID, invoice number). If you don’t, combine multiple columns to form a “likely unique key” (customer + date + amount), then inspect collisions manually.

The practical outcome of this section: you should be able to look at a spreadsheet export and identify which parts are data (rows of examples) and which parts are presentation (headers, totals, notes). Machine learning needs the data part.

Section 2.4: Handling missing values and strange entries (simple options)

Missing values are not just an inconvenience; they change what patterns a model can learn. Beginners often “just delete the rows with blanks” and accidentally throw away half the dataset or bias it toward the easiest cases. Instead, choose a simple, explicit strategy per column based on why the value is missing and how important the column is.

Here are beginner-friendly options that work well in practice:

• Drop the column if it is missing in most rows or clearly unreliable. A mostly-empty “notes” field might be better ignored early on.
• Drop the rows only when the dataset is large enough and the missingness is rare and random (for example, 1–2% of rows missing a non-critical field).
• Fill numeric blanks with a simple value such as the median (often safer than the mean) or 0 when 0 is a meaningful “none” (for example, “number of attachments”).
• Fill categorical blanks with an explicit label like “Unknown” so the model can learn whether missingness itself matters.

“Strange entries” are the cousins of missing values: values that are technically present but don’t match expectations. Examples include negative durations, impossible dates, or “priority” containing a full sentence. Treat these as data quality issues to triage, not as quirks to ignore.

A simple workflow for strange entries:

• Define allowed ranges and sets. Resolution hours should be >= 0; priority should be one of a short list.
• Count violations. If there are only a few, fix them manually or remove those rows. If there are many, your extraction process may be wrong.
• Decide on a rule. For example, clamp negative durations to missing and then impute, or exclude rows created by obvious system bugs.

Engineering judgment matters here. The goal is not to “make the spreadsheet pretty.” The goal is to create a training table where values mean what they claim to mean. If you hide problems by silently filling everything with 0, you can create a model that looks stable but predicts badly because the inputs no longer reflect reality.

Section 2.5: Turning text into usable categories (basic encoding ideas)

Most workplace datasets contain important text fields: priority, department, product area, region, request type. Models can’t use raw words the way humans do unless you convert them into a consistent set of categories. For this course, you’ll focus on structured text fields (short labels), not long free-form paragraphs.

Step one is standardization. Before any “encoding,” make sure “High” and “high” are the same category. Trim extra spaces. Decide whether “Urgent” should map to “High” or remain separate. This is where messy categories become model-breaking: if one concept appears as five spellings, the model sees five different signals.

After standardization, you need a basic way to turn categories into numbers. Two simple ideas cover many beginner problems:

• One-hot encoding: create a yes/no column for each category (Priority_High, Priority_Medium, Priority_Low). This prevents the model from assuming “Medium” is mathematically halfway between “Low” and “High” unless you want that.
• Ordinal encoding (use carefully): map ordered categories to numbers (Low=1, Medium=2, High=3) only when the order is real and consistent.

Watch out for high-cardinality categories: columns with too many unique values (customer name, ticket title, exact address). One-hot encoding thousands of unique values often creates a sparse, fragile dataset. For beginners, common solutions are to:

• Group rare values into “Other.”
• Use a higher-level category (customer segment instead of customer name).
• Drop the column if it’s mostly identifiers rather than useful predictors.

The practical outcome: you end up with a tidy training table where every feature column is numeric or a small controlled category that can be encoded reliably. This makes later modeling steps straightforward instead of a fight with inconsistent text.

Section 2.6: Splitting data into train and test (why it’s necessary)

Once your training table is clean, you need one more discipline before modeling: keep some data aside to check whether your model actually generalizes. This is called splitting into train and test sets. The training set is what the model learns from. The test set is what you use to evaluate it on “new” examples it did not see during learning.

Without a test set, it’s easy to fool yourself. A model can appear to perform well because it memorizes quirks in the data, repeats duplicates, or indirectly uses leaked information. The test set is a reality check.

Simple, practical rules for splitting:

• Split before heavy tweaking. Decide the test set once, early. If you repeatedly tune decisions by looking at test performance, your test set stops being a fair check.
• Avoid leakage across the split. If multiple rows belong to the same underlying entity (multiple tickets for one incident; multiple lines for one order), keep them together. Otherwise, the model can “recognize” the entity in test.
• Consider time. For forecasting-like problems, a time-based split is often best: train on earlier months, test on later months. This matches how the model will be used.
• Start simple with proportions. A common beginner split is 80% train, 20% test, assuming you have enough rows.

Train/test splitting connects back to earlier data cleaning steps. Duplicates are dangerous because they can land in both sets and inflate results. Messy categories can appear only in the test set, causing failures if you didn’t plan for “Unknown/Other.” Missing values can be distributed differently over time, which is exactly why a test set matters.

The practical outcome: when you build your first number predictor and yes/no predictor in later chapters, you’ll be able to compare them fairly against a baseline, using test performance that reflects real-world use—not spreadsheet luck.

Section 3.1: What regression means in plain terms

Regression is a type of prediction where the output is a number on a scale. If your target is “hours to complete a ticket,” “delivery days,” “monthly spend,” or “units sold,” you’re doing regression. The model looks at inputs (also called features) and returns a numeric guess. It does not “understand” your business; it finds patterns in past examples that connect inputs to the target.

In plain terms, regression answers: “Given what I know now, what number should I expect?” The input might be a small set of columns from a spreadsheet: request type, team, complexity score, number of items, customer tier, or region. The output is one column you want to predict: time, cost, demand, or some measurable outcome.

Regression is not the same as writing a formula. A formula usually encodes rules you believe are true (for example, cost = rate × hours). A regression model learns relationships from data, including interactions you didn’t think to write down. However, a regression model is also not magic: if your inputs don’t contain information that affects the outcome, the model cannot invent it.

A common beginner mistake is choosing a target that is not stable or not measurable. “Effort” is often ambiguous; “hours logged” is measurable. “Urgency” might be subjective; “days until due date” is measurable. Regression works best when your target is a number recorded consistently the same way.

Section 3.2: A tiny example: predicting time, cost, or demand

Let’s use a tiny work-flavored example: predicting the number of days to complete a request. Imagine a spreadsheet where each row is a completed request. You have columns like:

• Request_Type (Bug, Report, Access, Feature)
• Team (Ops, Data, App)
• Complexity (1–5, estimated at intake)
• Items_Count (how many accounts/files/items involved)
• Days_To_Complete (the number you want to predict)

Your goal is to predict Days_To_Complete for a new request at intake time. Notice the practical framing: you can only use inputs you actually know at prediction time. If “days to complete” depends on a later field like “hours logged after completion,” that column is unusable as an input because it would leak the answer. This is called data leakage and it can make a model look perfect in testing while failing in real life.

Start small on purpose. You do not need 50 columns to learn. A beginner-friendly dataset might have 50–500 rows and 3–8 inputs. The point is to build a workflow you can trust. If the tiny version works, you can expand later.

Also decide what the prediction is used for. If the result drives staffing or customer promises, you may need conservative predictions or “ranges.” If it only helps prioritize work internally, a rough estimate might still be valuable.

Section 3.3: Baselines: average and simple rules (why they matter)

Before training any model, build a baseline guess. A baseline is the simplest reasonable prediction method you could use without machine learning. It sets a fair starting point. If your model can’t beat it, the model is not helping—no matter how impressive the code looks.

Two baselines are especially useful for regression:

• Overall average: predict the mean (average) of Days_To_Complete for every new request. This is the “do nothing” baseline.
• Simple rule baseline: predict an average per group, such as average days by Request_Type, or average days by Complexity. This mimics how people often estimate: “bugs take ~3 days, reports take ~7.”

Why baselines matter: they protect you from fooling yourself. If the overall average yields an average error of 2.5 days, and your model yields 2.4 days, you have not created meaningful value (even if the model is technically “better”). On the other hand, if a rule-based baseline already performs well, that can be a win: you may not need ML at all. Machine learning is not the goal; better decisions are.

Common baseline mistakes include calculating the baseline using the entire dataset (including what should be “future” data), or updating the baseline with information that would not be available at prediction time. For a fair comparison, compute baselines on training data and evaluate them on held-out data the same way you evaluate your model.

Section 3.4: Training a simple regression model (conceptual steps)

You can train many kinds of regression models, but the workflow is similar. Conceptually, you will:

• Split your data into training and test sets. Train on one portion; evaluate on the other. This is how you simulate predicting on new work.
• Prepare inputs: handle missing values, make sure numbers are numeric, and convert categories (like Request_Type) into something the model can use. Many beginner tools do this via “one-hot encoding,” which creates a column per category.
• Choose a simple model: start with linear regression or a small decision tree. These are interpretable enough to learn from and often strong baselines themselves.
• Fit the model: the model adjusts its internal parameters to reduce error on the training set.
• Predict on the test set: generate predictions for rows the model did not see during training.

Engineering judgment matters in small details. If your dataset is time-ordered (requests over months), consider a time-based split: train on earlier months and test on later months. This avoids a subtle problem where the model “learns the future” because patterns drift over time (new process, new team, new tooling).

Another common mistake is overfitting: using a model that is too flexible for a small dataset. A deep tree can memorize training examples and still fail on new ones. For beginners, a simple model that generalizes is better than a complex model that wins only on paper.

Finally, keep the target definition stable. If your organization changed how completion time is recorded, mix-and-match data can confuse the model. In that case, either standardize the definition or restrict to a consistent time period.

Section 3.5: Measuring error: MAE and RMSE without math pain

After you have predictions, you need a clear way to measure how wrong they are. For regression, two beginner-friendly metrics are MAE and RMSE. You don’t need to love the formulas to use them well; you just need to know what they mean.

• MAE (Mean Absolute Error): on average, how many units off are you? If MAE = 2.0 days, your predictions miss by about 2 days on average. MAE is easy to explain to stakeholders and maps directly to the business unit.
• RMSE (Root Mean Squared Error): similar to MAE, but it punishes big misses more. If you occasionally predict 2 days but reality is 20, RMSE will jump more than MAE.

How to use them in practice: compute MAE and RMSE for your baseline and for your model on the same test set. If both metrics improve meaningfully, that’s a good sign. If MAE improves slightly but RMSE gets worse, your model may be making fewer small mistakes but more “disastrous” mistakes—important if you need reliability.

Two common evaluation mistakes: (1) measuring on training data instead of test data (this almost always looks better than reality), and (2) ignoring the distribution of errors. Always look at a handful of individual cases: the largest underestimates and overestimates. Metrics summarize, but examples teach you what’s going wrong.

If you have outliers (rare huge delays), MAE may reflect typical performance while RMSE highlights risk. Choose the metric that matches the cost of mistakes in your work setting.

Section 3.6: Reading results: when to trust, when to stop

Once you have baseline scores and model scores, the real skill is deciding what to do next. “Good enough” is not a universal number; it depends on the decision you’re supporting.

Start by lining up three views side by side: (1) a baseline prediction, (2) your model prediction, and (3) the actual outcome. For a few test rows, ask: is the model directionally right, and does it beat the baseline for the cases you care about? For example, if you only need to separate “fast” from “slow,” a model that reduces huge underestimates may be more valuable than one that improves average error slightly.

Trust increases when:

• The model clearly beats the baseline on the test set by a margin that matters (for example, MAE drops from 3.0 days to 2.0 days).
• The biggest errors have understandable causes (missing inputs, process exceptions) rather than random chaos.
• Performance is stable across key groups (teams, request types) instead of only working for one category.

Stop (or simplify) when:

• The model does not beat a simple rule baseline, or only improves by a trivial amount.
• The model relies on leaky fields (anything that is only known after the work is done).
• Your data quality is too inconsistent: shifting definitions, many missing values, or targets that are not recorded reliably.

If you’re close but not there, the next best move is often not a fancier algorithm—it’s better inputs. Add a field you can collect at intake (a consistent complexity score, customer tier, or “requires approval: yes/no”). Small, reliable signals often beat complex modeling.

The practical outcome of this chapter is a repeatable habit: baseline first, model second, compare fairly, measure with MAE/RMSE, then decide. This is how you build predictors you can defend in a work setting.

Classification is predicting a category. In this chapter we focus on the simplest case: two categories (binary classification), often written as Yes/No, True/False, or 1/0. Where a number predictor estimates “how much,” a classifier estimates “which bucket.”

Common workplace classification questions include:

• Will this lead convert this week? (Yes/No)
• Is this support ticket urgent? (Urgent/Not urgent)
• Will this shipment arrive late? (Late/On time)
• Is this expense likely out-of-policy? (Flag/Don’t flag)

Classification fits best when the decision is discrete. For example, you may only have capacity to call 50 customers per day. A churn classifier can rank customers by risk so the team contacts the top 50. Even if the model is imperfect, it can still create value by prioritizing attention.

Two practical cautions matter early. First, classification problems often have imbalanced outcomes: maybe only 5% of invoices are late, or only 2% of tickets are truly urgent. Second, the “correct” decision depends on the cost of mistakes. Marking an invoice as late-risk when it would have paid on time is annoying but often cheap; missing a truly late invoice might be expensive. Those two facts will shape how you evaluate the model later in the chapter.

A classifier learns from labeled examples: past cases where the outcome is known. The outcome column is the target (also called the label). Before modeling, make the yes/no target unambiguous by writing a one-sentence definition you could hand to a coworker.

Example target definition for late payment:

• Target: Paid_Late (1/0)
• Meaning: 1 if the invoice is paid more than 7 calendar days after the due date; otherwise 0.

This definition forces clarity on details that commonly break beginner datasets: partial payments, adjusted due dates, voided invoices, and invoices not paid yet. Decide what to do with “unknown” outcomes. If an invoice is still open, it may be impossible to label it honestly today. In many work settings, the safest approach is to exclude unlabeled rows from training rather than guessing.

Next decide what “positive” means. In binary classification, one class is treated as the positive class (often encoded as 1). Pick the class that represents the event you care about detecting. In the example, “Paid late” is the positive class because it triggers action (extra reminders, adjusted credit terms, earlier outreach).

Common mistakes to avoid:

• Moving targets: changing the definition mid-project (“late” used to mean 7 days, now 3) without updating labels.
• Label leakage: including an input that directly reveals the outcome (e.g., “days past due” measured after the due date when you want to predict earlier).
• Messy labels: mixing blanks, “Y/N,” “Yes/No,” and “1/0” in the same column. Standardize to a single scheme.

Once the label is clear, your spreadsheet becomes a simple training table: one row per invoice, a set of input columns (features), and one target column (Paid_Late).

The workflow to train a classifier mirrors your first model: prepare data, split into training/testing, train, then evaluate. The difference is what the model outputs and how you interpret it.

A beginner-friendly classifier to imagine is logistic regression. Despite the name, it’s used for classification. Conceptually, it learns a weighted combination of inputs to produce a score between 0 and 1—often treated as the probability of the positive class.

Practical training steps:

• Clean inputs: fix missing values, consistent categories, and obvious data errors (negative invoice amounts, impossible dates).
• Split data: keep a test set that the model never sees during training. This is how you estimate real-world performance.
• Train on labeled examples: the algorithm adjusts weights to separate positives from negatives.
• Generate scores: for each row, the model outputs a score like 0.12 or 0.83.
• Convert scores to Yes/No: choose a threshold (often 0.50 by default) to produce predicted labels.

The “engineering judgment” is mostly in the data choices. For example, if you want to predict late payment at invoice creation time, only use inputs known at that moment: customer history, contract terms, account age—not “number of reminders sent,” because reminders are sent after risk is already suspected.

Also, create a simple baseline before celebrating. A baseline classifier might predict “not late” for every invoice. If only 5% are late, that baseline is 95% accurate but useless for catching late payments. Your model must be compared against a baseline using the right metrics, not just accuracy.

After training, you need to see what the model gets wrong. A confusion matrix is the most direct tool. It compares predicted labels to actual labels and counts four outcomes:

• True Positive (TP): predicted late, actually late.
• False Positive (FP): predicted late, actually on time.
• True Negative (TN): predicted on time, actually on time.
• False Negative (FN): predicted on time, actually late.

Put those counts into a 2×2 table. Even without formulas, the table tells a story. If FN is large, the model is missing the very cases you want to catch. If FP is large, the model creates too many unnecessary interventions (calls, emails, reviews).

In work settings, the confusion matrix is also a communication tool. Stakeholders may not care about model details, but they understand outcomes. You can translate the matrix into operational terms:

• TP = invoices you correctly prioritize for early outreach
• FP = customers you annoyed with unnecessary reminders
• FN = late invoices you failed to prevent
• TN = normal invoices you left alone

Common confusion-matrix mistake: swapping the positive class. If you accidentally treat “on time” as positive, your “true positives” become the opposite of what you intend. Always label the matrix with the meaning of 1 and 0, not just the numbers.

Finally, don’t inspect the confusion matrix only on the training data. A perfect-looking matrix on training rows may simply mean the model memorized quirks of your past data. Always compute it on the held-out test set to estimate how it behaves on new cases.

Accuracy is the share of correct predictions: (TP + TN) / total. It’s easy to understand and sometimes useful—but it can be misleading with imbalanced classes. If late payments are rare, a model can be “accurate” by mostly predicting “on time.”

Precision answers: “When the model says ‘late,’ how often is it correct?” Precision = TP / (TP + FP). Precision matters when false alarms are costly. Example: a compliance team can only investigate a small number of cases, and each investigation is expensive. High precision means your flagged list is mostly worthwhile.

Recall answers: “Of all truly late invoices, how many did the model catch?” Recall = TP / (TP + FN). Recall matters when misses are costly. Example: a fraud team would rather review more transactions than miss true fraud. In late payment prevention, recall matters if missing a late invoice creates significant cash-flow risk.

Precision and recall usually trade off. If you flag only the highest-risk invoices, precision rises (fewer false alarms) but recall falls (you miss more late invoices). If you flag aggressively, recall rises but precision falls.

Practical guidance for beginners:

• If your action is cheap (an automated reminder email), favor higher recall.
• If your action is scarce/expensive (manual review, customer escalation), favor higher precision.
• Always report the baseline performance (e.g., “predict on time for all”) to keep metrics honest.

Another common evaluation mistake is “metric shopping”: choosing whichever metric looks best after the fact. Decide up front what failure hurts more—false positives or false negatives—then choose metrics that reflect that pain.

Most classifiers output a score (often interpreted as probability of “Yes”). Turning that score into an action requires a threshold. The default threshold is often 0.50, but 0.50 is not “neutral” in business terms—it’s just a convention.

Choosing a threshold is really choosing your mix of false positives and false negatives. Lowering the threshold (e.g., from 0.50 to 0.30) makes the model predict “late” more often: recall tends to increase, precision tends to decrease. Raising it does the opposite.

Make this decision using costs and capacity. A simple approach:

• Estimate the cost of a false negative (missed late invoice): extra days of cash outstanding, collections effort, risk of default.
• Estimate the cost of a false positive (unnecessary outreach): staff time, customer annoyance, reputational risk.
• Consider capacity: how many cases can your team realistically act on per day or week?

Then choose a threshold that fits the workflow. For example, if your team can call 30 customers per day, pick the threshold that flags roughly 30 per day on recent data. This turns the model into a prioritization engine instead of a theoretical score generator.

Two practical mistakes to avoid:

• Freezing the threshold forever: if the business changes (seasonality, new pricing, new customer mix), the score distribution can shift. Re-check the confusion matrix periodically.
• Optimizing for the test set: repeatedly tweaking the threshold to look best on your test data can create overly optimistic results. Treat threshold choice as part of deployment policy and validate on fresh data when possible.

By the end of this chapter, you should be able to look at a confusion matrix, compute precision and recall, and select a threshold that matches a real business goal. That is the core skill of practical classification: not just building a model, but turning its scores into sensible, accountable decisions.

Overfitting happens when your model memorizes the training data instead of learning a pattern that generalizes. In work terms, it’s like a teammate who “studied the answers” to last month’s tickets and now claims they can predict any ticket, but only because they remember the exact examples.

The simplest detection method is a train-vs-test check. You train your model on one portion of your data (train) and evaluate on held-out data (test). If the model performs much better on train than test, that gap is a warning sign. For a number predictor, you might see very low error on train but much higher MAE on test. For a yes/no predictor, you might see near-perfect accuracy on train but only average accuracy on test.

Common beginner mistake: tuning your spreadsheet or code until the test score improves, then reporting that score. If you keep “peeking” and changing things based on the test set, the test set stops being a test. Treat the test set like a final exam you only take occasionally.

• Practical habit: record both train and test metrics every time you change the model or features.
• Rule of thumb: a small gap is normal; a large gap signals overfitting or leakage.
• Quick fix options: simplify the model, remove suspicious features, reduce feature count, or collect more varied examples.

More data often helps overfitting because it gives the model more chances to see the real pattern and fewer opportunities to memorize quirks. But if your data is duplicated, mislabeled, or not representative of the future (for example, only “easy weeks” of work), more of it may not help at all.

Leakage is different from overfitting. Overfitting is “learning too much detail.” Leakage is “using information you would not have at prediction time.” Leakage creates models that look amazing in evaluation and then collapse in real use because they were allowed to cheat.

Workplace leakage examples are common:

• Predicting “will the task be late?” while including a feature like “actual completion date” or “final status.”
• Predicting ticket duration while including “time spent (final)” or “number of reassignments,” which you only know after the work happens.
• Creating a feature like “average time-to-complete by project” computed using the full dataset, including future tickets. That lets the model indirectly see the future.

A practical way to spot leakage is to ask: “When I’m making the prediction in the real workflow, do I truly know this value?” If the answer is “not yet” or “only after,” remove or rebuild that feature.

Another habit: if a single feature makes accuracy jump dramatically, get suspicious. Great improvements can happen—but huge leaps often mean leakage. Check also for IDs that encode outcomes (like ticket numbers that increase over time) when the outcome distribution changes over time.

Finally, be careful with time. If you predict future work, prefer a time-based split (older data for training, newer for testing) rather than random splitting. Random splitting can accidentally place “future-like” information into training via correlated records, inflating your test score.

Feature selection sounds advanced, but for beginner models it’s mostly disciplined cleaning and simplification. Features can help, do nothing, or harm you. Harmful features often add noise, encourage memorization, or encode leakage.

Start with basic feature fixes that improve data quality:

• Fix missing values: blank cells should be handled consistently. For numbers, decide on a safe fill (like 0 or median) and add a “was_missing” flag if missingness is meaningful. For categories, use “Unknown.”
• Normalize messy categories: “HR”, “Human Resources”, and “H.R.” should become one value. Otherwise, your model treats them as different.
• Reduce high-cardinality text: free-form “notes” fields often create overfitting if used directly. If you must use them, extract simple signals (length, presence of key words) rather than raw text.
• Remove identifiers: ticket ID, requester email, or random codes often let the model memorize rather than learn.

Keep features that are stable and available early: team, request type, estimated complexity, priority, day of week, backlog size at intake. These reflect real drivers you can know at prediction time.

A practical workflow is to start with a small, sensible set of inputs, build a baseline model, then add one feature group at a time (for example: “intake info,” then “team info,” then “calendar info”). If test performance improves without widening the train-test gap, you likely added signal rather than noise.

Reliable evaluation is mostly about repeatability. If your results change every time you rerun a notebook or reshuffle rows, you can’t tell whether your changes helped. The first habit is to use the same split for comparisons: keep one fixed train/test split (or fixed random seed) while you iterate.

Second, always compare against a baseline. For a number predictor, a baseline might be “predict the mean duration” or “predict the median duration.” For a yes/no predictor, a baseline might be “always predict the most common class.” If your model barely beats baseline, it may not be useful, even if the metric looks decent.

Third, use metrics that match the business question. Accuracy can mislead when one class dominates (for example, if 90% of tasks are on time, 90% accuracy is trivial). In that case, track precision/recall for the “late” class, or track balanced accuracy. For number prediction, MAE is often easier to explain than RMSE: “We’re off by ~1.2 days on average.”

Fourth, repeat checks in a lightweight way. If you can afford it, rerun evaluation with a couple of different splits (or do simple cross-validation) to ensure the result is not a lucky split. If performance swings wildly, you need more data, better features, or a clearer target definition.

More data helps when it adds coverage: more teams, more request types, more seasonal variation, more edge cases. It doesn’t help much when you’re just adding near-duplicates of the same situation or when the target is inconsistent (for example, “duration” measured differently by different teams).

When you have multiple models, compare them fairly: same target definition, same dataset version, same train/test split, and the same baseline. Otherwise, you’re not comparing models—you’re comparing different experiments.

A practical comparison approach for beginners is “one change at a time.” For example:

• Model A: baseline (mean/most-common)
• Model B: simple linear/logistic model with a small feature set
• Model C: slightly richer model (for example, a decision tree) with the same features

Prefer the simplest model that meets the goal. Simplicity is a feature in business settings: it’s easier to explain, easier to maintain, and less likely to break when work patterns change. If a complex model improves MAE from 1.3 days to 1.2 days but is hard to trust, the practical win may be small.

Also consider operational fit: if the model is only helpful when it is right for the risky cases, optimize for that. A late-risk classifier that catches most truly late tasks (high recall) may be better than one with slightly higher accuracy but misses the problematic ones.

Finally, watch for “evaluation overfitting.” If you try many variations and pick the best test score, you can accidentally select a model that just got lucky. Your experiment log (next section) is the antidote: it forces you to see how many shots you took and whether improvements are consistent.

Use this checklist whenever you want to make your predictor more reliable. It’s intentionally practical: you should be able to apply it to a spreadsheet-based dataset.

• Target clarity: Is the thing you predict defined the same way for every row? Are there hidden rule changes over time? Are there rows where the target is unknown or guessed?
• Prediction-time availability: For every feature, can you know it at the moment you would use the model? If not, remove it or rebuild it (no future info).
• Split discipline: Use the same train/test split while iterating. If this is time-related work, consider a time-based split.
• Train vs test gap: Track both. Large gaps suggest overfitting, leakage, or unstable patterns.
• Baseline first: Always compute baseline metrics. If you can’t beat baseline consistently, pause and improve data or target.
• Data quality fixes: normalize categories, handle missing values consistently, remove duplicates, and avoid IDs and free-form fields that cause memorization.
• Metrics match the goal: MAE for “how far off,” precision/recall for rare but important “yes” outcomes, and class balance checks for classifiers.

Keep a simple experiment log—just a table in your spreadsheet or notes doc. Each row is one run: date, dataset version, split method/seed, features used, model type, baseline metric, train metric, test metric, and a short note (“removed leakage: final status”; “merged categories”; “added backlog size”). This makes progress real, prevents you from repeating work, and helps you explain decisions to others.

By the end of this chapter, your models should feel less like magic and more like tools: you can show how they were tested, what they beat, where they fail, and what you changed to make them more trustworthy.

A prediction becomes useful only when it changes what someone does. Start by writing one sentence that connects model output to action: “If the predictor says X, we will do Y.” Avoid vague outcomes like “improve efficiency.” Instead, define the decision, the timing, and the owner.

Common patterns are:

• Decision thresholds: A yes/no model might flag invoices as “likely late.” You must choose a threshold (for probability or score) that triggers action. A beginner-friendly approach is to pick a threshold that matches capacity: “We can review 20 invoices/day, so set the threshold so ~20 are flagged.”
• Queues and prioritization: A number predictor might estimate “days until completion.” Rather than treating the exact number as truth, use it to sort work into a queue (most urgent first) or bucket items (“0–2 days,” “3–5,” “6+”). Buckets are easier to explain and often safer.
• Alerts: If a prediction indicates a rare, high-cost problem (e.g., “high risk of churn”), an alert might be appropriate—but only if the team can respond. Too many alerts create “alarm fatigue” and the model gets ignored.

Two practical mistakes to avoid: first, taking the raw model output literally (e.g., “the model says 4.2 days, so it must be 4.2”). Second, wiring predictions into an automated action with no backstop. For beginners, prefer “recommendations” over “automatic decisions,” especially when the cost of being wrong is high.

Finally, define your baseline behavior. What happens today without the model? Your deployment should make it possible to compare: “With the model, we reviewed 20 items/day and caught 8 true problems; without it, we caught 3.” This keeps improvements fair and prevents crediting the model for changes caused by other factors (like seasonality).

“Human-in-the-loop” means a person reviews the model’s suggestion before acting. This is not a sign of distrust; it is a safety feature and a learning mechanism. The trick is choosing where humans add the most value—without forcing them to re-do the model’s entire job.

Use human checks in these moments:

• High impact decisions: If a wrong prediction could harm a customer, violate policy, or cost significant money, require review. Example: a model recommending credit holds should never be fully automated in a beginner setup.
• Low confidence / edge cases: If your model provides probabilities, send “uncertain” cases to humans. If it doesn’t, create simple uncertainty rules: missing key inputs, out-of-range values, or unusual combinations that weren’t common in training data.
• Data quality failures: People should correct obviously wrong inputs (a date in the future, negative quantity, swapped columns). Bad input often causes more damage than imperfect modeling.

Design the workflow so the reviewer can answer two questions quickly: “Do I trust the inputs?” and “Does the recommendation make sense?” Provide a short checklist and a clear override option. Also record the override. Overrides are valuable feedback: if reviewers frequently override a particular scenario, you may have discovered a missing feature, a labeling issue, or a drift in the process.

A practical approach is a two-queue system: Queue A is “auto-approve” (low risk, high confidence), Queue B is “manual review.” For beginners, even if Queue A still gets spot-checked, the goal is to focus human attention where it matters most. This is how you use predictions safely while still saving time.

Stakeholders do not need a lecture on algorithms; they need a clear explanation of what the model is doing, why a particular prediction happened, and what the limits are. Explanations build trust and make errors easier to catch.

Use “simple reasons” that connect inputs to outputs. For a yes/no predictor, show the top few factors that tended to push predictions toward “yes” in your training data (e.g., “late deliveries were more common when the order was international and the lead time was under 5 days”). For a number predictor, show what typically increases or decreases the predicted value (e.g., “higher ticket volume increases resolution time”). If you’re using linear or tree-based beginner models, you can often provide these reasons directly from coefficients or feature importance. If you’re working in a spreadsheet, you can still describe the strongest patterns you observed.

Equally important: state the limits. A model is not a mind reader and cannot guess missing context. Write down what the model does not know (e.g., “This predictor does not include staffing levels” or “It assumes the same process as last quarter”). Also define where it should not be used: new product lines, new regions, unusual promotions, or cases with missing key inputs.

This section is where a one-page model card becomes practical. A good model card includes: the prediction target, intended users, data time range, key inputs, baseline comparison, simple metrics, known failure modes, and an escalation path (“If you see X, contact Y and pause use”). Keep it short enough to be read in five minutes. The goal is shared understanding, not legal paperwork.

You do not need to be a legal expert to practice “do no harm.” In a workplace predictor, fairness and privacy problems often come from small, preventable choices: using sensitive columns casually, storing predictions forever, or deploying a model that consistently performs worse for a subset of people.

Start with privacy: only use inputs you truly need to answer the work question. If a column feels personal (home address, personal email, medical notes), assume it requires extra justification and protection. Prefer aggregated or work-relevant alternatives (region instead of full address; account age instead of date of birth). Limit who can see raw data, and decide how long you will keep prediction logs. “Just in case” retention is a common mistake.

For fairness, beginners can apply a few simple checks:

• Group performance comparison: If you have a legitimate, approved grouping variable (e.g., region, product tier), compare error rates or accuracy across groups. Large gaps are a warning sign to investigate.
• Proxy variables: Even if you don’t include a sensitive attribute, other features can act as proxies (e.g., ZIP code). Be cautious about features that strongly correlate with protected characteristics.
• Outcome bias: Your labels may reflect past decisions, not objective truth. For example, if “approved” historically depended on a manager’s discretion, the model may learn that pattern and reinforce it.

Practical guardrails: do not use the model as the sole reason for denying opportunities; require review for impacted decisions; document sensitive features you excluded and why; and provide a way for users to report suspected harm. Fairness is not a one-time checkbox—monitoring (next section) is where you discover issues that only appear over time.

Once deployed, the world changes. Promotions launch, policies shift, suppliers change, and customers behave differently. Monitoring is how you notice change before the model becomes quietly wrong. For a beginner deployment, monitoring can be a monthly spreadsheet and a short meeting—as long as it is consistent and owned by someone.

Monitor three categories:

• Input drift: Are the inputs changing? Track simple summaries: missing-rate per column, average values, and category frequencies. Example: if “shipping method” suddenly has a new category, the model may not handle it well.
• Prediction drift: Are outputs changing? Track the distribution of predicted scores, the fraction flagged “yes,” and the volume of alerts. A sudden spike may indicate a process change or a data bug.
• Outcome performance: When true outcomes arrive (late/not late, actual days), compute the same metrics you used in evaluation. Also track baseline side-by-side so you can tell whether the model is still beating “do nothing” or “simple rule.”

Feedback closes the loop. Record what action was taken and what happened afterward. This creates future training data and reveals operational issues (“we ignored most alerts,” “overrides are common for Vendor X”). Decide in advance what triggers a response: e.g., “If accuracy drops by 10 points,” “If missing values exceed 5%,” or “If the flagged rate doubles.” Your response options are: fix the data pipeline, adjust the threshold, update documentation, or retrain the model with newer data.

Retraining is not always the first answer. Many failures are workflow failures: wrong inputs, new categories, or a threshold that no longer matches capacity. Treat retraining as a controlled change with a new model card version and a clear comparison to the previous model and the baseline.

To package your final mini-project, aim for a “work-ready predictor plan” that someone could follow without you in the room. Your deliverable is not just a model file; it is a small system with documentation, workflow, and monitoring. Below is a practical outline you can copy into a single document (or a short slide deck) and present confidently.

• Problem and decision: One paragraph describing the work question, the prediction target, and the action it triggers (decision, queue, or alert). Include the owner and how often predictions run.
• Data snapshot: What data sources you used (often a spreadsheet export), the date range, row count, and top data issues you found (missing values, inconsistent categories). State what you excluded and why.
• Model and baseline: Name the simple model type (e.g., linear regression, logistic regression, small decision tree) and the baseline you compared against. Include the key metric(s) and the result in plain language (“reduced average error from 6.2 to 4.8 days”).
• Workflow design: Describe the human-in-the-loop points, thresholds, and what happens on bad inputs. Include the override path and where overrides are logged.
• Model card (one page): Paste the model card: intended use, non-use cases, key inputs, metrics, known failure modes, fairness/privacy notes, and contact/escalation.
• Monitoring plan: A simple table listing what you track (input drift, prediction drift, outcome performance), how often, and what thresholds trigger investigation or retraining.

When presenting, focus on outcomes: what will be faster, safer, or more consistent. Show one realistic example: the inputs for a single case, the model’s output, the recommended action, and how a human would confirm or override it. This makes the deployment feel concrete, not theoretical.

If you can do this with a spreadsheet and a clear process, you have learned the most important beginner skill in machine learning: turning a predictor into a dependable work tool with sensible guardrails.