What We Built in a Homebuilder's Back Office
A look inside a short onsite engagement with a residential homebuilder: the QBO connection, warranty workbook, permit work, and the pieces we left alone.
I spent a couple of days in a residential homebuilder's office, sitting with the people who handle the work that rarely makes it onto a jobsite photo: invoices, warranty notes, paper walkthrough sheets, plans, email, and permit forms.
The brief was practical. Watch how the work actually moved, find the parts that were worth improving, and build only what the team could keep using themselves.
Some jobs were ready for a usable system. Others needed access, cleaner data, or more testing first. By the end, we had a clear view of what was live, what still needed work, and where a person needed to stay in the loop.
We tracked status before talking about results
We kept the status list simple: identified, scoping, in progress, live, verified, or parked.
A demo was not live. And live was not the same as verified. Staff needed to use a workflow in real work before we called it dependable. Anything touching money, permits, customers, contracts, or safety still had a person responsible for the final call.
The Government of Canada's generative AI guide is written for public institutions, but its accountability point applies in a private office too: the organization remains responsible for the output it uses.
Prairie AI's AI Automation service is built around this kind of work. Start with the existing record and handoff, remove repetitive steps, and leave the final decision with the person who owns it.
The finance connection made controlled QBO workflows possible
The finance process was already in decent shape. The friction was between invoice material, QuickBooks Online, and a separate reporting workbook.
The connector on hand did not support the QBO setup we needed, so we built a local integration with Intuit's open-source QuickBooks Online MCP server.
The connection was tested carefully before it was used for real work. Delete actions were disabled, and any workflow that could change a financial record kept a human approval step.
It gave the finance team a controlled way to bring QBO information into an assisted workflow for review, preparation, and reporting. We did not put a time-saved number on it. It needed to run through more real finance work first.
The warranty work put scattered records into one reviewable place
Warranty administration had a different problem. The information was there, but it was scattered across a warranty system, a shared spreadsheet, handwritten walkthrough sheets, messages, email, and older records.
The usual export did not have enough detail for the daily task. The better route was to export the record for each home and put the useful details into one workbook with three views:
- service requests
- a per-home tracker with possession and walkthrough status
- a lookup view for finding one home's record
We also tested a photographed walkthrough sheet. It pulled the marked items into the right home's record, then left the result for staff to check before using it.
The workbook was usable, but I did not call it verified yet. The first test surfaced ordinary cleanup work: keep the existing workbook as the source, preserve the formulas, and check that a photo import landed each item in the right place. That is exactly why the review step stayed in the process.
The earlier guide on warranty service records explains the general recordkeeping principle. In this case, the work was about finding an export path that actually supported the office, creating one reviewable record, and keeping the coverage decision with a person.
One of the most useful patterns was already owned by the team
One of the most useful things I saw had already been built by the team.
A project team member had already taught an assistant how to prepare a repeatable permit-plan markup from a simple reference example. The early versions needed correction. Repeated examples and direct feedback made the remaining corrections smaller, and the staff member still inspected and submitted the final plan.
The person doing the work had built the pattern and knew how to judge the output. I helped document where it was working and what the next step should be.
The workflow-by-demonstration guide covers why this approach works. The person who knows the task can often teach a stable example faster than they can write a long procedure.
The browser permit workflow stayed in progress
We also explored a browser workflow for a repetitive permit application. It could gather details from internal records, apply learned defaults, and fill most of a web form. It stopped before the final agreement and submission, which stayed with a staff member.
The test showed that much of the workflow was possible, but it was not reliable enough to call live. The portal was inconsistent, the run depended on a specific computer being available, and the trigger did not arrive in a dependable place.
That last point mattered. A workflow cannot act on an input it never receives. Moving or standardizing the trigger was as important as the browser steps themselves.
We left several jobs unfinished on purpose
We also found a few good ideas that were not ready to build:
- automatic invoice naming and filing
- month-end reporting support
- filing signed quotes and patterned vendor email into the right job folder
- assembling warranty booking material from existing records
- moving job templates into a replacement project-management system
Some needed administrator approval. Some needed a reliable export before we could judge the data. Others belonged in a later round.
We also left the live construction schedule alone. There were too many trade and timing dependencies for a short engagement, and the project team did not want an assistant writing to that schedule. I agreed. A convincing demo is not worth creating a system someone has to babysit inside a schedule that affects real work every day.
What changed in the office
By the end, the finance team had a controlled QBO connection for assisted workflows. The warranty work had one workbook and a repeatable way to bring paper notes into it. The project team had a plan-markup pattern that was already working. The permit workflow had a clear review stop and a clear list of blockers.
Each working pattern had an owner. The people closest to the work could explain the source record, inspect the output, and decide what happened next.
Nobody needed a promise that AI would run the company. They needed a few smaller systems tied to real work, and a better sense of what to leave alone for now.
That is the standard I would use for another office: inspect the actual task, build the smallest useful handoff, name the owner, and separate live work from projected value.
If your administrative work still jumps between inboxes, PDFs, spreadsheets, and portals, read about Prairie AI's AI Automation service. Bring one workflow that repeats every week and the records it depends on. We can tell you whether the next step is a build, a process cleanup, or leaving it alone.