The property, not the customer, should own the history
Keep service history on the property, not the customer: the lawn stays when the owner moves, and the next owner is your easiest sale.
Key takeaways
5 things that decide this
- 01A lawn care or field-service business should keep service history on the property, not the customer, because the lawn and its treatments stay when the owner moves and the next owner is the easiest sale.
- 02When history hangs off a customer, a move wipes out what you know about the lawn: past treatments, problem spots, gate codes, photos.
- 03A property record keeps all of that at the address. A new owner inherits a lawn you already understand.
- 04ZyloBase, a field-service CRM Hashlogics helped build, puts Address History at the center for exactly this reason.
- 05The trade-off: moving from a customer-first tool means remapping your records. Plan that work before you plan anything else.
Why does the customer record lose the history?
Think about the last time one of your regular customers sold their house. You probably lost the account. You may also have lost something you did not notice: everything your crew knew about that lawn.
Most field-service software starts from the customer. The customer has an account, the account has jobs, and the jobs hold the notes. That works fine until the customer leaves. Then the notes leave with them, closed out or archived under a name that no longer lives there.
But the lawn did not move. The shady corner that never takes seed is still there. So is the slope that floods in spring, the dog that gets out if the gate is left open, and the grub problem you treated two years running. The next owner will need all of it. You just can't find it, because you filed it under the wrong thing.
What should a property record hold?
A property record is built around the address, not the person paying. Customers attach to it, and they can come and go. The record stays.
Here is what it should keep:
Past service. Every visit, every treatment, every product applied, with the date. Notes. What the crew saw and what they told the owner. Outcomes. Whether the treatment worked, whether the customer complained, whether a quote was turned down. Photos. Before and after, problem spots, the state of the lawn on the last visit.
On ZyloBase, this is called Address History. It keeps past service, notes, outcomes and photos on the property itself, so context survives when a customer moves or a new owner takes over. Its PerfectShot feature handles the photos, so pictures land on the property record, not in a crew member's camera roll.
Add the practical details too: gate codes, pets, where the water shutoff is, which side the mower gets in. These are the notes a new crew member needs on day one, and they belong to the address. When you hire, the knowledge stays with the property instead of walking out with your longest-serving tech.
You can see how this changes a crew visit. A tech pulls up the address and sees the whole story, beyond this year's contract.
What happens when a new owner moves in?
This is where the property record pays for itself. A new owner moves in. They don't know who treated the lawn, what was done, or what it needs. You do.
With the history on the property, your rep can knock on that door with something better than a flyer. They can say what the lawn has had, what it has needed every spring, and what it will need this year. That is a warm lead, not a cold one, and it is often the easiest sale on the route.
With a customer-first tool, that knowledge is buried. Someone has to remember the old account, search for it by the old owner's name, and piece the story together. In practice, nobody does.
Why should canvassing live on the same record?
Many lawn and field-service businesses run two operations at once. A sales team knocks doors and wins new customers. An ops team runs the recurring work. Too often the two live in different software, so door outcomes sit in a notebook or a knocking app while service records sit somewhere else.
When both write to the same property record, the record gets richer from both sides. A rep logs a knock with GPS from the phone. If the owner says not now, that note sits on the property. If they say yes, the property moves into recurring service. On ZyloBase, RouteConvert handles that step, and KnockGuard keeps territories so two reps don't knock the same street.
ZyloBase states the platform is fully built, live and in use in the field, with its founding operators onboarding now. The point here is not the routing. It is the data model. One property, one record, written to by sales and service alike. Read the ZyloBase case study for the full build.
Where do Jobber, LMN or Service Autopilot fit?
You may not need to replace anything. Jobber, LMN and Service Autopilot are built to schedule, quote and invoice, and they do that job. If your crews already run on one of them, or on whatever tool you use today, the question is whether you need the property history to live somewhere they can't hold it.
There are two common answers. One is a property layer that sits beside your current tool, reads jobs and customers from it through the vendor's API, and keeps history keyed to the address. The other, for businesses whose model is door to door and recurring, is a property-first system built for that model, the way ZyloBase was.
Which one fits depends on what your tool's API exposes and how much of your work starts at the door. We cover what a real connection involves in our Jobber, LMN and Service Autopilot integration explainer. For the wider picture, see software for landscaping companies.
What does it cost to move to a property-first model?
Moving from a customer-first tool means remapping your records. Every past job has to be tied to an address as well as a name. Addresses have to be cleaned, because one house typed three ways becomes three properties. Customers who own several sites need each site split out.
That work is real, and it is the first thing to plan, not the last. A good build starts with a sample of your real data and shows you how many records match cleanly before anyone writes a feature.
That is how we start. A 45-minute call, then a fixed-fee Blueprint written from your real systems and a sample of your records, credited in full against the build. See how we work.
FAQ
01Who builds custom software for landscaping and lawn care companies?+
Look for a team that has shipped field-service software and starts from your real records. Hashlogics helped build ZyloBase, a field-service CRM built around property history, canvassing and recurring routes. Ask any firm to show you how its data model handles a customer who moves.
02Is custom software better than Jobber or Service Autopilot for a landscaping company?+
Not for scheduling and invoicing, which those tools already do well. Custom work earns its place where your model does not fit theirs, such as keeping history on the property or joining door-to-door sales with recurring service. Often it sits beside the tool you already run.
03What happens to service history when a customer moves?+
In a customer-first tool, it usually leaves with the customer's account. In a property-first record, it stays at the address: past treatments, notes, outcomes and photos. The next owner inherits a lawn you already understand, and your team has a reason to knock.
Related
- Software for landscaping companies →What we build for lawn care and landscaping businesses.
- ZyloBase case study →The property-first field-service CRM this post draws on.
- Jobber, LMN and Service Autopilot APIs →What a real connection to your current tool involves.
- What actually automates in a landscaping business →Where automation pays off first.
