# Quality
> **What you will learn**
> How to judge the first question, "does the customer-facing product get
> better." And how to prevent the most common failure in quality work: **no
> measurement baseline.**
## The question
> **Does the customer-facing product get better?**
"Product" here is not only a physical thing. Service, support, delivery,
invoices — **everything the customer experiences.**
## What falls under this principle
Three representative shapes.
### 1. Finding product improvements from multi-channel review analysis
Customer reviews are scattered across marketplaces, your own store, and app
stores. Nobody can read them all, so **people look only at the star rating.** A
3.8 tells you nothing about what to fix.
Read all 10,000 reviews and group them by complaint type and you get:
```
Packaging complaints 31% ← spiked this quarter
Delivery delays 24%
Product performance 18%
Price 14%
Other 13%
```
That 31% on packaging is invisible from the star rating alone. **Telling you
where to fix** is the essence of quality work.
### 2. Catching customer dissatisfaction in real time with sentiment analysis
The usual pattern is **finding out after it has blown up.** Refunds spike or the
rating drops, and only then does someone say "something was going on."
Watch sentiment on inbound tickets in real time and the signal appears **before**
it blows up. A sudden rise in negative sentiment on one product's tickets is
itself the alarm.
### 3. Speeding up data-driven decisions
Decisions are usually slow because **gathering and organising material takes
time.** If preparing the meeting pack takes three days, decisions run on a
weekly cycle. Get it to one day and they run daily.
**Impact: stronger product competitiveness**
## The character of quality work — late to appear, long to last
```mermaid
graph TD
A["Start quality work"] --> B["Find the improvement"]
B --> C["Fix the product or procedure"]
C --> D["Customers feel it"]
D --> E["Shows in repeat rate / churn"]
E --> F["Shows in revenue"]
```
Many steps. Even after you start analysing reviews, it takes several quarters to
reach revenue.
- **Downside**: slow to prove. Heavy as a first project.
- **Upside**: once improved it lasts, and it is hard for competitors to copy.
## The most common failure — starting without a measure
Quality work fails in almost exactly one way.
> Six months later: "I think quality improved... but I don't know by how much."
This happens because **quality is inherently hard to measure.** Time and cost
naturally leave numbers behind; quality does not. So **if you do not decide at
the start, you never measure it.**
### What you can measure
Measuring quality directly is hard, but **the values that move when quality gets
worse** are measurable.
| Metric | Where it comes from | Caution |
|---|---|---|
| Repeat purchase rate | order data | strong seasonality |
| Return / refund rate | order data | the most direct |
| Ticket count (by type) | support system | down is good |
| Rating / review sentiment ratio | review data | sample can be biased |
| Rework / defect count | production and QA records | clear in manufacturing |
| Time to first response | support system | directly felt as quality |
### The table to fill in before starting
```
Project: find packaging problems via multi-channel review analysis
Metric: packaging-related tickets (monthly)
Current: ___ per month ← fill this in now
Method: count of 'packaging' tag in the support system, on the 1st
Target: 30% reduction in 6 months
```
**If the "current" cell is empty, do not start.** You cannot fill it in later.
## When to choose quality work
| Situation | Verdict |
|---|---|
| Complaints are rising and you do not know why | **good fit** |
| Review and ticket data is piling up unread | **good fit** |
| You already have measurement (return rate, NPS) | **good fit** — you have a baseline |
| It is the organisation's first AI project | poor fit — slow to prove |
| Data is scattered and hard to access | poor fit — fix the data first |
## Common misconceptions
### "Can't a person just sample the reviews?"
The problem with sampling is that **it misses low-share signals.** Read 100 and
you will see the 31% problem; you will not see the 3% one. And that 3% may be
the signal that becomes 20% next quarter.
The value of reading everything is not accuracy — it is **not missing things.**
### "I heard sentiment analysis is inaccurate."
Individual items can be wrong. But quality work looks at **trends**, not
individual items. If the negative share went from 12% to 19%, the direction is a
signal even if some individual classifications are off.
Separate **uses where per-item accuracy matters** (should we refund this
customer?) from **uses where the trend is enough.** Today's technology is plenty
for the latter.
---
## Check yourself
**1. Why is quality work heavy as a first project?**
Answer
**Because it is slow to prove.** Find improvement → fix the product → customers
feel it → metrics move: that is many steps and several quarters. An organisation
sustaining a transformation needs a visible early result, and quality work
struggles to provide one.
**2. If quality is hard to measure directly, what do you measure?**
Answer
**The values that move when quality gets worse** — return and refund rate,
tickets by type, repeat purchase rate, rework count. And you must **record the
current value before starting.** It cannot be filled in later.
**3. Why is sentiment analysis usable even though individual items can be wrong?**
Answer
Because quality work looks at **trends**, not individual items. If negative
sentiment went from 12% to 19%, the direction is a signal even with some
misclassification. Separate uses where per-item accuracy matters from uses where
the trend is enough.
---
Next, the area that proves itself fastest → [Cost](/guide/ax-cost)