Small‑Team Continuous Improvement System That Actually Changes Behavior

Most dry cleaners don't fail at improvement because they lack ideas. They fail because the improvement lives in someone's head, gets tried for two weeks, and quietly dies when the owner gets pulled into a busy Saturday. Then three months later the same problem shows up again, and everyone acts surprised.

That's the real problem with "continuous improvement" in a small shop. It's not that the changes don't work. It's that nothing holds them in place. The pressing station tweak that cut rework? Gone the moment the person who invented it took a week off. The new intake question that caught more pre-existing damage? Forgotten because nobody wrote down who owned it.

So this isn't a pep talk about building a culture of improvement. It's a description of the actual system — calendar, templates, QC hooks, and ownership routines — that makes changes stick in a shop where the same five people wear ten hats each.

Why improvement quietly dies in small shops

The pattern is almost always the same, and it has very little to do with laziness.

In a 2–15 person shop, the person who spots a problem is usually the person who has to fix it, run the counter, and close the register. There's no separation between "thinking about the business" and "doing the business." Improvement work gets done in the cracks — and the cracks are the first thing to disappear when volume spikes.

The second reason is that most shops treat improvement as a mood, not a schedule. "We should really fix the tagging mix-ups" is a feeling. It has no date, no owner, no way to tell whether it worked. Feelings don't survive a busy season.

And the third reason — the one people rarely admit — is that shops try too many things at once. An owner reads a few articles over the weekend and comes in Monday with five new changes. Staff nods, gets overwhelmed, and reverts to habit by Wednesday. Nothing was measured, so nothing was learned.

What actually works at this size is boring by design: one or two experiments at a time, on a fixed calendar, with a named owner and a way to check the result against real data. The magic is in the constraint.

The quarterly experiment calendar

The core of a working dry cleaner continuous improvement system is a calendar that limits how much you try at once. Small shops don't have the bandwidth to run six experiments in parallel, and if you try, you can't tell which change caused which result.

Here's the structure that holds up across shops this size:

1. 1
   One "big" experiment per quarter — something that touches workflow or layout and takes real effort (a new work-cell handoff, a revised inspection gate, a route change).
2. 2
   Two "small" experiments per month — quick tests you can run without disrupting production (a new intake script, a different tag color for rush orders, a supplier swap).
3. 3
   A two-week minimum run time for anything worth measuring. Anything shorter and you're reacting to noise.

A realistic quarter might look like this:

The point isn't to fill every slot. If you run three experiments in a quarter and two of them stick, that's a genuinely successful quarter. Most shops overestimate how many changes they can absorb and underestimate how long it takes a new habit to set.

One pattern worth calling out: shops that put the calendar on a physical wall in the back — not buried in a phone — actually run their experiments. Visibility does most of the enforcement work. When everyone can see that Week 6 is "test rush-tag color," it's harder for it to vanish.

The hypothesis template (keep it to one card)

A hypothesis in a small shop should fit on an index card. The moment it needs a document, it won't get filled out. The whole purpose is to force you to say, before you start, what you expect to happen and how you'll know.

1. 1
   What we think is happening — the problem, stated plainly. ("Rush orders get lost between assembly and the front rack.")
2. 2
   What we're going to change — one thing. ("Rush orders get a bright orange tag instead of the standard white.")
3. 3
   What we expect to see — the predicted result. ("Missed rush deadlines drop from around 3–4 a week to under 1.")
4. 4
   How we'll measure it — the exact source of truth. ("Rush deadline misses on the daily log.")
5. 5
   Who owns it — one name, not a team.
6. 6
   When we decide — the review date. ("Review end of Week 8.")

The reason this matters more than it looks: writing down the expected result before you start kills a bad habit small shops fall into — declaring every experiment a success after the fact. If you didn't predict a number, you'll always find a reason it "kind of worked." A pre-committed prediction forces an honest yes/no.

A common mistake here is changing two things at once inside a single hypothesis. If you swap the tag color and move the rush rack, you'll never know which one helped. One change per card. If you're tempted to bundle, that's usually two experiments trying to sneak in as one.

Wiring QC into your experiments (sample-based, not everything)

A lot of small shops go wrong in one of two directions: they either check nothing, or they try to inspect every garment and burn out in a week. Neither gives you usable data.

Sample-based QC is the middle path. Instead of inspecting all output or none of it, you pull a consistent sample and score it against the same criteria every time. For a shop doing a few hundred pieces a week, checking a fixed sample per day — say the first 15 pieces off pressing each morning plus 15 random pulls — gives you a stable defect signal without stopping production.

The sample has to stay consistent while you run an experiment, or your "improvement" is just measurement drift. If you inspect 30 pieces before the change and 8 pieces after, a drop in defects means nothing.

Tie the QC sample directly to the hypothesis. If the experiment is about pressing rework, your sample should specifically flag re-press cases. If it's about intake accuracy, your sample checks tag-to-ticket matches. A general "quality looks good" check tells you nothing about the specific change you made.

