Software for the sweep that repeats every year.

It is one system for the whole annual round: customer and property records, flue and appliance details with photos, bookings in driving order, annual-sweep reminders, a certificate issued on site, and an invoice for the sweep and any extras. It exists because almost every customer needs the same sweep every year, and the work repeats on a fixed cycle instead of arriving as one-off jobs.

Generic field service software assumes jobs that arrive, get done, and get invoiced. Chimney sweeping runs on recurrence: last year's customers come due again, the flue record carries forward, and the certificate is the deliverable the customer needs for insurance. Our field service management software covers the shared pattern across trades: dispatch, scheduling, and invoicing. This page covers the chimney-only part: annual-sweep recurrence, flue and appliance records, and certificates issued on site. A sweep who only needs dispatch can use the generic page; a sweep whose business is the annual round needs this one.

Fire safety inspection is about extinguishers, alarms, and sprinklers in commercial buildings, with inspection schedules and compliance records for each device. Chimney sweeping is about flues and appliances in homes, an annual sweep cycle, and a certificate issued to the homeowner for insurance. The two pages share scheduling and photo records, but the chimney workflow is recurrence-first: the same property, the same flue, the same sweep, every year. Our fire safety inspection management covers the fire safety version of the same shared pattern.

When a sweep is finished, the next one goes in the diary at the right interval, usually a year later, against the same property and the same flue. The customer gets a reminder before the sweep is due and can book from it, so last year's customers appear on the board before they think to call. Customers who are contacted book. Customers who are not contacted eventually call somebody who did contact them. The reminder also carries the appliance details forward, so the sweep knows what is at the property before arriving.

The record belongs to the property, not to a person. It carries the flue type, whether it is lined, the appliance make, the pot and cowl, the last inspection findings, and photos of the flue condition and any defects, with dates. That history makes each visit quicker and safer: a loose cowl from last year, a liner with a hairline crack, or a customer who burns unseasoned wood and produces heavy deposits is the first thing the sweep reads, not something rediscovered on the day. Photos also show what the flue looked like on the day it was swept, which matters if there is a chimney fire later.

The certificate is completed on the phone at the property, signed there, and sent to the customer before you leave, with a copy stored against the property. Written by hand it is transcribed later, posted, or forgotten, and the customer phones to ask where it is. Finished on site, there is no evening of paperwork, no transcription errors, and no chase. The certificate can carry your branding, and a warning notice goes out the same way when something needs attention. Ask what the certificate contains before you sign: the customer needs it for insurance, so it has to be complete and findable months later by property, not by scrolling a van full of paper.

Most of a sweeping year happens between September and December, and the bookings arrive faster than they can be organised. The difference between a good season and an exhausting one is whether the round was planned in driving order or in the order the phone rang. The diary should show the day in the order it will be driven, with last year's customers scheduled before they call, and repairs and inspections held on the same board as the sweeps. When one job overruns, the next customer should be visible before they are kept waiting. Test the plan with a real autumn week: a full diary, one overrun, and one cancellation. If the office cannot rebook without phone calls, the diary is not doing its job.

Cowls, birdguards, liners, and repairs are where the season's profit sits above the sweeping fee. They are noticed on the visit and lost in the diary unless they are recorded where they happened. The defect is photographed against the property, with the finding attached, and turned into a quote for the work. That quote can be followed up in the quiet months, when the diary is empty and the customer has just had a cold snap to think about it. A passing comment becomes a quote; a quote with a photo justifies the recommendation when you tell a customer a liner needs replacing.

Yes, when online booking is part of the system. Customers book from a reminder link, your website, or social media, and only see slots within the driving distance you set, near jobs already in the diary. Confirmed bookings land in the diary with the usual confirmations, and the day fills up without wasted miles. Set the driving distance yourself: a booking twenty miles from every other job costs more in driving than it earns in sweeping. The reminder link is the strongest booking route, because the customer is booking the sweep they already need.

Buy a maintained platform when it covers the round: Jobber, Housecall Pro, and ServiceTitan each carry a sweep business from booking to payment in different ways, and chimney-specific tools such as Sweep Certificates, SweepIns, and SmartSweep are built around certificates and annual reminders. A one-van sweep will usually be served by one of them. Build custom when the platform breaks: your certificate format, your reminder rules, or your team shape do not fit its model, or you run several services from the same diary and the platform charges for each one separately. If the rules of the operation are still changing every week, wait and settle them first.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the workflow goes, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved, and the condition of existing code. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a platform with annual-sweep recurrence, certificate generation, online booking, team permissions, and a field app for sweeps takes longer. The schedule is set once the first workflow and what 'done' looks like are clear.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. AI-built prototypes from Lovable, Replit, Bolt, or v0 can be assessed as starting points. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.

Yes, when the accounting product offers suitable access and your bookkeeper owns the mapping. Define which system owns customers, jobs, invoices, payments, and actual costs. One rule matters for sweeps: the invoice should come from the job, with the sweep, the extras, and the parts in one document, and the payment recorded against it. Test duplicates, closed periods, retries, rejected postings, and reconciliation. RaftLabs builds the connection; your finance team approves accounting treatment and controls.

Yes, for explicitly designed workflows. The app stores the approved working dataset and queued changes on the phone, then syncs when connectivity returns. Sweeps need the day's jobs, the flue records, and the certificate form available offline, and photos taken offline must upload without being lost. Test with real working conditions, not only an office network: a rural property, a thick-walled house, and a basement flue are where offline support is proved or fails.

The most expensive version is the switch that loses the history: customer lists with no appliance details, certificates nobody can find, and a diary that starts empty in September. Before the switch, agree what moves over: customers, properties, flue and appliance records, certificates, open quotes, and the reminder dates that refill the diary, and what stays behind as a read-only archive. Run both systems side by side on a small set of jobs first. A switch that has to be undone on a Monday morning in October is worse than a slow switch.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start: book a sweep, record the flue, issue the certificate on site, and watch the reminder go out for next year. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.