The Repeat Issue That Nobody Flagged
Severity B call, HVAC unit, same customer, third time in four months. The first call was logged somewhere. The second call was logged somewhere else, or maybe in the same system but under a different technician's login. Nobody flagged it as a repeat because nobody looked back before dispatching the third tech. The third tech shows up without knowing there is a pattern, without the relevant history, and without the parts most likely to be the actual root cause.
This is the structural failure that the Repeat Issue boolean and the Severity classification together prevent. They only prevent it if both fields are filled in at time of logging — not after, not by the office admin reconstructing from memory, but by the tech in the field before leaving the site.
What Severity Levels Actually Distinguish
The four severity levels — A, B, C, and S — represent a classification system that varies by company and sector but typically follows a descending urgency pattern. S is special or safety-critical. A is highest urgency. B and C are stepped-down priorities. The specific definitions do not matter as much as the consistency: every call classified by the same tech using the same standard creates a queryable dataset.
Filtering for all Severity S and A calls in the last 60 days gives you the picture of your highest-urgency service load — which is the number that tells you whether you are understaffed for the volume of critical calls coming in, or whether your dispatching is working efficiently. Filtering for Severity A calls that also have Repeat Issue flagged is the subset that identifies your systemic failures: equipment that is failing repeatedly at the critical level is a maintenance contract problem, a product quality problem, or an installation problem, and it needs escalation before the next call.
Severity as a multichoice field rather than a single choice is the unusual design decision here. A call could in theory span multiple severity levels if a single visit addressed both a safety finding and a routine maintenance item — the multichoice accommodates that edge case without requiring a second record for the same dispatch.
Reported Issue vs Service Call Description
The distinction between Reported Issue and Service Call Description is the difference between what the customer said and what you actually found. Reported Issue is "the unit is making a noise." Service Call Description is "compressor start capacitor failed, causing hard start cycling and the associated mechanical noise at startup." Those are related but not the same, and both need to be in the record.
The divergence between what was reported and what was found is where patterns live. If fifteen Reported Issue entries say "unit not cooling" but the Service Call Descriptions sort into five different root causes — low refrigerant, blocked condenser, failed expansion valve, oversized unit for the space, incorrect thermostat wiring — then "unit not cooling" is not diagnostic information and your customer-facing problem statement needs refinement. You can only see that pattern if both fields are populated consistently.
The Notes field hint text — "Be sure to include Time in/Time Out" — is the field instruction that keeps the record from losing the billable-hours data that the previous version of this template tracked with dedicated time fields. Writing time in and time out in free text is less structured, but it means the on-site time survives in the record even without a dedicated time field.
Eight photo slots per call versus six is the margin for complex multi-system calls where the documentation needs to cover more than one piece of equipment, more than one access point, or a sequence of fault progression images that tells the diagnosis story visually.