Powstania Warszawskiego 15
31-539 Kraków
For most HVAC contractors, maintenance agreements are the steadiest revenue in the business and the part software handles worst. The agreement is sold in the office, the visits happen on a roof, and whether a repair is covered gets decided at the invoice. This is how the software has to carry one agreement through all of that.
HVAC service agreement software has to treat the agreement as a record of its own, linked to a customer, their sites and the specific equipment covered. From that record it schedules the included visits, shows the technician on site what is covered for this unit even without signal, applies the coverage rules when the visit is invoiced, and tracks renewal. Most problems come from agreements stored as notes on a customer, which forces technicians and the office to decide coverage by memory.
Many field service tools store a maintenance agreement as a flag or a note on the customer: "has a plan". That is enough to send a reminder and not much else. A real agreement is more specific. It covers named units at named addresses, includes a set number of visits, and changes what the customer pays for parts and labour.
When the software does not know which unit is covered, the technician on the roof has to guess or call the office, and the office has to reconstruct the answer at billing. Both are slow, and both end with covered work billed or uncovered work given away.
This is the minimum record that lets the rest of the system make decisions without asking a person.
The equipment line is the one most often missing, and it is the one everything else depends on. The wider case for treating the unit as the central record is made in what a field service app has to capture in version one.
An agreement passes through five moments. Each one needs something specific from the software.
Whoever sells it records which units and sites it covers, not just the customer name. If equipment is not yet in the system, the first visit is where it gets recorded properly.
Where it breaksAn agreement sold to "the Smith house" when there are three units and one of them is excluded.The software generates the visits the agreement includes and puts them in front of the dispatcher in the right season, so they are booked before the busy weeks rather than squeezed between emergencies.
Where it breaksMaintenance visits that exist only as a reminder, and get pushed back until the season has passed.On arrival, the app shows what the agreement covers for this specific unit, its history and what was found last time. This works without signal, because mechanical rooms and roofs often have none.
Where it breaksA technician who calls the office to ask whether a part is covered, or decides from memory.When the job is closed, parts and labour are priced according to the agreement automatically, and anything outside it is marked as billable before the invoice leaves.
Where it breaksSomeone in the office applying discounts by hand from a spreadsheet, days after the visit.Before the term ends, the office sees which visits happened, what was found and what the customer saved, which is the conversation that renews an agreement.
Where it breaksAn expiry date that goes unnoticed until the customer has already left.Coverage decided from memory is where agreement revenue leaks, one small discount at a time.
The on site moment deserves its own attention, because it is where the decision is made. The technician needs three things on one screen: whether this unit is covered, what the agreement includes, and what happened on previous visits. Anything that requires a phone call turns a ten minute decision into a half hour one.
In our field projects, crews regularly work in basements, plant rooms and similar places without signal, so the job and its history have to be on the phone before the technician arrives. Photos from the visit go into their own upload queue, separate from the form data, so a weak connection never holds back the closed job.
The technician side we built for electrical contractors in TimeFix follows the same logic: the job on site, with everything needed to finish and sign it off before leaving.
One requirement there only appeared in real use, a work timer that had to keep running when the screen was locked or a call was placed from inside the app. HVAC apps meet the same kind of surprises once real technicians use them.
Residential agreements usually cover one or two units at one address. Commercial ones can cover dozens of units across several buildings, with different visit frequencies per unit type, a customer contact per site and a report the facilities manager expects after every visit.
The data model above holds, but it has to be designed for that scale from the start. Retrofitting multiple sites and per unit schedules onto a model built for one house is one of the more expensive changes a field app can face.
If your agreements are simple, the same plan for every customer, one or two units, no commercial accounts, a standard field service platform will handle them and cost less.
Custom software pays off when agreement terms vary between customers, when coverage has to be decided per unit, when commercial accounts carry many sites, or when agreement data has to live in the system that already runs your business. The signals are listed in when you outgrow field service software.
Customer self service, online payment of agreements and deep accounting integration can follow. How we scope and build these systems is on our custom HVAC software development page, and the broader picture is under field service app development.
Software that stores maintenance agreements as records linked to customers, sites and covered equipment, schedules the included visits, shows coverage to technicians on site and applies the agreement's rules when the job is invoiced.
Because agreements usually cover specific units. Tying coverage to the customer forces someone to decide which unit is covered by memory, which is where mistakes and lost revenue come from.
Yes, if the app loads the day's jobs, agreements and unit history onto the phone before the technician goes on site. The closed job and photos sync when coverage returns.
They cover many units across several sites, often with different visit frequencies per unit type and a report for the facilities manager after every visit. The data model has to support that from the start.
If every customer has the same simple plan, an existing platform is usually enough. Custom makes sense when terms vary, coverage is decided per unit, or commercial accounts carry many sites.
A narrow first version around agreements, visits and the technician app typically takes 10 to 14 weeks. A full system with dispatch, offline reporting and an integration takes 14 to 22 weeks.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Walk us through how you sell, schedule and bill maintenance agreements today. We will tell you what the first version of your HVAC software should handle, and what can wait.
30 minutes, no preparation needed.