AI for a Chimney Sweep Business: Inspections and Reminders

An AI agent for a chimney sweep business keeps one inspection history per property, drafts annual service reminders from the date of the last completed visit, and holds technician notes in a fixed structure so the record stays consistent when different people work on it. The agent handles the bookkeeping and the follow-up. A named person still decides what a finding means for safety and approves any change to a service status.

Key takeaways

• Build the inspection history first. Every reminder and note depends on one accurate record per property and appliance.
• Generate reminders from the last completed visit and its open findings, never from a booking date or someone's memory.
• Give technician notes a fixed structure so observations, actions and recommendations can be compared across years.
• Keep safety judgments and status changes with a human approver, and limit the agent to drafting and proposing.
• Judge success with checks: each due reminder either goes out with the correct appliance, date and history, or it does not.

Why records drift across visits

Most chimney sweep businesses keep their knowledge in several places at once: invoices, a scheduling calendar, notes written in the van, photos on a technician's phone, and the memory of whoever did the last job. This works while the same two people run the same route. It stops working when a new technician takes over a district, when a property changes owners, or when a recommendation made at one visit never reaches the homeowner. Small differences then accumulate. An address is spelled two ways, a stove is recorded as an insert in one system, and a note saying the flue should be camera inspected before the next heating season exists only in a photo.

Illustrative scenario: On a return visit, a technician records heavy deposits in a flue and writes a recommendation in the van. Two years later, another technician books a routine sweep using only the last invoice, which shows a standard cleaning. The recommendation is never raised with the customer. Nobody made a bad decision in this sequence. The record simply did not carry the decision forward.

Recurring-service businesses face the same pattern. The route is the easy part, while the history of each property is where errors tend to hide, as discussed in AI for a Landscaping Business.

What the inspection history must hold

A usable history depends less on volume than on completeness. For each property, the record should include:

• Property identity: the service address, access details, the owner or manager contact, and a log of changes to those details
• Appliances: each fireplace, stove, insert or connected heater, with type and make recorded as observed on site
• Visit entries: date, technician, work performed and the condition checked at each point
• Findings: each finding with a severity label the business defines in advance, a reference to any photo, and whether the customer was told
• Open recommendations: what was advised, when, and whether it was accepted, declined, deferred or completed
• Reminder state: the next due date and the visit that produced it

The agent's job is to keep these fields complete and consistent, flag gaps, and show where each value came from. It should not infer a condition that nobody observed. A field filled from an old invoice should be marked as imported, not as verified.

Annual reminders that depend on the last visit

A reminder is only as good as the date behind it. The due date should be calculated from the last completed visit for that specific appliance, using the interval your business and local requirements call for. A canceled booking should not move the schedule. An open recommendation should stay visible on the property, so the reminder can say what is outstanding instead of only announcing that service is due. Recurring property records follow similar logic, as shown in AI Agents for Property Management.

Good reminders name the appliance, the last completed visit and any open item. The agent drafts them, and staff review them in batches before sending, at least until the review shows they are consistently right. Reminders should stop automatically when a property is marked as sold, transferred or no longer served, so the business does not write to the wrong person.

A reminder that cannot name its last visit should not be sent until someone checks it.

Technician notes with a fixed structure

Free text is where most accuracy problems begin. Use a short template for every visit with five parts: what was observed, what check or measurement was performed, what action was taken, what is recommended, and how the customer responded. Each recommendation carries a status that changes only through a new entry.

Before a visit, the agent can summarize prior entries for that property so the technician arrives with context. Keep each summary short and specific, since agents work best when they receive only the context a task needs, and link every summary back to its original entries. Corrections are appended, never overwritten, so the history shows what was known at each point. That matters when a customer disputes a recommendation, when a new technician takes over, and when an owner reviews the work.

Technicians should not need to write essays. A brief note that follows the structure is more useful than a long one that does not. The structure is what allows an agent to compare this year's notes with last year's without guessing.

A checklist for the first rollout

Start with one service area and a set of properties whose records are already reasonably complete. Then work through these steps:

• Agree the visit template and severity labels with the technicians who will use them
• Choose the system of record for scheduling and for invoicing, and decide which one wins when they disagree
• Import existing histories and mark each imported field as unverified until a technician confirms it
• Give the agent read access to histories, and write access only to draft reminders and proposed schedule changes
• Set the approval rule: a named staff member approves every safety-related recommendation and every change to a service status
• Each week, compare a sample of records with the original visit sheets and log every mismatch with its cause
• Expand to the next service area only after mismatches are rare and the team trusts the summaries

Permissions, approvals and where the agent stops

Limit what the agent can touch. Least privilege is the standard principle: each tool and data source should grant only the access the role needs. The OWASP authorization guidance describes this idea in general terms, and it applies directly here. An agent that drafts reminders does not need permission to close a finding or to send a message stating that an appliance is safe to use.

Treat any text the agent reads as data, not as instructions. A customer message, a forwarded email or a note from a third party might contain sentences that try to change what the agent does. Route those inputs through the same checks as any other input, and log what the agent read and wrote. For a structured way to decide which risks to monitor and who owns each one, the NIST AI Risk Management Framework is a practical reference.

Be Human runs this kind of setup as a managed service. The first engagement defines one role, such as the records and reminders agent for one service area, along with the history it must hold, the tools it can call, the approval boundaries and a stated success criterion, for example that every reminder sent carries the correct appliance and last-visit date. Managed operations then cover monitoring of reminder runs, recurring evaluations against sample records, permission reviews as staff and tools change, and controlled updates to templates. The work is remote and available in English or Portuguese.

Measuring whether the records stay accurate

Accuracy needs measures you can check. Useful ones are simple: how many due reminders went out on the scheduled day, how many carried the correct appliance and last-visit date, how many open recommendations are older than the owner expects, and how many corrections were appended after a visit. Review them on a fixed schedule and keep the sample small enough that one person can check it in under an hour.

If a measure drifts, find the cause before changing the agent. It may be a template that technicians fill in inconsistently, an import that mapped a field to the wrong place, or a scheduling rule that nobody updated after the season changed. Record each change in the process log so the next reviewer knows what was tried. Set the first review date before the rollout begins, and make sure the owner knows which records are trusted, which are still being verified and who signs off. If you want to find the first task worth handing to an agent in your sweep business, take the free Be Human AI diagnostic.

Frequently asked questions

Do we need to replace our scheduling software to use an agent? No, not at the start. The agent can read from the tools you already use and write only to drafts and proposals. Replacing a system is a separate decision that depends on whether the current one holds the records you need.

Who has the final say when a technician and the agent's summary disagree? The technician's signed visit entry prevails, and the summary is corrected to match it. Corrections are appended, so the history shows both the original summary and the fix. Any disagreement that touches a safety finding goes to a staff member for review.

Can the agent decide whether a chimney or appliance is safe to use? No. Safety judgments belong to qualified technicians and to the rules that apply where you operate. The agent can surface the open finding, the date it was recorded and who has not yet been notified, so a person can act.

Where should a business with paper records begin? Start with the visit template and a small set of properties. Transcribe the most recent visits first, mark every imported field as unverified, and confirm the fields that drive reminders before expanding. A clean recent history is more useful than a large, incomplete archive.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.