Why generic categories fall short
Most feedback tools ship with a fixed set of categories — "bug," "feature request," "billing," "UX" — and quietly force your product into that mold. For a while it is fine. Then you notice that half your feedback lands in a vague catch-all, that two categories you actually care about are merged into one, and that the labels do not match the language your own team uses in standup.
The problem is that categories are not universal. A developer-tools company cares about "API reliability" and "SDK ergonomics." A consumer app cares about "onboarding friction" and "notification fatigue." A vertical SaaS product has domain-specific concerns no off-the-shelf taxonomy will ever anticipate. When the categories are wrong, every downstream chart, filter, and priority list inherits that distortion.
Rereflect takes a different stance: the taxonomy is yours to define, and your definitions are fed directly into the analyzer so the AI categorizes against the buckets you actually use.
Custom taxonomies that feed the analyzer
Rereflect lets you define custom categories across the three dimensions it analyzes — pain points, feature requests, and urgency. Crucially, these are not just display labels applied after the fact. Your taxonomy is passed into the analysis step itself, so the AI is reasoning about your categories when it reads each piece of feedback.
That distinction matters. A tool that lets you "rename" categories after analysis is just relabeling generic output. A tool that feeds your taxonomy into the analyzer is genuinely classifying feedback into the buckets you defined, which produces far more accurate and useful results.
- Custom pain-point categories — define the specific problem areas your team tracks, so complaints get sorted into buckets that map to real owners and roadmap themes.
- Custom feature-request categories — group incoming requests under the product areas you plan around, instead of one undifferentiated "feature request" pile.
- Custom urgency definitions — describe what "urgent" actually means for your business, so churn-risk and critical-issue flagging reflects your thresholds rather than a generic default.
Because the analyzer works from your definitions, the categorization improves the more precisely you describe each category. Clear, distinct category descriptions give the model strong signal; vague or overlapping ones invite ambiguity. Treat your taxonomy like documentation for the AI — the better you describe each bucket, the better the sorting.
Designing a taxonomy that works
A good taxonomy is a balance between granularity and usability. Too few categories and everything collapses into a useless catch-all. Too many and the signal scatters so thinly that no category ever accumulates enough volume to act on. A few principles help:
- Map categories to owners — if no one on your team owns a category, you will never act on what lands in it. Categories should correspond to teams, roadmap themes, or decision-makers.
- Keep categories mutually distinct — overlapping categories force both the AI and your team to guess. Each bucket should have a clear boundary that a human could apply consistently.
- Describe, do not just name — a category called "performance" is ambiguous; a category described as "slowness, timeouts, and latency in the core editor" gives the analyzer something concrete to match against.
- Start small and split later — begin with the handful of categories you genuinely track today. When one accumulates enough volume that it needs subdivision, split it then.
Because the taxonomy is configurable per organization, different teams running their own Rereflect instance can each shape it to their product without affecting anyone else.
Configurable customer-health-score weights
Categorization tells you what customers are saying. The customer health score tells you which customers are in trouble. But "health" is not a one-size-fits-all formula — the signals that predict churn in your product are not the same as the ones that predict it in someone else's.
Rereflect makes the health score configurable per organization. Rather than locking you into a fixed formula, it lets you set the weights that determine how much each signal contributes to a customer's overall health. If declining sentiment is the strongest leading indicator of churn in your business, weight it heavily. If a drop in engagement matters more for your product, shift the weight there.
This turns the health score from a generic gauge into a model of churn that actually reflects your reality. Two organizations looking at the same raw signals can produce different, equally valid health scores — because they have tuned the weights to their own retention dynamics.
Tuning weights honestly
Configurable weights are powerful, but they invite a temptation: tuning the score until it tells you what you want to hear. The discipline is to tune it until it tells you what is true. A few practical guidelines:
- Anchor on real outcomes — when you have customers who actually churned, look back at what their health score and underlying signals looked like beforehand. Adjust weights so the score would have flagged them in time.
- Change one weight at a time — sweeping multiple weights at once makes it impossible to tell what improved the score and what just moved it.
- Beware over-fitting to a few cases — a handful of churned accounts is anecdote, not pattern. Wait for enough history before trusting any single signal's weight.
- Revisit periodically — your product, pricing, and customer base change. Weights that were predictive last year may not be this year. Treat the configuration as something you maintain, not something you set once.
The goal is a health score your team trusts enough to act on — proactively reaching out to accounts the score flags, and confidently leaving healthy ones alone.
Bringing it together
Custom taxonomies and configurable health weights work best as a pair. The taxonomy shapes how feedback is understood; the health weights shape how that understanding rolls up into a per-customer risk signal. Together they let you bend a general-purpose feedback analyzer until it fits your specific product, your specific language, and your specific definition of a customer in trouble.
Rereflect is open source and self-hosted, so this configuration lives in your own instance, tuned by your own team. Define the categories that match how you actually think about your product, set the health weights that reflect how churn really happens for you, and let the analyzer do the rest. Clone Rereflect and start shaping it to your product on your own infrastructure.