Introduction
Imagine you just opened a coffee shop. Every day, new reviews roll in on Yelp, and news articles mention your shop here and there. Some are lovely. Some are angry. Most are... just noise.
Now imagine hundreds of them every week.
You want to read the ones that matter - the unhappy customer who's about to stop coming, the person begging for oat milk. But finding those few needles in a mountain of feedback is exhausting. By the time you spot the problem, the customer is already gone.
That's the exact problem this project solves. And the best part? the idea is simple enough that a total beginner can follow it.
In this post I'll walk you through Customer Sentiment Intelligence - a small Python project that reads public feedback and sorts it into four tidy buckets. If you've heard words like "API" or "AI" but never quite knew what they meant, you're in exactly the right place.
What you'll learn
By the end, you'll understand:
- What a pipeline is (spoiler: it's just steps, like a recipe)
- What an API is and why it saves you from writing scrapers
- How a computer can "read" a review and give it a score
- How a few simple rules can sort feedback automatically
- A smart habit: only spend money where it counts
No math. No degree. Just curiosity.
The big idea, in one sentence
Feed a company name into the script, and it hands you back a neat list of every review and news article, each one understood, scored, and sorted into the right bucket.
Think of it like a friendly mail sorter at a post office. Mail comes in messy and mixed-up. The sorter reads each piece, decides what it is, and drops it into the right bin. The proposed solution does the same thing - but for customer feedback instead of letters.
Here's the journey a single review takes. It comes in messy, gets cleaned up into a consistent shape, gets read and scored, drops neatly into a bucket, and - only when it's important enough - gets a deeper AI look.
Five words you'll see, explained simply
- Pipeline - A set of steps done in order, like following a recipe. Step 1, then Step 2, then Step 3. That's it. Nothing more mystical than that.
- API - Short for "Application Programming Interface." Fancy name for "a way for two programs to talk to each other." Think of it like a waiter: you tell the waiter what you want, they go get it from the kitchen, and bring back your food. You never have to cook it yourself.
- Sentiment - Just the feeling behind some words. Positive (happy), neutral (meh), or negative (upset).
- Score - A number the computer gives something after "reading" it, like a rating out of 4 stars. It's the computer's way of saying "how big is this?"
- Triage - A hospital word for "sort patients by how urgent they are." it's used to sort feedback by how much it needs your attention.
That's honestly most of the vocabulary. Let's build.
Step 1 - Collect the feedback (without writing a scraper)
First we need the reviews. You could try to grab them yourself by copying and pasting from the Yelp website - but that's slow, fragile, and against most sites' rules.
Instead, use a service called SerpApi. Remember the waiter analogy? SerpApi is our waiter for search data. You ask it, "Hey, find the Yelp page for this coffee shop and give me its latest reviews," and it hands back clean, organized data. No messy HTML, no scraping, no maintenance.
Under the hood, the script does two little requests. First it searches Yelp for the business and grabs its permanent ID - think of it like a library card number for that shop. Then it uses that ID to pull up to 100 recent reviews. As a bonus, it can also fetch the latest news articles that mention the shop, so you're not just looking at reviews but the wider conversation around the business too.
Step 2 - Clean it up (make everything match)
Here's a hidden headache in programming: data is messy. A Yelp review stores the date in one field, the rating in another, and the customer's name somewhere else entirely. A news article has completely different fields. Comparing them is like trying to read a book where every page is a different size and language.
So, before we do anything smart, we normalize everything - meaning we reshape every piece of feedback into the same format, with the same boxes to fill in. Every review and every article gets the same nine slots: a unique ID, the company name, where it came from, what kind of source it is, when it was published, its rating, who wrote it, the actual text, and a link back to the original.
Now every review and every news article looks identical underneath: same company, same date field, same text field, same URL. The rest of our pipeline never has to worry about where the data came from.
The duplicate problem (and a clever trick)
Sometimes the same review shows up twice - maybe it appeared in two different fetches. Re-reading it wastes time and can skew our counts. So, we deduplicate: remove copies so each real review is counted exactly once.
How do we know two reviews are "the same"? We give each one a fingerprint. Behind the scenes, a small helper takes the key pieces of a review - the company, the text, and the date - and squeezes them into a short, fixed-length code using a standard technique called hashing.
Don't let the word "hash" scare you. All it does is turn some text into a short code. Same input equals the same code, every single time. So if two reviews produce the same fingerprint, we know they're identical and keep only one. Empty reviews with no text at all get tossed out too.
Step 3 - Understand each review (the "AI" part, demystified)
Now for the fun part: teaching the computer to understand what a review is actually saying.
We send each cleaned-up review to a scoring service (System One model) and ask it seven simple questions about the review. That's the whole "AI" - it's just a set of questions asked over and over.
Here are the seven questions in plain English:
- Is this even about the customer's experience? (Relevant?) - A review about the weather isn't useful to us.
- How do they feel? (Sentiment) - Happy, meh, or upset?
- What are they trying to do? (Intent) - Complaining? Praising? Asking a question? Requesting something?
- What's it about? (Topic) - Pricing? Support? The product itself?
- How serious is it? (Severity) - A tiny nitpick, or a serious problem? Scored 0 to 4.
- Does a human need to step in? (Needs escalation?)
- Could this customer leave? (Churn risk) - Scored 0 to 4.
Notice we're not asking the AI to write an essay. We're asking simple, specific questions - and it answers with one of three easy formats:
- Yes/No with a confidence (like "90% sure this is relevant")
- Pick one from a list (like "this is a complaint")
- A number from 0 to 4 (like "severity level 3")
Those three answer styles have technical names - noul, choice, and score - but you can just think of them as yes/no, pick-one, and how-many-stars.
Here's what one of those questions looks like behind the curtain. The relevance question, for example, is set up to expect a simple yes-or-no answer with a confidence score attached. Its instructions read like an ordinary sentence - "Is this materially relevant to the customer's experience?" - and it even spells out what counts as yes (directly concerns the customer) versus no (nothing to do with the customer experience). That clarity is the whole point: the better you define the question, the better the answer.
Step 4 - Sort into buckets (the sorting rules)
This is my favorite part, because it's only about a dozen lines of code and it does something genuinely useful: it decides what to do with each review.
We sort every review into one of four buckets:
| Bucket | What it means | What you should do |
|---|---|---|
| DISCARD | Not about the customer experience at all | Ignore it |
| QUEUE | Unclear or something went wrong | A human takes a quick look |
| ANALYZE | A real, useful signal | Worth a deeper look |
| ESCALATE | Serious - a customer might be at risk | Act now! |
The rules are checked top to bottom, and the first one that matches wins - just like a checklist. In plain English, the engine reads the scores it got back and walks through them in order. First, it checks relevance: if the review isn't really about the customer experience, it's discarded - no point wasting anyone's time. Next, if the model wasn't confident about how the customer felt, it's queued for a human to make the call rather than guessing. Then it checks for danger: if the review needs escalation, or the churn risk is high, it's flagged for immediate action. And if none of that fire, the review is treated as a normal, useful signal that's worth a deeper look.
Every bucket also gets a short, human-readable reason attached - something like "Low customer relevance" or "Material customer risk signal" - so you always know why something landed where it did.
Read it top to bottom and you'll see it's just common sense wearing a costume:
- If it's not relevant (score under 0.60), don't waste time - discard it.
- If the model isn't confident about the feeling (under 0.70), don't guess - queue it for a human.
- If it needs escalation (0.80+) or the churn risk is high (3.0+), escalate it immediately.
- Everything else is a normal signal - analyze it.
Those four numbers (0.60, 0.70, 0.80, 3.0) are just knobs you can turn. If you want to be extra careful, lower them so more things get a human's eyes. They all live in one place, so tuning is easy.
Step 5 - The optional AI deep-dive (and how to keep costs down)
For reviews in the ANALYZE and ESCALATE buckets, you could ask an AI model for a full write-up: What's the real issue? What probably caused it? How might we respond?
Remember, most reviews get discarded as noise. Why pay an AI to analyze "5 stars, love it!"? We already know what to do with that - nothing. So, the expensive AI step runs only on the important buckets.
And if you don't have an AI key set up at all? No problem. Before it would call a paid model, the script checks whether one is actually configured. If not, it simply hands back the exact question it would have asked - labelled as a draft prompt - instead of a paid answer. The feature fails gracefully instead of breaking.
One more safety habit: nothing disappears
What happens if something goes wrong halfway through - say, the scoring service has a hiccup on one weird review? A naive script would crash and lose everything. Not this one.
Each review is handled inside its own little safety net. The script tries to score and sort each one, but if something goes wrong on a particular review, it doesn't panic and it certainly doesn't lose your work. Instead, it catches the problem, quietly notes what happened, and routes that single review to the QUEUE bucket - the "a human should peek at this" bin.
So if one weird review causes a hiccup, it doesn't take down the whole batch. It just gets parked for human review, and everything else keeps flowing.
Try it yourself
Want to see it work? You'll need Python installed and a free SerpApi key (they have a free tier). Getting started takes three friendly steps. First, set up a virtual environment - think of it as a clean little room just for this project, so its tools don't mix with anything else on your computer. Second, install the project's dependencies and drop your API keys into a small settings file. Third, run the script from your terminal and tell it which company to look up, along with the city, state, and country so it can find the right place on Yelp. In other words: create the room, install the ingredients, then cook.
If you'd rather use it as a tiny web service instead of a one-off command, you can start the server and then send it a request over the internet, pointing it at the same company and location. It responds in exactly the same way - the web version just wraps the same pipeline behind a friendly address.
Either way, you get back one clean summary: how many reviews you found, how many were positive, neutral, or negative, and a bucket for every single one.
What I hope you take away
You don't need to be an expert to build something genuinely useful. This whole project rests on ideas any beginner can hold in their head:
- Break the problem into steps - collect, clean, understand, sort. That's a pipeline.
- Use services, don't reinvent them - APIs save you from fragile scraping.
- Normalize your data early - one consistent shape makes everything downstream easier.
- Ask clear questions - "AI" is often just structured questions with structured answers.
- Simple ordered rules can be powerful - a dozen readable lines can replace hours of manual sorting.
- Fail safe, spend smart - never let one error crash everything, and never pay for work you don't need.
If you've been waiting for a "big" project to feel ready for, this is your sign: the best projects are just small, clear ideas stacked together.
Quick glossary
- Pipeline - Steps done in order, like a recipe.
- API - A way for two programs to talk, like a waiter between you and the kitchen.
- Sentiment - The feeling behind words: positive, neutral, or negative.
- Score - A number rating something, like 0-to-4 stars.
- Triage - Sorting things by how urgently they need attention.
- Normalize - Reshaping messy data into one consistent format.
- Deduplicate - Removing copies so each item is counted once.
- Fingerprint (hash) - A short code that's identical for identical input; handy for spotting duplicates.
-
noul/choice/score- The three answer styles: yes/no-with-confidence, pick-one-from-a-list, and a 0-to-4 rating.
Key Takeaways
- APIs simplify data collection and reduce maintenance.
- Normalizing data upfront saves time later.
- AI can be framed as structured Q&A rather than complex black‑box predictions.
- Smart categorization helps teams focus on what matters most.
- Cost‑effective design ensures scalability without overspending.
Top comments (0)