Why checklists belong on the equipment, not the work order.

This is the default state of checklists in most field service software. The checklist is a form template. It lives in a settings panel somewhere. Dispatch — or the tech — has to remember to attach the right one to each job. Or the shop just has one generic checklist for everything and accepts that it's wrong half the time.

We took a different approach: the checklist belongs to the equipment, not to the job. Once you tell TuffOps which checklist applies to a piece of equipment (or to a class of equipment), the right items show up on the right work orders — automatically, every time, filtered by what kind of work is being done.

Attach to the asset, not the appointment

In TuffOps, a checklist template can be attached to:

• A specific Unit — the actual condenser at 410 Main St, the rooftop on Building C. Useful when one piece of equipment has its own quirks or its own customer-mandated procedure.
• A Device Model — every Carrier 24ANB6, every walk-in cooler with a Copeland scroll, every refrigeration rack of a particular configuration. Set the checklist once at the model level; it's applied wherever that model lives in your customer base.

That's the configuration step. From then on, you don't think about it.

How it flows onto a work order

When a work order is created against a unit, TuffOps does this automatically:

1. Find the checklists attached to this specific unit that apply to this work-order type. Attach all matching ones.
2. If no unit-specific checklists matched, fall back to the checklists attached to the device model (filtered by work-order type).
3. For every item in every attached checklist, snapshot it onto the work order — name, required-flag, result type, and all.

The tech opens the work order; the checklist is already there, already scoped to the equipment, already scoped to the kind of work they're doing. Dispatch didn't have to remember anything. The tech didn't have to dig through a template library.

Type-aware: maintenance vs. install vs. repair

Same unit, same equipment, completely different procedures depending on why you're there. A startup commissioning is not a quarterly PM. A no-cool diagnostic isn't a refrigerant retrofit.

Each TuffOps checklist template flags which work-order types it applies to. The five types are installation, repair, maintenance, service, and other. A single piece of equipment can have a different checklist for each — the system picks the right one based on the work order's type, with no manual selection.

That means a 7.5-ton split can carry:

• A 12-item commissioning checklist that only attaches to installation work orders
• A 6-item quarterly PM checklist that only attaches to maintenance work orders
• A 4-item triage checklist that only attaches to repair work orders

None of them clutters the others. None of them needs to be added by hand.

The five item types — built for HVAC reality

Every checklist item has a result type — what kind of answer the tech is expected to record. Five options, each rendered as the right input on the tech's phone:

Required items block completion. Period.

If a checklist item is marked required, the tech can't move the work order to waiting approval or completed until that item is filled in. The mobile app marks required items with a red asterisk. Required photo items show "(required before complete)." If the tech tries to complete the WO with required items open, the API rejects the transition with a clear count: "Cannot complete work order: 3 required checklist items must be completed first."

This is a real block, not a soft warning. It exists because the most expensive thing in a service operation isn't a missed checklist item — it's a tech who marks a job complete, drives away, and the office discovers two weeks later that no one logged the refrigerant readings.

Optional items get a softer treatment. If any are still open at completion time, the tech is asked to confirm: "You have 2 optional items still open. Continue anyway?" Tap continue, the WO completes. Tap cancel, you go back and fill them in.

Want to see it on a real phone? Book a 30-minute demo and we'll walk through configuring a checklist on a device model, watching it auto-attach to a new work order, and triggering the required-item block from the mobile app.

Supervisor override — permissioned, audit-logged

Real life happens. A tech finishes a job at 7 p.m., the customer is locked out and can't get a final reading, the required item can't be completed today. You want a way to close the work order without erasing the requirement.

In TuffOps, two distinct override permissions exist on the office side:

• checklists.bypass_required_items — the holder can complete a work order even when required items are still open. The bypass is recorded against the user.
• checklists.override_frequency — the holder can complete an item before its frequency window has reopened (e.g., re-do a quarterly item early if the equipment failed and was fixed under warranty).

Every checklist completion, un-completion, or override is written to checklist_item_audit_logs with the user, timestamp, IP, user-agent, and old-vs-new values. There is always a record of who did what and when. If the auditor asks, the answer is one query away — not a search through a tech's text messages.

For shops in our refrigerant-compliance program, items flagged as regulatory refrigerant get a third tier: a separate compliance permission, a mandatory written reason of at least 5 characters, and a permanent ComplianceOverride record that ties back to the EPA leak-rate calculations downstream.

Snapshot semantics: yesterday's job stays yesterday's job

This is the part that turns out to matter the most for shops doing any kind of compliance or warranty work, and it's invisible until the moment it isn't.

When a checklist auto-attaches to a work order, TuffOps doesn't just link a reference back to the template. It copies every item onto the work order as a snapshot — the name, the required-flag, the result type, all of it. That snapshot is what the tech sees, what they fill in, and what becomes the permanent record of the job.

So when you edit the checklist template tomorrow — rename an item, add a new field, change something from optional to required — only future work orders see the change. Yesterday's completed job still shows the checklist exactly as it was on the day the tech filled it in.

Most field service tools don't do this. Edit the template, and historical jobs retroactively show the new version, sometimes with phantom blank fields where the tech "didn't fill in" something that didn't exist when they were on site. That's a recipe for a bad day in court, in front of an auditor, or in a warranty dispute.

Frequency gating — the quiet PM productivity feature

Real PM checklists have items that are appropriate annually, not monthly. Coil cleaning, refrigerant leak inspection, contactor replacement, condensate-line treatment — each on its own cadence.

Each item in TuffOps can carry a max_required_frequency_in_days value. If the same checklist runs against the same unit before that interval reopens, the item is auto-marked not-required for that visit — the tech still sees it as informational, but it doesn't gate completion. Set the coil-cleaning item to 365 days, and your monthly PM techs see it once a year, not twelve times.

The frequency clock resets the moment the item is completed. If a tech overrides the gate and re-does the item early, the override is logged and the clock restarts.

What this gets you, day-to-day

Why most field service software doesn't work this way

Most general-trades field service platforms grew up serving plumbing, electrical, lawn care, pest control, and handyman work — categories where "the equipment" isn't a stable, repeatedly-serviced asset with its own model number and history. A plumber doesn't service the same toilet quarterly; a lawn-care tech doesn't return to the same mower next month.

Their data model reflects that: a checklist is a generic form, attached to a job type or a service category. There's no concept of "this checklist belongs to this piece of equipment, and follows it across visits over years."

HVAC is different. The equipment is the relationship. The same condenser is going to be visited twice a year for the next ten years, by different techs, under different work-order types, possibly by your shop and possibly by the next contractor the customer hires. The procedure-of-record needs to live where the equipment lives, not where the next appointment lives.

Once you've made that shift, everything downstream gets easier — auto-attach, type filtering, snapshot integrity, frequency gating, regulatory items. None of those are exotic features in isolation. They're what falls out of binding the checklist to the right thing in the first place.

Available where

Checklists are part of the core TuffOps product. The EPA refrigerant integration — required-by-law fields tied to the Comply module's leak-rate calculations and Section 608 / Part 84 reporting — is included on Pro and Enterprise, and available as an add-on for Starter. See pricing.

The bottom line

Checklists are not a feature you should have to think about every time you cut a work order. The right checklist should be on the right job, automatically, every time — filtered by what kind of work is being done, snapshotted into the historical record, gated where it matters, overridable where it has to be, and audited when it is.

That's how we built ours. It's the same idea behind linked equipment groups and the customer-facing QR scan-to-request flow: the equipment is the durable thing in HVAC. Build the workflows around it, not around the appointment.

← Back to all posts