How your team gets better, on purpose.
Improve is the function with the highest payoff and the least process. It's the difference between a team that fights the same fires forever and a team that compounds. What you find, what you fix, what you prevent next time.
v 02 · live
What Improve means.
Improve is the work of turning what hurts into what's better. Not the work of running retros. Not the work of writing post-mortems. The work of finding friction, naming it, fixing it, and preventing it from coming back. As a routine, not as a heroics.
Most CX teams find friction the hard way. A complaint pattern emerges. The team tells the lead. The lead tells engineering. Engineering says they'll look at it. Six weeks later, the pattern is still there. The team learns not to bother. The friction becomes the floor.
That's the gap Improve names. The signal exists; the system to act on it doesn't. Operators see patterns; the org has no inbox for them. Improvement becomes a side project, not a core function.
"I made my team a list of "things we keep solving for customers that shouldn't need solving." It was 18 items. We solved 12 of them in three months. The other six were product changes engineering wouldn't take. But just having the list changed everything. The team felt heard for the first time."
Haven's Improve module starts with the friction inbox. A named place for the team to log patterns. A weekly triage. A clear owner for each friction. A path from "this keeps happening" to "this doesn't anymore."
The team learns to name patterns. The org learns to act on them. Improvement compounds because it's routine, not heroic.
The progression. Four levels.
Friction is folklore. The team knows the patterns; nobody writes them down. Fixes happen when a pattern blows up. Same fires, every quarter.
- Friction is folklore
- Fixes are reactions
- Same fires every quarter
- No inbox for patterns
Some patterns get logged. The lead keeps a running list. Some get fixed. Engineering takes the obvious ones. The rest stay on the list, year after year.
- Lead's running list
- Obvious fixes happen
- Long-running stale items
- No retirement criteria
The friction inbox is named, triaged, and owned. Weekly triage. Each friction has an owner and a fate. The team sees patterns turn into changes.
- Named inbox
- Weekly triage
- Named owners
- Patterns turn into changes
Patterns get caught before they're patterns. Detection is automated. The inbox is rarely full. The team's job becomes prevention, not reaction.
- Automated detection
- Inbox rarely full
- Prevention over reaction
- Compound improvement
What Improve builds.
The friction inbox
A named place for the team to log patterns. Tagged, dated, ownable. The signal layer the org never built.
- Single named place to log patterns
- Tagged, dated, ownable
- Open to the whole team
- Linked to QA findings & KB drift
The triage ritual
A weekly 30-minute session where the inbox gets owned. Each friction is named, fated, and assigned. Nothing stays orphaned.
- Each friction named, fated, assigned
- Closed, parked, or owned — never orphaned
- Routes to Build / Know / Enable
- Decision log per session
The pattern register
Solved frictions logged with the change that solved them. Compounding institutional memory. The same pattern doesn't get re-solved.
- Solved frictions paired with the fix
- Compounding institutional memory
- Searchable by symptom & surface
- Quarterly retrospective view