A chimney business runs two kinds of work through one system: field service that gets scheduled, dispatched and invoiced, and inspection work that produces a documented record someone may read years later. This page sets out what software needs to hold for that combination, and what to test before committing to a product.
It is a requirements guide, not a product ranking. The evidence-backed product pages for this trade are linked at the end, under where to go next.
- Written for
- Chimney sweep, chimney inspection and fireplace service businesses, from owner-operator to roughly twenty staff, where the owner is often still in the field.
- Market
- United States and Canada. Terminology, credentials and code adoption differ by jurisdiction, and this page names the jurisdiction wherever it refers to them.
- Not covered here
- Product rankings, prices and plan comparisons; inspection procedure, code interpretation and safety guidance; hearth retail and appliance sales workflows.
Quick decision summary
The decision is driven by which part of the work is failing, not by headcount. A solo operator whose reports are inconsistent has a different problem from a four-truck company losing findings between seasons, and the two buy differently.
Who this guide is for
The operating model matters more than the size of the team. A sweep who inspects and documents on each visit has a different software problem from a company that sweeps and refers repairs out.
- Sweep and inspect, residential. The visit is scheduled, performed and invoiced inside a day, and the durable output is a short report with media attached to the correct flue. The pressure sits on speed in the field and on finding last season’s record before the truck arrives.
- Inspection-heavy work, including real-estate transactions. The report is the product. Templates, required fields, media quality, delivery and acknowledgment matter more than dispatch, and the report may be read by a party who was not present at the visit.
- Repair and masonry. Findings turn into priced scopes, materials and multi-day work. The chain from finding to estimate to approved work to completion documentation carries the revenue, and open recommendations behave like a pipeline that needs to be listable.
- Multi-technician seasonal operation. Capacity, dispatch and consistency between technicians dominate. Two technicians should produce comparable reports, and the schedule should survive a lost day in the busiest month.
Use this guide if you are choosing or replacing the system that holds customers, properties, inspections and follow-up. Use a different resource if you are researching inspection procedure, code requirements or certification: this page covers business software and points you at the authorities for the rest.
The property and system history that must survive between visits
For a chimney business the durable record is more than the customer. It is the history attached to the property and to the venting systems inside it, and it needs to be findable by the technician standing in front of them.
A customer may hold several properties. A property may contain one or more chimney or venting systems, appliances, flues, liners, caps, crowns and related components. How those parts relate varies by installation, and the vocabulary used to describe them varies with it, so there is no single hierarchy that fits each building. What the software needs to provide is traceability: a technician can tell which system a finding belongs to, and can retrieve that finding later. Some products hold the history on the property, some on an asset or equipment record, some on the inspection or the job. Any of those can work if the relationships survive the year between visits.
Two things make traceability real rather than nominal. The first is a stable label or identifier for each system that a technician recognises in the field, so a photo of a cracked crown lands on the system it came from rather than on the customer file. The second is that the label survives edits: renaming or replacing a component should not orphan the records taken before the change.
- Customer
- Property
- Chimney or venting system
- Service event
- Inspection record
- Finding
- Recommendation
- Estimate
- Approved work
- Completion documentation
- Report delivery
- Future reminder
| Step | Record that must persist | Failure to test for |
|---|---|---|
| Customer and property | The customer, each property they own or manage, its address and access notes, and which properties are currently theirs. | A second property is entered as a second customer, splitting the history in two. |
| Chimney or venting system | Each system at the property under a stable label, with its components and any replacements. | A finding or a photo attaches to the property with no system named, or lands on the wrong system. |
| Service event | What was performed, by whom, on what date, against which system. | The visit exists as a calendar entry and leaves no durable service record behind it. |
| Inspection record | The completed report, the template and version it used, its required fields, its media, and the technician who completed it. | The report survives as a flat attachment with nothing searchable or reportable behind it. |
| Finding | The observed condition, the system and component it belongs to, the date, and its media. | Findings sit in free text and cannot be listed across visits or across the customer base. |
| Recommendation | What was recommended, its urgency, its author and date, and its status: open, declined, deferred, superseded or completed, with the date of each change. | A declined recommendation disappears rather than staying on the record with its date. |
| Estimate | The priced scope traced back to the finding it answers, with its version and approval state. | The estimate loses its link to the finding, so nobody can reconstruct what it was for. |
| Approved work | The approved scope, the schedule, the assigned technician, and any change agreed on site. | Approved scope is retyped into the work order and drifts from what the customer accepted. |
| Completion documentation | What was done, parts and materials used, before and after media, and the technician's notes. | The invoice goes out with no record of the work performed attached to the system. |
| Report delivery and acknowledgment | When the report was sent, to whom, and whether the customer acknowledged it, held apart from the source record. | Editing an issued report silently rewrites what the customer already received. |
| Future reminder | The next follow-up date, the rule that set it, the system it applies to, and whether it fired. | The reminder hangs off the customer rather than the system, or assumes a fixed interval nobody chose. |
| Property transfer or replaced component | Prior records stay attached to the property and system while the customer changes; a replacement records the new component and keeps the superseded one. | Changing the customer detaches or deletes the property's history, or a replacement overwrites the record of what was there before. |
Retention belongs in the same conversation. Inspection reports and their media can matter years after the visit, so ask how long records are kept, whether media is kept at the resolution it was captured, and in what form both leave the system if the business moves.
Software approaches for a chimney business
Four approaches are realistic here. None is inherently deeper or better integrated than the others: those are hypotheses to check product by product, with the product in front of you.
| Approach | Best fit | Main compromise | Verify in a demo | Integration or data risk |
|---|---|---|---|---|
| Broad field-service platform | Scheduling, estimating, invoicing and payments across a mixed workload, where inspection reporting can be met with the platform's own assets, custom fields or forms. | Report structure and media handling are generic, and a jurisdiction-specific report format may have to be assembled by hand. | Build a property with two systems, run an inspection, log a declined recommendation, then find that finding a year later by system rather than by scrolling notes. | History held in notes or custom fields can be hard to export in a readable, attributable form. Ask what an export of reports and attachments actually contains. |
| Trade-focused platform | Inspection reporting and system-level history are the daily work, and the product also covers scheduling, estimating and invoicing well enough to avoid a second system. | A trade label is positioning, not proof. Depth varies by product, and the field-service side around the reporting can be thinner than it looks. | Ask which report templates ship for the jurisdictions you serve, who maintains them, and what a template change does to reports already issued. | A smaller vendor concentrates your inspection archive. Ask about export format, media export, and how long records stay reachable after cancellation. |
| Specialist inspection tool beside an existing system | The current platform runs the business and the gap is narrow: report structure, offline capture, media quality, or delivery and acknowledgment. | Two systems to maintain, two places customer data lives, and a handoff that has to stay in step. | Confirm the inspection tool can pull customer, property and system from the platform, or that a job can be raised in both without retyping. | Duplicate customer and property records, and an inspection archive kept apart from the job history it belongs to. |
| Connected stack | A business with an accounting or booking tool it intends to keep, choosing an operations product around it. | The integration defines what carries across. Anything it drops gets re-entered by hand, usually by the person with least time. | Push one customer, property, approved estimate, deposit and completed job through the whole chain and note which fields survive each hop. | Sync failures create duplicates, and a later migration has to reconcile several systems' versions of the same history. |
Three things belong in that comparison and are easy to skip in a demo. Offline capture, because reports get written in basements and on roofs where signal is not guaranteed: ask what happens to a report and its media when the device reconnects. Report format support, because a report produced for a property transaction is a different document from a routine service report, and template coverage differs by jurisdiction. And the exit: data migration and long-term access, because an inspection archive that leaves a platform as an unreadable dump is an archive you no longer have.
Capabilities to verify
Each item below is a behaviour to test, not a feature name to look for on a pricing page. Run them against one of your own properties with two systems on it rather than the vendor’s demo data.
Must have for this operating model
- Can one customer hold several properties, and one property hold several identifiable systems, without collapsing into a single note field?
- Does each system carry a stable label or identifier a technician recognises on site?
- Can a technician open the prior inspection, its findings and its media from a phone before arriving?
- Do a finding, its media, its recommendation and the resulting estimate stay attached to the same system?
- Does a recommendation hold a status of open, declined, deferred, superseded or completed, with the date and the person who set it?
- Can an inspection be completed in the field and reviewed before it is issued to the customer?
- Do photos and videos attach to the finding rather than to the job alone, and do they keep enough resolution to be read later?
- Can a lost day be rescheduled without breaking a visit's link to its property and system?
Important at the next stage of growth
- Are report templates version controlled, with required fields, so two technicians produce comparable reports?
- Can follow-up reminders be configured per service and per system, on the interval the business chooses?
- Can a report be delivered and acknowledged by the customer without altering the source record?
- Can technicians hold different permissions for creating, editing and issuing reports?
- Can open recommendations be reported on by age, value, property and system, so unquoted findings stay visible?
- Can capacity be planned across technicians and days when demand concentrates into a few months?
Useful only for certain services or contracts
- Do report formats exist for the jurisdictions and transaction types the business serves, such as a report produced for a property sale?
- Can a property hold a managing agent or landlord distinct from the occupant who is on site?
- Can a multi-unit or commercial property hold many systems under one account with per-system history?
- Are there records for liners, caps and other components with installation or warranty dates where the business tracks them?
- Can deposits be taken for repair work while inspections are invoiced after the visit?
Verify before switching
- What does an export contain: customer, property, system, findings, recommendations, reports and the media, or a list with the attachments missing?
- In what formats do historical reports leave the system, and are they readable without the vendor's software?
- How long do records and media stay reachable after an account is cancelled?
- How does the import handle existing customers and properties, and what does it do with duplicates?
- Do inspection or media capabilities depend on a higher plan, a paid add-on, or a particular device?
- What happens to a report completed offline when the device reconnects: does it sync intact, or produce a duplicate?
Follow-up intervals are a configuration question rather than a constant. The Chimney Safety Institute of America states that NFPA 211 calls for chimneys, fireplaces and vents to be inspected at least once a year (csia.org, checked September 3, 2026), and that is a United States standard whose adoption and enforcement are decided locally. Appliance type, fuel, usage and the customer’s own agreement also change what a business schedules. What the software needs to do is let the business set the rule, per service and per system, instead of assuming one.
What breaks when the season fills
In markets with a cold heating season, requests for sweeps and inspections concentrate in the months before and during winter. That is editorial reasoning about how demand behaves in those markets, not a measured figure, and it does not describe each market a chimney business serves: gas appliance work, dryer venting and commercial contracts can spread the year out. Where the pattern does hold, a business with a fixed number of technicians fits a large share of the year’s work into a compressed window, and a scheduling setup that copes in a quiet month can fail once the calendar fills.
A visit does not follow one fixed path. A sweep may end with nothing to report. An inspection may produce a finding that needs no work, a recommendation the customer declines, or a repair booked for spring. The test is whether each of those outcomes leaves a durable record attached to the right system, the declined one included, and whether the next technician sees it.
Clear, correctly attached documentation can help the customer understand what was observed and preserves the record for later review. It does not prove a condition or settle a dispute by itself. The reason to attach a photo to a finding is that the finding should still be legible in two years, to a technician who was not there and to a customer who has forgotten the conversation.
Capacity is the other seasonal stress test. Ask how the product shows remaining capacity by technician, day and service type, what it does when a job overruns, and how a cancelled or weather-delayed visit is rebooked without losing its link to the property and system. A product that handles this in a slow month may still be worth rejecting if it hides the constraint in October.
Questions to test in a demo or trial
Take these into the demo and ask for them to be performed rather than described.
- Can one customer hold multiple properties, and can a property hold multiple identifiable systems/components without flattening everything into one note?
- Can a technician reliably open the correct prior record before and during a visit?
- Can findings, media, recommendations, estimates, and completed work be tied to the correct property and system?
- Can the workflow retain declined, deferred, superseded, and completed recommendations with dates and authors?
- Can required report fields and templates be configured for the jurisdictions and services the company actually performs?
- Can a report be completed offline and synchronized without losing media or creating duplicates?
- Can the customer receive and acknowledge the correct report without altering the source record?
- Can future reminders follow the company's configured policy rather than a hardcoded annual assumption?
- Can historical reports and attachments be exported in readable formats if the company leaves the platform?
- What product plan, add-on, or device restrictions apply to inspection and media features?
- Can two technicians produce comparable reports from the same template, and does a template change leave already-issued reports unaltered?
- Can open recommendations be listed across the customer base by age, property and system, so findings are not lost between seasons?
Where to go next
The decision this page supports is complete above: the record model, the four approaches, the checklist and the demo questions are what you take into an evaluation. Two pages on this site carry product facts rather than a trade verdict, and are useful for that purpose alone. The Jobber review records what the product does under our standardized test, and it states that fit for chimney work is unverified. The Jobber pricing guide is a plan and price reference. Neither is evidence that the product suits chimney work.
Research roadmap
Guides we plan to publish once they meet our evidence requirements. None of these is available yet.
- Planned Chimney sweep CRM: How products hold customer, property and system history below the customer record.
- Planned Chimney sweep scheduling and dispatch: Calendars, booking and dispatch behaviour under concentrated seasonal load.
- Planned Chimney sweep estimating: Turning a documented finding into a priced, approvable scope without retyping it.
- Planned Chimney service reminder and recall software: Configurable follow-up rules per service and per system, rather than a fixed interval.
How we evaluate this, and sources
This page contains no product findings. It is an editorial assessment of what the work requires, written from the trade record model and from the sources below. Where it refers to a standard or a code, it names the jurisdiction and the source and leaves the interpretation to the authority that issues it.
Sources and scope notes
- NFPA 211, Standard for Chimneys, Fireplaces, Vents, and Solid Fuel-Burning Appliances Checked The United States standard document referenced for inspection levels. Named here, not summarized; adoption and enforcement are decided by state and local authorities.
- Homeowner Resources, Chimney Safety Institute of America Checked A United States certification body. States that a Level 1 inspection is detailed in NFPA 211, and that NFPA 211 calls for chimneys, fireplaces and vents to be inspected at least once a year. Supports the terminology note and the follow-up interval discussion.
- Codes Canada publications, National Research Council of Canada Checked National model codes published by the National Research Council, which directs readers to the appropriate provincial or territorial official to find out which codes and regulations apply in their area. Supports this page's statement that Canadian requirements are set provincially and are not summarized here.
- How we evaluate software Evidence labels, the testing method, and how incomplete research is handled.
- Editorial policy Who writes and approves pages, how corrections are handled, and how commercial relationships are kept out of evaluation.
This page is published to help a business select software. It is not an inspection standard, a code interpretation, or a safety recommendation.