Diagnosing a Complaint That's Really About Preference
Why this matters
A preference dressed up as a complaint will eat your day if you treat it as a repair. There is nothing to fix, so nothing you do satisfies, and you gave the time away for free because you called it warranty in your own head. Spotting preference early lets you honor it, which is legitimate, and get paid for the work it actually takes, instead of chasing a defect that was never there.
Fault versus preference: the defining line
- A fault is a deviation from how the system should work. Something changed, something is out of spec, something is broken.
- A preference is a wish for the system to work differently than it was designed or set, with nothing actually wrong. The system is fine; the customer wants a different fine.
Every comfort complaint sits on one side of that line. Your first job is to figure out which, because the two get completely different responses.
Tells that it is preference
When these line up, you are looking at a want, not a defect:
| Tell | What it means |
|---|---|
| It has always done this, they now want it different | No deviation; the system did not change, the desire did |
| Another user in the same setup is satisfied | The condition is acceptable to spec and to someone; this is individual taste |
| It started right after they changed a setting | They are reacting to their own adjustment, not a fault |
| Nothing measurable deviates at any point or time | There is no fault to find |
Name it without judgment
Preference is not a lesser complaint or a customer being difficult. People are allowed to want their space a certain way. Say it cleanly:
- "Good news, nothing's broken. What you're describing is the system working as set. We can change how it behaves, and here's what that takes."
- Do not make them feel foolish for calling. The complaint was real; it just resolves with a change, not a repair.
Convert it to scoped, priced work
Meeting a preference is real work and it is billable. The move is to turn a vague want into a defined change:
- Pin down the exact target: what behavior, in which room, at what time.
- Scope what it takes to get there (a setting, a balance, added zoning, a relocated fixture, a capacity change).
- Price it and let them decide. This is a change order, not a callback, and framing it that way protects your time and sets a clear expectation of the result.
The exception: preference that reveals a real mismatch
Not every preference is just taste. Sometimes "I wish it did X" is the customer finally naming that the system was wrong for their use from the start (undersized, misplaced, the wrong type for the load). If the want points to a genuine design mismatch, treat it as a design conversation, not a simple preference. The tell is that the stated preference is a normal expectation the system should arguably meet, not an unusual one it was never built for.
References
- Trade-standard practice on scope definition and change orders
- Manufacturer documentation on design intent and adjustable ranges
- See related: The Difference Between In-Spec and Acceptable to the Customer; When the Fix Is Education, Not a Repair