Skip to main content

From Insight to Action: The Feedback Loop Every Business Needs

A one-star review at midnight costs you more than a one-star review at noon. The gap in between is the real problem. Here's what I learned building two projects to close it.


I want to walk through a problem I kept running into while scoping two recent projects, because the problem itself turned out to be more interesting than either solution on its own.

Here's the scenario: a customer buys a product, it arrives defective, and they leave a one-star review at midnight. Nobody on the support team sees it until the next morning. By then, the review has already been read by hundreds of other shoppers, maybe shared once or twice, and the original customer has already written the company off.

Ask most teams what went wrong here, and they'll point at the review itself — "we got a bad review." That's not really the failure. The failure is the gap between the moment a customer tells you something and the moment your business does anything about it. A one-star review at midnight and a one-star review at noon are the same complaint. The difference that actually costs you customers is the eight hours in between.

That gap is invisible when you're handling ten reviews a day. It becomes a structural problem the moment you're handling thousands of them, spread across a marketplace, an app store, and three social platforms — which is exactly the situation most growing businesses find themselves in sooner than they expect.

Lesson One: A "Negative" Label Hides More Than It Reveals

The first project I built was, on the surface, a standard sentiment classifier — trained on movie reviews, predicting positive or negative. But the more I worked with it, the clearer it became that stopping there throws away almost everything useful in the text.

Two "negative" reviews can be negative for completely different reasons:

  • One customer is annoyed about a slow delivery.
  • Another customer received a genuinely broken product.

Both get flagged "negative." Both, in a naive system, get treated the same way. That's the mistake I wanted to design around.

So instead of a single sentiment score, the system pulls apart a review across several dimensions:

  • The emotion underneath the words — is this anger, disappointment, or just mild surprise? (This came from word embeddings and cosine similarity, not simple keyword spotting.)
  • What aspect of the product or experience the review is actually about — story vs. acting vs. visuals in the movie-review dataset; price vs. durability vs. support in a commercial one.
  • How similar this complaint is to others, using BERT-based embeddings, so that ten different customers describing the same defect in ten different ways get grouped as one recurring issue instead of ten unrelated complaints.

The practical effect: instead of a dashboard that says "40% negative today," you get one that says "12% of today's negative reviews are about shipping delays, and 6% are about a specific hardware defect that's trending upward." That second version is something a business can actually act on.

Lesson Two: Understanding Without Action Is Just a Nicer Dashboard

The second project started from a blunter question: once you know what customers are saying, what do you actually do about it — especially when there are too many reviews for a human to respond to each one individually?

This is the part where it's tempting to just hand the problem to an LLM and let it reply to everyone. I'd push back on that instinct. An AI responding to customers at scale, with no oversight, can get facts wrong, drift from brand tone, or worse — say something that creates a compliance problem nobody catches until it's already public. Speed is only a win if what's moving fast is also correct.

So the system I built treats "fast" and "safe" as two requirements that both have to be satisfied, not traded off against each other:

  • Reviews get pulled straight from a live database rather than a static export, so the system reflects what's happening right now.
  • Each review gets tagged not just with sentiment but with urgency and intent — is this praise, a complaint, a product issue, or a feature request? Each of those routes to a different team.
  • Recurring themes get surfaced across reviews, so a support lead can see a pattern forming before it becomes a crisis.
  • An LLM drafts a response aligned to company policy and tone — but it drafts, it doesn't send.
  • A human reviews and approves before anything reaches a customer.

That last point is the one I'd defend the hardest. The value of GenAI here isn't replacing judgment — it's clearing out the repetitive 80% of the work so a human's judgment gets spent on the 20% that actually needs it.

Two Questions, Not One

What I like about having built both pieces is that they answer two genuinely different questions that are easy to accidentally merge into one:

What are customers really telling us? — that's a data science and NLP problem.

How should we respond, responsibly? — that's a systems and process design problem, and the interesting decisions there are mostly about where you deliberately slow the system down so a person stays in the loop.

Neither project is complete without the other. Understanding without a response mechanism is a report nobody acts on in time. A response mechanism without deep understanding just replies fast to the wrong problem.

I'll be publishing the deeper technical breakdown of both — the actual pipeline, the model choices, and the specific tradeoffs I ran into — in the posts that follow.

If you had to pick just one to fix first in your own work — understanding feedback better, or responding to it faster — which would it be, and why? 

I'd genuinely like to hear how others think about that tradeoff.

Comments

Post a Comment

Popular posts from this blog

The First Notebook

Somewhere between where I was and where I am going! Welcome to One Notebook at a Time. Every data project starts the same way. A blank notebook. A first cell. No idea yet what the data is going to say, or whether the model is going to work, or whether the whole approach is wrong and you'll scrap it by Tuesday. You just start. This blog is that first cell. Why "One Notebook at a Time" I picked this name because it's literally true on two levels. If you're a data person, you already know what a notebook is — Jupyter, Colab, whatever your tool of choice. It's where the real thinking happens. Not the polished dashboard, not the final slide deck — the notebook. Messy cells, half-finished thoughts, a graph that didn't work followed by one that finally did. But it's also true in the older sense of the word. A notebook is just where you write things down before you know what they're going to become. That's what this space is for. One notebook — one pos...
Post a Comment
Read more

The Line of Best Fit Isn't "Best" — It's a Decision What I wish someone had told me before I ran my first regression model.

  Same data. Different definition of "best." Different line." Here's something that took me longer than I'd like to admit to figure out about linear regression. That line through your scatter plot — the one everyone calls the "line of best fit" — isn't objectively the best anything. It's the best fit for one very specific definition of the word "best." Swap that definition, and you get a completely different line. Equally valid mathematically. Just built on a different set of assumptions. Once I understood that, I started looking at every machine learning model differently. What Everyone Gets Taught (And What Gets Left Out) The standard introduction to linear regression goes something like this: draw a line through your data that minimises the total error between your predictions and the actual values. Square those errors, add them up, minimise the sum. Done. This is Ordinary Least Squares (OLS) — the engine behind most introductory r...
Post a Comment
Read more

The Network That Learns Who Comes Back

It's been a minute since I last posted here — most of that gap was spent heads-down on a project I just wrapped up, so let's catch up. Where a heartbeat becomes a data point — teaching a neural network to see risk before it happens. If you've followed along before, you know this space usually lives in supervised learning — regression, classification, the more "classical" side of the toolkit. This post is a deliberate left turn into neural networks , the first one I've built and documented fully end-to-end. I expect this thread to keep rotating: NLP is probably next, and I'll likely circle back to supervised or unsupervised learning again after that. Think of it as this notebook's current chapter, not a permanent pivot. The setup The project: predict whether a patient will be readmitted to hospital within 30 days of discharge, using a 5,000-row dataset of vitals, prior admission history, chronic conditions, and a handful of administrative fields. It...
Post a Comment
Read more