This connects directly to the kind of defect-tracking discipline covered in a lightweight QMS that stops repeat garment defects. The QMS gives you the defect categories and logging habit; the experiment system gives you a reason to actually look at that data on a schedule instead of only after a customer complains.

“

Tie the QC sample directly to the hypothesis so the sample measures the specific change you're testing.

On sample size: you don't need statistical rigor. You need enough that a real change is visible. If your baseline defect rate is roughly 6–8% and it drops to 2–3% across a couple hundred sampled pieces over a few weeks, that's a signal you can trust at this scale. Don't overthink the math — just keep the method identical before and after.

Ownership routines: the part everyone skips

This is where most improvement systems fall apart, and it's the least glamorous part. An experiment without an owner is a suggestion. A calendar without a review cadence is a wall decoration.

Daily (2 minutes, verbal): Whoever owns the active experiment says one sentence at the morning huddle — "rush-tag test is running, we've had zero misses so far this week." That's it. Keeps the experiment alive in everyone's attention without eating into the day.

Weekly (10 minutes): The owner logs the week's numbers against the hypothesis. Not analysis — just recording. This is where the QC sample data lands. If it's not written down weekly, it won't exist at review time.

Quarterly (30–45 minutes): The whole team looks at what ran, what stuck, and what reverted. This is the only meeting that should feel like a real sit-down. Everything else stays lightweight on purpose.

What breaks these routines is making them too big. A weekly review that takes 45 minutes gets skipped by week three. Keep the weekly one boring and mechanical — numbers in, done.

One thing worth sitting with: in shops where the owner personally holds every experiment, nothing scales past the owner's attention span. The shops that actually build a lasting improvement habit are the ones where the counter lead owns intake experiments, the production lead owns pressing experiments, and the owner mostly manages the calendar itself. At 8+ people, distributed ownership isn't optional — it's the only thing that works.

A real scenario

A three-station shop doing roughly 550–650 pieces a week kept getting the same complaint: garments coming back with pickup-stage damage the customer swore wasn't there before. The owner had "fixed" it twice — once by yelling about it, once by adding an inspection step that lasted about a month.

They ran it as a proper experiment instead. Hypothesis: most of the damage was happening at the assembly-to-rack handoff, not in cleaning. Change: a single QC checkpoint with a photo at final assembly, owned by the assembly person, reviewed weekly. Sample-based check on 20 pieces a day against a short defect list.

The first two weeks looked flat, which nearly killed it — but because there was a fixed review date, they kept going. By week five, the daily sample showed the real issue was a specific rack where hangers were catching fabric. A five-minute fix, once they could actually see it. Pickup-damage complaints dropped from around 5–6 a week to one or two, and the change held because the photo step had an owner and a weekly number rather than depending on the owner's memory.

The lesson wasn't the photo step. It was that a fixed review date kept a slow-starting experiment alive long enough to find the actual cause.

When this system makes sense — and when it doesn't

It makes sense when:

1. 1
   You're running the same problems on repeat and fixes keep evaporating.
2. 2
   You have at least a couple of people who can own something besides the owner.
3. 3
   You already track some numbers — defect logs, deadline misses, rework counts.

It's a bad idea when:

1. 1
   You're in the middle of a genuine crisis (equipment down, cash crunch). Fix the fire first; experiment later.
2. 2
   You don't measure anything yet. Start with basic tracking before you start testing changes — otherwise you're running experiments blind.
3. 3
   You'll be tempted to run six things at once. If you can't commit to the one-or-two-at-a-time constraint, the calendar will just become a to-do list you ignore.

If you don't yet have a clear sense of which numbers actually move your profit, that's the real starting point — figuring out which KPIs actually predict profit at a dry cleaning shop before you build experiments around them. Testing changes against the wrong metric just gives you confident wrong answers.

Keeping the whole thing connected

None of these pieces work alone, which is worth being direct about.

The workflow end to end: a problem gets noticed → it goes on the calendar as a small or big experiment → someone writes the one-card hypothesis → the QC sample starts tracking the relevant metric → the owner logs weekly numbers → at the review date, the team decides keep, kill, or adjust → the ones that stick get written into the actual SOP so they stop being experiments and start being how the shop works.

Here's a simple visual of that workflow.

That last step is the one shops forget. An experiment that works but never gets written into the standard process isn't an improvement — it's a temporary lucky streak. The whole point is to convert good tests into permanent behavior, one at a time, at a pace a small team can actually absorb.

Lightweight operational software earns its place here, quietly — not as the hero of the story, but as the thing that logs your QC samples, timestamps your experiment reviews, and keeps the defect data in one place so the weekly review takes ten minutes instead of an hour of digging. When the logging is frictionless, the routines survive busy seasons. When it's a hassle, they don't. But the tool is downstream of the discipline, not a substitute for it.

Start with one experiment this quarter. Give it an owner, a card, a sample, and a review date. Get one change to stick. Then do it again. That's the whole system — and it's the only version of continuous improvement that actually survives contact with a busy shop.