One Operating Backbone From Quote to Invoice for a Fire Protection Contractor

#The starting position

The contractor installs and certifies passive fire protection on commercial construction projects. Its work is high in compliance and low in tolerance for error: every penetration sealed, every product used and every inspection has to be evidenced, because a building cannot be signed off without it.

Before this engagement, that work ran across five tools. Sales lived in Salesforce, but only as a list of opportunities. Jobs were tracked in spreadsheets. Technicians clocked hours in QuickBooks Time. Site forms, photos and compliance records sat in Dashpivot. Invoices were raised in Xero. None of them shared a job number anyone trusted, so the office spent its week copying details from one system to the next, and every copy was a chance to get a site address, a scope line or a billable hour wrong.

The cost showed up in three places. Quotes went out with inconsistent terms. Jobs started without a complete set of work orders, so tasks were discovered on site. And invoicing waited on someone matching timesheets and site records by hand, which slowed cash collection on every project.

The business was also growing. More projects meant more crews, more subcontractors and more documents per week, and the manual hand-offs that were tolerable at a smaller size were becoming the limit on how much work the office could take on.

The brief was clear: one operating backbone for sales, field jobs, documentation, time and accounting, without forcing crews off the tools that work in the field.

#What we built

01 Sales Cloud as the commercial front end

We rebuilt the sales process on Sales Cloud for the way the contractor actually wins work: leads from builders and head contractors, opportunities by project, and quotes that carry the company's standard terms. Quote terms were added as a delivered enhancement, so every proposal now goes out with the same conditions, which matters when a variation or a dispute arrives months later.

02 Jobs, purchase orders and work orders

A won opportunity becomes a job. We modelled purchase orders against the job, and parent and child work orders underneath it, with custom automation creating the child work orders from the parent. A typical project has the same set of tasks every time, so the system now creates them instead of relying on someone to remember them.

03 Scheduling synced two-way with QuickBooks Time

Appointments are scheduled in Salesforce and pushed to QuickBooks Time, where technicians already clock on and off. We deployed the production scheduler and built a two-way integration, so hours worked return to the right work order without anyone keying them in. The office sees planned against actual on the job record.

04 Dashpivot site folders and pre-filled forms

Dashpivot was delivered in two phases. Phase 1 creates the site and work order folders from Salesforce and writes the document links back to the job. Phase 2 added document workflows and pre-fill, so forms open on site with the job details already in place. Crews spend their time on the work, and the compliance record is complete when they leave.

05 Xero invoicing with the file on the record

When a job is ready to bill, Salesforce raises the invoice in Xero and attaches the invoice file back to the record. Finance, operations and sales now look at the same job and the same invoice, and nobody has to search a mailbox to answer a builder's billing question.

06 Operational alerts

We also scoped the Slack requirements for operational workflows, so the right people hear about job events without watching a report.

#How we delivered it, end to end

One project, traced end to end. The design started from the path a real job takes, from quote to invoice, and every hand-off between systems on that path became an item on the integration backlog.

Data model before integrations. Job, purchase order, work order and appointment were settled first, because every integration reads from or writes to them. With that model agreed, each integration had a clear owner record and a clear direction of travel.

Integrations in custom Apex REST. The rules were specific to this business, such as which hours belong to which work order and which forms are pre-filled for which job, so the logic sits inside Salesforce, next to the records it governs, and is tested with the rest of the org.

Delivered in phases. Sales Cloud and the job model came first, then the QuickBooks Time scheduler went into production, then Dashpivot in two phases, then Xero. Each phase stood on its own, so the business was using the new process while the next piece was built.

Support and enhancements after go-live. The contractor stays on ongoing support. Quote terms, Dashpivot pre-fill and child work order automation were delivered as later enhancements through that relationship.

#The decisions that mattered

Keeping the field tools. It would have been tidier on a whiteboard to move everything into Salesforce. In practice, technicians already used QuickBooks Time and Dashpivot well. We made Salesforce the system of record and let the field tools stay the system of entry, which is why adoption was not a fight.

Custom code over middleware. A middleware platform would have added licence cost and another place to debug. For this volume and this rule set, well-tested Apex REST was the cheaper and more transparent option, and it can move to middleware later if volumes grow.

Automating the boring, repeatable parts first. Child work orders and form pre-fill are not glamorous. They removed the most frequent errors, and that earned the trust needed for the bigger integrations.

#Beyond the CRM: a technical library for estimators

The relationship grew past Salesforce. Alongside the CRM work, we built a separate web application for the contractor, a fire protection estimator and technical library on Next.js. Estimators and technicians look up approved systems and products, filter by manufacturer, and produce PDFs to support a quote or an inspection.

The application has authenticated access for three roles, users, technicians and administrators, with subscription pages for external users. It sits outside Salesforce on purpose: the library is a product in its own right, used by people who will never hold a Salesforce licence, and it needed a public-facing experience a CRM page cannot give.

AI identification of fire stopping products and MCP-based workflows are in development on top of the library. They are not live yet, and we describe them here only to show where the platform is heading: the same discipline of one source of truth, now applied to the technical knowledge behind every quote.

#What changed

The point of the design is simple: with one record per job, the office stops reconciling systems and starts managing the work.

#What we would tell a contractor starting this

Most contractors we speak to already own the right tools. What they lack is a single place where a job is defined, so each tool holds a slightly different version of it.

Start with the job. Agree what a job is, what belongs under it and which system owns each piece of it, before anyone builds an integration. Keep the tools your crews already use well, and make them read from and write back to the job. Then automate the repeatable tasks first, because that is where errors hide and where trust is earned.