Customer Says "It Worked Yesterday" Translation to Fault Decision Tree

Why this matters

"It worked yesterday" is one of the most useful sentences a customer can say, and one of the most often wasted. It tells you the system has a sharp onset, which brackets the cause to whatever changed in a narrow window. But the sentence is also imprecise: "yesterday" may mean last week, "worked" may mean "kind of worked," and the customer's timeline may be reconstructed from memory rather than observed. A tech who takes the phrase literally chases a one-day window; a tech who ignores it loses the single best clue on the call. This article translates the everyday phrase into a structured fault investigation that works across any trade.

Symptom presentation

The customer reports that the system functioned normally in the recent past and does not now. The framing is a before/after: a known-good state, then a fault. The phrase carries an implicit claim that something happened in between, even when the customer cannot say what.

What the customer means and what is literally true often diverge. "Worked yesterday" can mean it genuinely worked, it appeared to work, it worked intermittently and yesterday was a good day, or it failed gradually and yesterday is just when they noticed it crossing a threshold. The translation job is to find out which.

Quick checks at intake

Nail down the timeline. "When you say yesterday, was it definitely working, and how do you know?" Distinguish a confirmed working state (they used it and it was normal) from an assumed one (they did not use it but expected it to work).

Ask what changed between then and now. Recent service, weather, a power event, a renovation, a setting touched, a new device added, a part the customer swapped. New-onset faults have triggers; this question hunts the trigger.

Ask whether the failure was abrupt or whether yesterday was simply the day it got bad enough to notice. Abrupt points at an event; "got worse until I called" points at wear.

Isolation tree

Branch A: confirmed working, then abrupt failure, with an identifiable event in between. This is the cleanest case. Investigate the event first (a recent repair, a storm, a blown breaker, a setting change). The cause is almost always whatever happened in the window, not a spontaneous component death.

Branch B: confirmed working, abrupt failure, no event the customer can name. Look for an unremembered or unnoticed change: a tripped safety, a GFCI, a closed valve someone bumped, a clog that finished forming, a connection that vibrated loose. The sharp onset still means a discrete cause; you are hunting an event the customer did not register.

Branch C: "worked yesterday" actually means "worked intermittently and yesterday was good." Reframe as an intermittent fault, not a new-onset one. The system did not break overnight; it has been failing on and off, and the customer is reporting the most recent good day. Switch to intermittent-fault capture rather than chasing a single trigger.

Branch D: "worked yesterday" actually means "I assumed it worked but did not check." The known-good state is unverified. Treat the onset as unknown and diagnose from the symptom forward, because the timeline you were handed is an assumption, not an observation.

Branch E: gradual degradation that crossed a noticeable threshold yesterday. A slowly fouling filter, a wearing bearing, a creeping leak, a dimming output finally became obvious. The "yesterday" is perceptual, not physical. Diagnose the wear component, and educate the customer that the failure was building for a while.

Branch F: the timeline points at a seasonal first-run. "Worked yesterday" before a seasonal switch (first cold night, first AC day, first run after winter) means the system met a new demand it had not faced. Check the condition-sensitive parts that a season exposes, not a sudden breakage.

Branch G: the customer's "yesterday" coincides with someone else's work. A prior tech, a handyman, a DIY attempt, a delivery that moved something. Investigate the disturbance from that work first; coincident timing is rarely coincidence.

Confirming diagnosis

Confirm by tying the fault to the bracketed window. If the cause is the recent event, reversing or correcting it should restore function, which closes the loop tightly. A diagnosis that ignores a clearly identified trigger is suspect.

When the translation reveals the phrase meant something other than a one-day onset (intermittent, gradual, or unverified), document the corrected framing so the diagnosis matches reality and so the customer's expectation is reset. Telling the customer "this didn't actually break yesterday, it's been building" is part of the fix.

Re-test under the condition that the timeline implies. A seasonal first-run fault must be confirmed under that seasonal load, not at rest.

Next steps

Once the phrase is translated to a real fault class (event-triggered, intermittent, gradual, or seasonal), move into the matching isolation tree. Record both the customer's words and your translation on the work order, so a callback inherits the corrected timeline rather than the raw phrase.

If the timeline cannot be pinned down at all, treat onset as unknown and diagnose from the confirmed symptom forward; do not let an unverified "yesterday" narrow your search prematurely.

References

• ISO 13379-1 (Condition monitoring and diagnostics of machines; onset and failure-progression analysis).
• ISO/IEC/IEEE 24765 (vocabulary; failure, fault, and degradation definitions).
• ACCA service and diagnostic best-practice guidance (customer intake and symptom translation).
• ASHRAE Handbook (HVAC Applications; seasonal first-run fault diagnosis).