What came before
One rebate meant rebuilding the same job across two systems and a printer.
The office began in Housecall Pro, opened the completed job, and copied the customer name, address, phone number, and equipment details into a separate union rebate portal. The employee had to interpret the line items, select the correct rebate program, and enter the counts and customer information field by field.
After submitting the portal form, she printed the rebate. Then she returned to the Housecall Pro invoice, found the version with the customer signature, changed the print scale, reinserted the paper in the correct orientation, and printed the signed invoice onto the reverse. The final form still needed physical signatures and mailing.
Each step was understandable on its own. Together they created a recurring office process that depended on retyping, remembering rules, switching systems, and getting an unusual print sequence right.
The new workflow
The operator starts with the job and reviews the result.
The secure company portal asks for one Housecall Pro job number. It retrieves the customer record, service address, equipment line items, and invoice details, then presents the prepared rebate information for review. The employee can correct a city, postal code, classification, or other unusual fact before generating anything.
One button then runs the rest of the digital workflow. The software opens the union portal in a cloud browser, enters and submits the rebate, captures the resulting form, opens the signed Housecall Pro invoice, and combines the two into a double-sided PDF ready to print.
The employee still controls the submission. The software removes the repeated assembly around that decision.
What the system decides
Rules handle the repeatable work. Exceptions return to the person who knows the job.
The app identifies equipment-replacement and clean-and-check rebates from the contractor’s Housecall Pro price-book records. Stable service-item identifiers and tested program rules determine which equipment counts belong in the portal. The system does not ask an AI model to invent eligibility or rebate amounts.
Real records are still imperfect. Postal codes can map to more than one city, migrated customer data can be wrong, and a technician may leave without capturing a signature. Those conditions are visible to the operator or handled according to a documented company decision instead of being silently guessed away.
Why custom work was warranted
The valuable products stay. The company-specific work between them changes.
Housecall Pro remains the operating record for the HVAC business. The union portal remains the required filing destination. Botworks did not recreate either product.
The custom software handles the work specific to this contractor: reading its job and price-book data, applying its rebate workflow, operating an older portal with no practical integration, retrieving the signed invoice from the Housecall Pro web application, and composing the exact document the office must mail.
What makes it production software
A working automation needs more than a successful demonstration.
The application has restricted sign-in, a run history, saved PDFs, visible error states, operator corrections, health checks, deployment procedures, and in-product documentation. Real failures, including city-name drift and wrong-customer rendering risk, became explicit safeguards and tests.
Botworks operates and maintains the system while engaged. The contractor controls its company data and the path to the application, but reliable use still requires a named operator and ongoing maintenance when Housecall Pro or the union portal changes.
Boundary
The application is in production for this contractor’s residential Union 265 equipment-replacement and clean-and-check rebates. Printing, physical signatures, and mailing remain manual because the union requires them. Manufacturer rebates, utility rebates, commercial work, and other unions are not part of this system.